Calvin Austin's Blog

April 2006 Archives

Java: What's in a name

Well first let me tackle the Tiger bit. The Java codenames are all listed here. Tiger or 'Project Tiger' was the name used on a day to day basis, its a convenience instead of saying one point five point zero. The names are chosen as big animals (birds, mammals) for major releases (tiger, mustang) and little insects for maintenance releases. Graham Hamilton took this naming to heart and even launched a poll to decide on dolphin. The insects were all to be beneficial insects too, don't expect a Java roach to make an appearance any time soon.

The name mustang was initiated by a little in-joke by myself, both the product managers at the time drove a Ford Mustang. It wasn't hard to convince them that it was a good name.

The other numbering scheme was so nearly Java 2.0 for Java 1.2, Java 2000 was also on the table as it was the fad at the time. Who knows there may have been Java XP going down that road.

In all that time though the platform internal version has stayed consistent, we looked at how Solaris tackled this with SunOS versions and Solaris and decided the last people we wanted to upset were the developers who wrote code on the platform. Personally I think Java 5 as a name is at the right name at the right time.

So you want to rewrite or re-factor your application

Why Code Rewrites Don't Always Work.

Give an engineer some code and one of the first things crossing through the mind of some engineers is, "Should I rewrite or re-factor that code?". The logic being that the new version will be ultimately be better in some way than the original.

However simply rewriting or re-factoring an application doesn't always warrant the effort you put in. The rewrite version may generate new, but different bugs. As well as include some of the old existing bugs. The new version may ultimately take far longer and cost more than the original. It could even run the risk of missing its time to market or not really meet users needs. I use the term 'time to market' to cover open source projects as well.

So what should you do if you want to rewrite an application, or one of your colleagues is planning on a great rewrite project and you want to convince your manager that they shouldn't just say no?

Well, I have some tips and techniques that may help. I've been developing software for over 20 years, most recently at SpikeSource. I've seen the good and the bad and formed some of my own thoughts over the years. I'm interested in your thoughts too!

Why does an application need rewriting?

First what is a rewrite? I use the term rewrite and re-factor interchangeably although there is a difference. A rewrite normally implies additions, deletions and corrections to an application. A re-factor is a change that should leave existing interfaces unchanged. In this context both apply but more typically a re-write is where most of the issues appear.

To find out why an application needs re-writing, it really helps to find out what happened during the original development. Ultimately many projects that now require a rewrite, experienced one or both of the following.

Case 1. Short of time and was under-resourced
Case 2. The project was breaking new ground or was experimental

The results of these constraints is that in the first case the project is very likely under-tested or even untested. In the second case the project is more likely to be under-specified or unspecified, especially if the end users are unknown.

Steps to make the re-write a success

Case 1: Short of time and under-resourced

Symptom Checklist:

1) Bug fixes and hacks that clutter or make code messy
2) Bug fixes that don't have test cases
3) Documentation if it exists, doesn't match the source code.

Resolution:

The first question you should ask is this. If the original author didn't have time to complete the project what has changed, is there more time now?

Does the application have a large mature installed based? The risk/reward ratio on rewriting this type of project is going to need significantly higher development costs to mitigate those risks and make the project a success.

Were the tests hard to implement or run, for example i18N and GUI tests are often expensive and test optimizations are often made.

If you do go ahead, spend time to revisit the design and make the specification complete. Backfill tests to validate the current behavior. Those hacks may initially appear like they can be re-factored but without the tests to verify changing the code may introduce a new bug. By putting more cost into validation the rewrite has a higher chance of succeeding.

Case 2: Experimental

Symptom Checklist:

1) Specification will be incomplete, or not reflect the final product
2) Tests, if they exist do not match the end user experience as there were no end users

Resolution:

Again re-write the specification completely before starting.
Try and extrapolate test case scenarios through initial bug reports.
Finish use cases and plan to spend a larger effort on test cases before starting coding

Conclusion

Rewriting a project should never be undertaken lightly. The difference between a rewrite success or a rewrite failure can be a matter of a few bugs either way. Ultimately don't repeat the mistakes of the original author, especially if that original author was you.

This work is licensed under a Creative Commons License.