Calvin Austin's Blog

Programming Archives

Dirty secrets of computer engineering

Imagine taking your car into the shop, they call back saying you need to apply a manufacturers fix to the fuel injection system, it may not fail now but soon. Instead you say, "No way! I put one of those fixes on before and it took a week to get the car working again!"

OK, my example isn't perfect but in the software world we are trending towards the wrong end of trouble-free updates. Don't get me wrong, software updates in principal are great, I like useful new features, fixes to annoying problems. The problem is that each user now has more customizations, more add-ons and the applications are more complex and modular than before. The tested patch may never go through the number of permutations required out in the field

There is a whole industry of "Change management" like ITIL, to essential mitigate the risk of a change causing a problem. However I found very little about identifying the root cause and technology to solve it. If you have a configuration file, which by its very definition implies it will be changed, how do you manage updates to that changed file? What if your reseller also changed it? How do you diff an XML file? Does a registry or configuration database help or hinder updates?

My colleagues Nimish and Vinay collected some of the current approaches and a strategy for configuration updates. There is also a new open source web-based diff tool, JSBlend. If you have used graphical diff tools before the web based approach should look familiar. The industry still has a long way to go to clean up the current state, I just hope we are heading in the right direction.

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.

What do Developers Want?

Open Source IDE shootout

For all the hot air, both products and teams are more alike than they are different. Netbeans is free, Eclipse is free and yet both parties spend huge resources to give them away. The original IBM eclipse team and original Sun netbeans team were both away from the companies central engineering efforts and probably had more freedom in the direction they chose.

Both have reached a good usability level with useful features, but at the same time the corporate sponsors want to see their features like mobile support even if there is debatable current demand.

As a Java developer I believe the competition is good, they both set a standard for the other to reach, The downside is that it makes it increasingly difficult for the commercial tools vendors that provide even higher productive gains to survive. That said I've enjoyed giving them both a test run with JDK 5.0

To finish, a reminder we have a free event at SpikeSource next week http://www.spikesource.com/testfest.html. I'll be there if you just want to talk all things Java.

This work is licensed under a Creative Commons License.