Studio Vs Live In Software Development

Led Zeppelin By tony morelli (originally posted to Flickr as led zeppelin) [CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons

I like rock music. And I love live performances. Well, you know, studio albums provide a great sound quality and the cure of small acoustic details. But songs registered during a tour are on another planet.

Because a song evolves during time. It is never played in the same way twice. In some cases, it is completely different, with another rhythm, other arrangements or with a new guitar solo. There may be some small imperfections but they are quickly forgiven by the energy provided by the musicians. And eventually there is the interaction with the public that sings and claps.

The first release of a software is just like a studio version of a song. It's perfect, right? It has a wonderful structure, meaningful variable names and good comments before each function. Then the testers find some bugs and slightly your code starts to change. Then the project manager asks you to modify the behavior of a particular dialog. Then the customers want to add new functions. Eventually the code becomes a mess and you do the refactoring.

If you try to execute git blame on your code at this point, you'll find that more than 50% of the functions have been changed since the initial release. But this is not a problem. It's tested, reviewed and appreciated by users. Now your software is absolutely better. Just like a good song played live.

Cleaning Up the Path in 5 Easy Moves

Freddie Mercury - "I Want to Break Free" music video
Freddie cleaning his house
The idea for this post came during last weekend while I was cleaning my house. In fact, this activity is made by several parts: some are funny (like using the vacuum cleaner while singing "I Want to Break Free"), some other are boring, others are awful.

The development of a big project is very similar: there is the challenging part, the damn-long part and the stupid part. Here there are some advice to help you to accomplish your job in the best way.

1. Split the project in tasks and subtasks - this is obviously the first thing to do; start developing headlong is something to avoid.

2. Try to see if there are constraints - it's important to understand which tasks must be made before others and define a clear path between them.

3. Start with the task you consider the worst - it may be the longest or the most boring or the most annoying, the choice is up to you, but when it will be done, the rest of the project it's all downhill.

4. Work on a single task at a time - you have a road map (defined at point 2), why do you need to get rid of it?

5. Work always on tasks related to those already accomplished - in this way, you are always sure that new pieces fits properly in the existing structure and it's easier to test your progresses.

Well, that's all folks. Let me just add another general purpose suggestion: always remember the 80/20 rule, that can be declined as "details will cost you the majority of your effort".