Using code from an existing application and making a new one from it. - Good idea?

Question

There is a fully tested running codebase that has gone from ver 1 to ver 4 over a period of 4 odd years. This code is sufficiently tested with the last bug reported about 6 months ago.

Is it a wise decision to take that code base and make a different application where the UI stays 98% the same but the functionality changes around 80-85%.

I personally am not for it, but still want to know your views and thoughts so that I can either challenge this decision when called to, or quietly accept it.

Edit A related post:- http://stackoverflow.com/questions/721371/software-design-approach-design-build-test-refine-design-document

check the reply by S.Lott

About the application: lets say its an HR app where the original deals with say employee performance feedback and the 'clone' deals with the employee's career plan. A Career plan is treated as a document and so is his perf feedback and thats the end of the similarity. The data is different. The only common data is the employee userbase. since both apps deal with employees. The UI is moderately coupled in some areas. There are no documented classes who methods and properties can be called. We just take existing code.. delete whats not required in our opinion, add our code.

Answer 1

Um, I guess if your goal is to have an application with 98% of the same UI but 80-85% different functionality, then it's a wise decision to go make that. Is there some alternative choice?

Answer 2

No*

*Unless your old codebase is next to perfection in both style, practices, and functionality. Which I doubt.

Just make sure that before you start a new codebase, you fully understand why it is you do not want to take the old one, otherwise you will repeat history.

Answer 3

If the new app is similar enough to the original one, it doesn't sound like a bad idea. But it's hard to say without much details.

This sounds like forking, which is a common and perfectly reasonable thing to do, assuming you do it for the right reasons. Many excellent apps have been developed off the code base of another application, and you can see a lot of this going on in the open source world.

Answer 4

It sounds like your application code needs the redesign. The UI stays the same. Your application code should not depend much on the UI so I don't see an issue. Keep the UI. Redesign the application. The application is more interesting work anyways. Or am I missing something?

Answer 5

If the UI is tight coupled to the functionality in the old application, then just ignore it and make all from scratch. Otherwise just adapt your views to your new code.

Answer 6

I guess it depends (as usual) I wonder what kind of app / change that is, where function can change without the UI

If the code that you could actually reuse is more the 20% and more or less cleanly seperated, it is probably a good idea to reuse it. Of course the nice way would be to extract common functionality (domain logic or ui) into libraries, but that might be to expensive, depending on the future plans for the software

Answer 7

Reusing code really depends on your needs, having a solid base is usually something good, but if your base doesn't fit your needs, then this is wrong. UI isn't usually the biggest part of the job. You will probably have result faster if you use this, especially if its as good as you say but at what price. You can consider it for prototyping, otherwise prepare for some major refactoring.

Answer 8

Rewriting code is expensive. Developers often want to start from scratch and "do it right this time." You'll end up with new bugs, and a late schedule. Reuse as much as you can.

Remember that an engineer does for $1 what anyone can do for $2. Time is money and bugs are expensive, too.

Answer 9

I think there are two related issues here. One is the question of code reuse, which many of the other responders have commented on already. In general, if you can easily reuse the code, you should.

The second question is whether it is sensible to have two applications with substantially different behaviors share a common user interface. This is the more interesting question I think. Unfortunately, the answer depends on what your applications are used for. For example, the various applications in an office suite often share a substantial amount of the user interface -- they have common menus, toolbars, dialogs, etc. That's generally considered good, as it makes it easy for a user familiar with one application to work with another from the same suite.

On the other hand, you can imagine cases where sharing the UI will only lead to frustration and agony for your users. As an extreme example, suppose you have an application, SmartHouse 2009, which allows you to control various aspects of your ultra modern smart home. In this application, you have a control that allows you to turn off the cooling system in the house. This involves a button with a clever icon of a melting ice cube or something; when you click the button, a dialog is shown asking the user to confirm the action.

Now suppose you need to write NuclearPowerPlant 2010. Thinking to save some development time, you crib the UI from SmartHouse 2009. Lots of things line up just perfectly. There's even a need for a button to turn off the cooling system in this new application, so you reuse the UI from the first app. Unfortunately, your users have all been using SmartHouse 2009 for months and months, and they have gotten very used to turning off the home A/C with that button. It's ingrained into them that using that button is a relatively harmless action. One day, some poor user comes to the office and logs into NuclearPowerPlant 2010. He feels a little bit cold, so he clicks on the melting ice cube button, expecting it to turn off the A/C. He even clicks through the next dialog -- remember, he's been doing this for months at home. Too bad for him, he disables the power plant cooling system, triggering a massive nuclear explosion.

Obviously this is an extreme fictional example. But you could easily imagine situations in ordinary software, where a user gets used to a button in app A doing a particular kind of action, and assumes that a similar button in app B will do a similar kind of action. If it doesn't, your users will curse you every time they hit that button.

So the question is, how similar are your applications really? Are the conceptually the same, but operating on different types of data, or data from different sources? Are they related in that they are part of a suite of tools with many common actions between the two? Or are they really independent, unrelated applications? If they are unrelated, what is the probability that a user of app A will ever need to use app B?