This question already has an answer here:
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.