Fog Creek Software
Discussion Board

Re-using desgin/code

The question can be interpreted as follows in one line:

  Will we succeed in re-using a code base and design which has not been designed/developed for re-usable purpose? I am talking about relatively big/complex source code base.

The elaborate question is as follows:

What kind of code can be re-used?

Here is the situation: Product A is big, complex and has lots of product specific code.

Product B is new, which is similar to product A. We don’t have software spec for product B. We don’t really know right now what components that we need in product B.
Management decided that we have to re-use Product A code. We studied Product A source code and found that it is well designed, has some reusable code but too much product specific code.

The developers who are going to work in Product B have no idea about Product A source code and design. Product A source have some software design documents but specific to Product A.

How to go about this situation?

One proposal is to start removing product specific code from product A and make it some common code base. This is assuming that we know what we wanted in a common source base.

Another proposal is to study the Product A source code line by line, and see if we can re-use it or not. Remember we don’t have Product B spec yet.

Any thoughts?

Afraid to tell my name
Thursday, September 02, 2004

> has some reusable code but too much product specific code.

Doesn't that seem like the answer there? Abstract
out the code so it handles both cases. Don't
try to handle every case. Just the cases you know

aftraid to respond
Thursday, September 02, 2004

Basically all reusable code starts out this way--as not-quite-reusable chunks of a real application.

If I had permission to modify project A, I'd start out by refactoring useful classes into standalone modules, retesting A at each step. I'd write unit tests for the new standalone modules *and for the parts of A which interface with those modules*.

At the same time, I'd start by developing a primitive version of B which called the new standalone modules (and unit tests for B, of course).

In general, if I need to modify an existing codebase heavily, I write lots of unit tests *before* making changes. This allows me to make wrenching changes without (much) fear of breaking stuff.

J. Random Hacker
Thursday, September 02, 2004

Afraid didn't say whether he wants to maintain Project A: whether he wants to end up with A and B (implying that A is refactored), or whether he wants to end up with only B (implying that A may be cannibalized).

Christopher Wells
Thursday, September 02, 2004

Was the code for product A built with reuse in mind?  If not, forget about it.  Reuse almost never happens by accident or as an afterthought.  Write the code for product B from scratch, and deliberately design it make it reusable so product C can benefit.

Thursday, September 02, 2004

Been there done that.  The code for Product A was well enough engineered that I could rip out huge chunks of it (the stuff not needed for Product B) and still have it mostly compile.

What is hampering us most is that the overall architecture for Product A doesn't quite translate to the new product.  So we have a few odd pieces of functionality grafted onto or embedded within the code.

In the short term, I think we've saved some time.  In the longer term, I suspect we will wind up refactoring and recoding to support new features and it'll play out to be roughly equivalent to starting from scratch.

Should be working
Thursday, September 02, 2004

It sounds to me like the management refered to by the OP has decided that they want some sort of Product B, similar to A. Ergo, we must reuse product A or B will be *too expensive*.

This is classic poor judgement on the part of management. There is no way to predict ahead of time whether refactoring a massive existing architecture will be cheaper than starting over, perhaps with newer, better tools or dev environments. This is especially true if you have no specs for product B.

I've seen this type of reasoning before from those who think they understand software development, but really have only a limited experience with it. Let me guess: is the management's experience primarily with product A?

Another factor to consider is how much destabilization you are willing to accept in the course of heavy refactoring of A. The type of changes you allude to rarely occur without introducing bugs. It helps if you have good unit tests though.

My advice is this: don't get into the evolution vs. revolution argument, especially if the management have emotional attachment to product A and some delusions that they understand software. You won't win. Instead, treat the project as an exercise in learning how to safely restructure large existing codebases.

But don't be surprised if you aren't given time to do it correctly -- if time weren't an issue they wouldn't have already decided they had to reuse A.

Jeff Kotula
Thursday, September 02, 2004

"We don’t really know right now what components that we need in product B."

Until you do, forget the question of code re-use. If you start trying to refactor now, all you're going to be doing is burning £5 notes (replace currency as applicable).

Unless there's at least one person who has the time to both understand the product requirements for Product B, and understand (at least approximately) the code base of Product A, you might as well start drafting the appendix to Death March now.

Andrew Cherry
Thursday, September 02, 2004

Product A is active and going to be alive for a long time.

I am afraid that instead of developing ‘Product B’ specific functionalities, we will be spending most of the 'Product B' development time on correcting Product A code base to create a platform on which again the Product B code have to be written.

Afraid to tell my name
Thursday, September 02, 2004

Substitute 'correcting' with 'Refactoring' :)

Afraid to tell my name
Thursday, September 02, 2004

Sounds like a crock of shit. What do you want us to do?

Thursday, September 02, 2004

"Product A is active and going to be alive for a long time. "

maybe you can forget Product A and rebuild (not refactory) product B (of course, you can copy some codes from product A)

There is  possible risk in development process of product B.  When you "correcting Product A code base to create a platform", maybe you make product B *dependent* on product A in the early phase of development process? Only you know the details.


Thursday, September 02, 2004

I second Andrew.  You *need* the spec for Product B before you can make any decisions.  That includes the premature decision that your pointy haired bosses have already made to reuse Product A code, although it doesn't sound like you have any say in getting them to consider that more carefully.  But you should insist on knowing more about B before you start trying to figure out what chunks to rip out of A, or whether you want to create a common code base.

Thursday, September 02, 2004

Third that.  Are the following suppositions correct?

1) Product A is up and running with maintainance staff of 2.

2) Product A users like it as it is - working.

3) Product A development team is dispersed / out the door.

If so, no one sane would touch Product A,  it would be like fitting a new motor to a jetplane in midair. The task is way beyond the maintenance guys (been there, done that) and is a threat to the product. Let it go.

Copy A's codebase to B and start afresh. Use relevant chunks from A, but do not retrofit to A.  Rehire any good guys from A's development and tell them it's their last chance to get it right.

And sack your managers - they're nitwits. Quote from this thread if it helps.

Friday, September 03, 2004

*  Recent Topics

*  Fog Creek Home