How to merge several product lines into one

[dennis-fedco]

I have a task that seems to be complex.

 

Short Description:  currently users of the application I am hired to develop have two steps to do when using the app:

1.  Select a Product Line (A, B, C, D)

2.  Select input parameters for that product line - all product lines have simlar "Main" input parameters, but also each line has its own special features that can be selected.

3.  Selections for that product line are shown - the result is a long table or options for that particular product line.  Things like price, discounts, product specifications, etc.

 

What the users want now is this:

1.  Select input parameters (not sure how to handle individual product lines special parameters yet)

2.  Selections for all product lines are shown

 

The code base is legacy code, with code thrown around everywhere.  One idea me and my coworkers have been considering is a complete rewrite, since it will help us with writing tighter code, and do what the customer wants.  But that will also take time, and there is no spec.  The spec is in the code mess.

 

Another one is I am considering now is a "merge".  Somehow merge the product lines, since we have the separate product modules (A, B, C, D), there must be a way to consider maybe extending one to include the others, or somehow get me to the end result -- allow users to see selections for all product lines.

 

Do you have any experience, any suggestions on how to do this?  I know this needs details, and details are in my code that you don't see, and most likely won't have the time to read and understand anyway. 

 

But I am looking for any ideas or encouragement though that may help.  And my question is -- is there any kind of procedure or technique or something to deal with the problem I am facing -- merging several separate yet similar modules into one single merged module.  How do I approach this, what are some things that could help, etc.  That's what I'm looking for.

[requinix]

I suggest you get an explanation from the user(s) as to why they want that change. Seems to me like the biggest gain is that they can use the "main" parameters to find all products, without caring very much about the specialized parameters.

If that's the case then you can change the procedure a little bit as a compromise between the existing system and their desired changes: let them select the main input parameters to start, and optionally allow them to choose a product line and then the specialized parameters for that product.

 

As to the technical questions, it'd help to know how the system is architected - like the overall flow to the code (like does it use MVC to any extent), where code is loaded from (like is it a bunch of included files or a bunch of autoloaded classes), and the structure of the files themselves (like whether the HTML output is located inline with PHP code or segregated).

[Psycho]

My biggest question would be how is the data set up currently? Are each line in separate tables? Are those tables similarly constructed (i.e. same columns, at least for the same parameters)? If they are in the same tables or the tables are similar enough you can probably use what you have and create new procedures for performing the searches. But, even if the table structures are very dissimilar, you could run multiple "queries" on each product line in a single query to get the results from all lines using a UNION.

 

A complete rewrite will be a huge task, but you would get better, cleaner code (assuming you do it right ). I would ask myself these questions. Aside from the new request are there other non-minor problems with the current functionality? How much time is spent currently maintaining the application? If there are problems for the users how much time or pain are these issues? If it's not broke don't fix it. Ugly inefficient code that works - still works. So, you have to weight the effort of the initial rewrite and the effort to clean up bugs that get missed during that process compared to the current pain to the users and the time you are investing to keep the current application running.