I was hired about a year ago as the lead (well, really the only) developer on a new project/product we will call product "B". Product B was designed to pursue a new market for the company.

This company has had great success with a similar product for a different market. We will call this other product "A".

“A” is almost 5 years old now and is reliable.

The two markets don’t necessarily overlap, but a lot of the core functionality in A could be re-purposed to work for B.

My deadline to pursue this new market for product B was pretty aggressive. We had to demonstrate certain capabilities to potential clients quickly and show them that we were a serious competitor in the new market. To expedite the development, we took the shortest route to create a new product. We started with a deep copy (a branch) of the companies' product A and re-purposed it as B.

This approach made a lot of sense given the time constraints as we inherited a lot of overlapping core functionality and infrastructure for free. We removed a bunch of features and options that didn't apply, left some things that carried over, and added a bunch of new features that were needed to secure these customers. It wasn't a perfect transition, but it was good enough.

Product B has been around for about a year now, and things are looking good as we have secured two customers with several more potential customers on the horizon. What are the next steps?

From a “best practices” perspective, it doesn't seem like a good strategy to continue developing product B as a copy of product A. It’s not a solid foundation to build a new product.

We accomplished our immediate goal by creating a “product” and demonstrating it to potential clients. Now, shouldn't we take a step back, find out what the users really want and refine our design?

We really don’t have a “new product”. We created some “vaporware” for a couple of demo installs.

Unfortunately, I get the impression from management that they think we have a new product to develop and sell and there is no time to step back and refactor and refine. Why would we spend time and money redesigning when we already have something we can use and sell?

Here are my issues:

  • Since it was created from a copy of A, the product B code base is littered with artifacts and “technical debt” from product A. Some of this code is no longer reachable. Some of this code is reachable, but maybe the business logic does not make sense for product B. For example, there may be lookups against empty tables in the database or checks against things that don’t exist. This type of logic not only hurts performance, but it also a maintenance nightmare.

    I’m going to estimate that we’re actually using 35% of product A’s code base, and the rest is baggage.

  • Management thinks it was smart to create B from a copy of A: “It will save money since code can be reused between the products.” If a bug is fixed in A, why can’t it be merged into B? Or if I develop a new feature in B, why can’t it be merged to A? This argument is flawed. Although B was created from A, it was done so over a year ago, and A has a dedicated team with 4 developers. I am alone on product B. The code branch for A continues to diverge from B. Now, it’s very difficult to merge anything.

  • Finally, I feel as if we've put unnecessary constraints on ourselves by starting with a product that's already 5 years old. Some aspects were designed very poorly and will no doubt create the same problems with a new user base. Let’s take our lessons learned and use this opportunity to improve the design instead of copying crap. Also, let’s utilize new technologies where it makes sense - a lot of things have changed in 5 years!

How can I convince management that we need to refine our product – most likely from the ground up? My boss thinks in terms of time and dollars, and I feel that I am going to lose this debate if I’m not careful. Can this type of effort be quantified and put into management terms?

I've been reading up on “emergent design” and I’m trying to approach my argument from the angle that we don’t have to deliver everything all at once. Let’s focus on small pieces of working code with the most business value.

  • 1
    You wrote "Product B has been around for about a year now" and "we have secured two customers with several more potential customers", but then "We created some “vaporware” for a couple of demo installs". So you have paying customers for over a year for vaporware? Does not sound reasonable for me. What's the actual status production of product B? – Doc Brown Mar 21 '14 at 12:17
  • Perhaps, the term vaporware was a slight exaggeration. Does it work? "Yes". If you paint the walls, add new carpet and tile to a house with foundational issues, will it sell? "Yes" That's the closest analogy that I can come up with. In other words, it works, but it's very brittle. Once customer's start to use it and generate new feature requests, how well will be able to respond? – Russell Mar 21 '14 at 12:20
  • @DocBrown, can you clarify what you mean by "actual status production of product B"? – Russell Mar 21 '14 at 12:26
  • Sorry, typo, I meant "production status" (so you have paying customers actually using product B and they are happy with it)? – Doc Brown Mar 21 '14 at 12:28

The best architects I know have the same reaction periodically - that the fix for all the problems in the project is 'to start from scratch'...

As code ages, it gets messed up, acquires technical debt, missed the boat on a lot of exciting new technologies, which would have made modules in the current system simpler, or even redundant. Also, the architect looking at the system has also aged, and (hopefully) wizened, so he now sees decisions he's made about the product in the past, and knows that now he would have made different (better?) decisions.

There are times when this is also the best approach, but on other times, it might not be, especially since any new code you write as susceptible to the same aging the current code suffered.

What management is looking for, and so should you, is value in writing from scratch. Look forward into the future, and identify the concrete points where the product will hit a brick wall if it continues to depend on the parent project.

Focus on the differences between the markets to show that the products, although on a business perspective might look similar, are actually profoundly and architecturally different.

Also, I suggest that you search for a way where you can gradually divert from the current code-base (by re-writing a module at a time), while always adding value to the system, so that you will not end up suggesting a long period of non-functional deliveries, which might be very problematic in a fast-paced new market, where the competition is just waiting for that edge over you.

If you can't find enough deal-breakers in the current code-base, or can't think of a way to make the change without losing ground on the business aspects, maybe you should consider the possibility that, as much as it offends us technical people, management might be right to keep the current code-base as long as possible...

  • 1
    IMHO a really good architect understands Joel Spolsky's warning against "the big rewrite". – Doc Brown Mar 21 '14 at 12:36
  • @DocBrown They might understand, but the temptation is always there... Of course, they don't actually do it (most of the time), but complaining about wanting to do it is very satisfactory at times – Uri Agassi Mar 21 '14 at 12:38
  • Great points about on focusing first on the "brick wall" type areas and addressing these by gradual conversions. – Russell Mar 21 '14 at 13:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.