The house building metaphor

I really like metaphors. They make it easier to understand and explain complex and abstract things easily. One of the most used metaphors in software development is the house building metaphor.

But unfortunately it isn't a good fit for modern software development,

First of all a house is built from the basement to the roof. One floor after another.

In software development we have layers but usually we don't complete a whole layer before starting to work on the next one.

Also if we do test driven development for example we are constantly refactoring (which is the equivalent of reconstruction of the house). If I would see workers constantly building, moving and removing walls I would be very irritated but it's basically what we are doing with constant refactoring.

Another difference is that you can't start to build the house without an exact plan. You shouldn't differ from the plan by more than a few millimeters but in software development it's often counterproductive to have a big plan. (But you should have a plan anyway but "Big design upfront" is really an anti-pattern)

Additionally the customer usually doesn't change it's mind while it's house is being built. But it's not an exception that the software developer's customer comes up with new and changed requirements during the development phase.

But unfortunately I don't have an idea for a better software building metaphor.


Premature optimization is the root of all evil - also on J2ME

There are a lot of valuable resources on the internet with a lot of tips and tricks to reduce the size and improve the performance of MIDlets.

One comprehensive resource can be found here: http://sergioestevao.com/midp/?p=21

If you really have to optimize the above link and a lot more you can find on the internet can help you.

But you should really think twice before applying one of these tricks.

In general you should reserve a realistic amount of time at the end of the project to optimize for size and performance and make the application fly on all the desired handsets. This step might take a considerable amount of time. The best strategy to deal with that is to have a clean code base to start with. Development is a lot faster when working on clean code.

Before entering the optimization phase you should NOT sacrifice clean code for size and speed. In the long term writing clean code and using clever algorithms will make a big difference. A good software design and methodologies like test driven development is the most important thing for being successful. Otherwise you will end up with unmaintainable and messy code.

Remember that optimizing clean code is a lot easier than cleaning weirdly optimized code.

Additional I believe in the following guidelines
  • Don't optimize if you don't need to. Stop optimizing as soon as possible. Enough is enough.
  • Don't do what a bytecode optimizer / obfuscator can do for you. (e.g. method inlining makes getter and setters cost you nothing)
  • Optimize step by step. Measure the effect of each optimization. If it doesn't pay off - roll it back. The internet if full of performance optimization myths (not only regarding J2ME) so don't believe what you can't measure yourself.
  • Create a new branch for the optimization. Keep the clean code for later addition of features. Keep the clean version up to date. (i.e. don't fix bugs only in the optimized version)
  • Focus on the hot-spots of code where small changes have a big impact. There is no need to pollute the whole code when 20 percent would do the trick.

Remember that all of these suggestions are just suggestions. If you are writing a J2ME action game for low-end phones you might have to do more optimization than when you are writing a web-service client for high-end phones. As a rule of thumb optimize as late as possible.


ProGuard 4.4 has some problems (with MIDlets)

Recently I found out that obfuscating one of my MIDlets with ProGuard 4.4 resulted in a broken application. The application did start and most of it worked but some of the features were broken.

The good thing is: After going back to 4.2 everything was fine again.

Unfortunately I hadn't had the time to investigate more on this but if you run into similar problems when using a more recent version of ProGuard you are warned by now.