Next steps for developing new product [duplicate]

Question

This question already has answers here:

How can I convince management to deal with technical debt? (17 answers)

Closed 6 years ago.

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.

Answer 1

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...