The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Building a 2.0

I'm just wondering what the community of developers out there would advise in this situation:

We have ProductX 1.0, which is written in a less desirable language and less maintainable design than we would like.  We are undertaking ProductX 2.0, which will carry over the basic features of 1.0 but have a better internal design, supportability, new features, and actually be maintainable.

An approach that has been suggested is to *keep* the language A source code in the new, actively developed, project and convert it to language B, and as each piece of functionality is copied from the original source, delete the old source code that it came from to signify that it is done.  There are two problems that I see with this approach:

1) the old code is not actively used in the current project... so it violates YAGNI to an extreme degree

2) the old code is not a good example of how to build the new code, so the conversion cannot be done class-by-class or method-by-method

3) the old code is very big and is much harder to comprehend than what is going on in the UI

What would you do?
Stuck In The Middle
Friday, August 24, 2007
Make that "three problems," I guess.
Stuck In The Middle
Friday, August 24, 2007
Rewrites are generally a waste of time.  I'd leave the existing system in place as long as possible, only fixing critical bugs when necessary, and implement something completely new and different.  When fixing those critical bugs, that's when you take the time to fix the true issues behind the bugs, refactoring the old code to get to the true problems at hand, but do not add new functionality at all.  That's what the new project is for.
Friday, August 24, 2007
Assuming that I really really wanted to move to a new language and a new architecture, as you've indicated (and there are plenty of reasons for doing so, as long as you're willing to pay the price), I'd probably start by porting the unit tests & regression tests. (Don't have tests? Start by writing them.)

Then I'd start developing new code against the unit/regression tests.

Depending on the similarity of the two languages, I might copy/paste the old code into the new project and start hacking on it from there (not without the tests, though). For example, if I was porting a project from Java to C#, I'd *definitely* take this tack.
BenjiSmith Send private email
Friday, August 24, 2007
+1 to the first half of what Benji said.  You have a system that you know works... aka a "baseline".  Your tests should be quite easy to write because you can just run it through the system if you're not sure of what should happen.

The second half could be useful up to a point, but if this is really a re-architecting /restructuring, then things aren't going to be a 1:1 mapping and having the old code in front of you constantly may send you down the old paths.

You want the old behavior, not the old structure.
KC Send private email
Friday, August 24, 2007
"You want the old behavior, not the old structure."

That's a good point.

Though I think it's a bit risky to simultaneously move to a new platform AND a new architecture. I'd probably approach the project in two phases, first porting to the new language/platform (with the old architecture) and then I'd refactor to the desirable architecture.

If you move to a substantially new architecture, you can probably kiss all of your existing unit tests goodbye, since they're unlikely to be very applicable under the new architecture (given the typical granularity of unit tests, as opposed to regression tests).
BenjiSmith Send private email
Friday, August 24, 2007
In this case, there are no existing unit tests and the product is largely GUI based.  The "back end" is pretty basic from the functionality point of view and very testable.  I don't have any experience in automated GUI testing.  I assume it is possible with tools like JUnit?
Stuck In The Middle
Friday, August 24, 2007
I would identify the basic features I keep from version 1.0, write detailed test cases for it (manual in your case I suppose) and bite the bullet: the product gets rewritten so do it.

The old source (as it looks like is no good) I'd keep separately for reference, but what's most important I'd make the old product 24/7 available to developers.

While a developer works on a feature (s)he must make sure in 2.0 it works the same way it works in version 1.0. In your case it means comparing UI from two monitors. Too bad you have no unit tests (yes, you can have unit tests for GUI, just separate widgets and functionality classes from the beginning).

If you have QA, it's a very good idea do NOT share test cases between testers and developers. You don't want developers to drive evaluation of your product quality, do you?

Don't waste you time and money on automated GUI testing tools, it's a pain in the ass to maintain, and it is not for developers to use, a good tester who knows a tool can be way more productive there.
deem Send private email
Friday, August 24, 2007
I'm a big believer in not burning bridges.  People who burn bridges as a "symbol" that they can't go back often find themselves in situations where going back would be a really good idea -- but they've already closed off that option.

And in software, obscure bugs can hide for quite some time -- how do you REALLY know you're "DONE" enough to delete the old code?

And it's OLD CODE for crying out loud, leave it on a CD somewhere, what's this urge to destroy working stuff?
Friday, August 24, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz