I’ve had some interesting discussions lately on the management of work through user stories. A lot of teams, especially those just starting to use agile techniques, seem to have quite a bit of uncertainty around some common topics :

• The theory behind story points and why they are preferred over estimations in hours
• Why story points and velocity are self-correcting measures
• The sizing process and appropriate sizes for stories

The problems with sizing in units of time

I’ve had the opportunity of working on several waterfall projects. I feel blessed to have been in these teams because I now recognize that:

• Most estimations in hours are completely thumb-sucked. Given that software development is an incredibly complex beast, how can we possibly forecast time to be spent on a specific task in an accurate fashion?
• Work break down structures are frequently used to aid in estimations, even though they exasperate inaccuracies of estimation at lower levels.
• As teams typically contain members at different skill levels, how long a task takes depends on which members of the team actually do the work. An estimate based on time does not make sense in this context.
• Traditional project management focuses on getting projects on time, sometimes sending teams on a death march and severely compromising on quality.
• Waterfall based software teams are held to completely inaccurate estimations. The Gantt chart proves to be completely inflexible as the focus of the traditional project manager is on staying true to the original plan.

It should be obvious that I’m not a big believer in time-based estimations. Apart from the above, one should also watch out for the problem of local safety :

If asked how long a small task will take, a developer will naturally not want to deliver it late. After all, this is a small task, it should be on time or the developer wouldn’t be professional. Hence, the estimate will include a buffer to absorb the developer’s uncertainty about the task.

The estimate given by the developer will depend on how confident that developer is that he has understood the task and knows how to perform it. If there is uncertainty in the understanding of the task, then the estimated time to completion is likely to be significantly longer. No one wants to be late with such a small task.

In a discussion with a former colleague of mine on the organization of components and on system boundaries, we focused on the complexity inherent to software building. It hit me that we can learn a little from physics here.

The law

The first law of thermodynamics states that

energy can be transformed, i.e. changed from one form to another, but cannot be created or destroyed.

This law, in my mind, can be applied to software development quite generally :

Complexity in software can be transformed, i.e. changed from one form to another, but cannot be created or destroyed.

I was about to make this law my own, but on writing this I found that another named this back in 2003. Matt’s first law of software complexity states :

The underlying complexity of a given problem is constant. It can be hidden, but it does not go away.

Or:

Complexity is conserved by abstractions. In fact, apparent complexity can be increased by abstractions, but the underlying complexity can never be reduced.

This post is more than two months late, but I’ve been at DStv Online since November 2011.

Intervate has been incredibly good to me, and is still on my recommended list of employers. I have had incredible growth there, and I thank them for that - but with consideration of some quality of life issues I’ve been having, and a need to stretch my skillset a little, I’ve decided to move on.

So far, I’ve found my new environment stimulating and challenging. I’ve spent most of my career in finance (aka banks) - the media industry is completely new to me so I’m learning a lot there. The people are eager to experiment and learn on both technical and process levels, and I can say that I have never felt at home quite so quickly at any of my previous jobs. This video is a good indication of the type of enviroment they have.

Some perks :

• Exciting, pioneering work. Not (as a friend put it) writing Excel over and over again.
• Public facing sites. You know that “What do you do for a living?” question? I have an answer for people who are not complete geeks. I can show them.
• I work close to my house. No highway travelling. Period. No sitting in traffic. Actually, I might even downgrade to one of these soon.

Nothing quite like a bit of change.

In preparation for my yearly “I really need to update that dang blog, yo!” new years resolution, I’ve followed the advice of Simon Cropp and moved my old blog to Posterous.  

If you are subscribed to my FeedBurner feed, there should be no changes necessary from your side to receive updates from me.  Please update any other bookmarks to my site.

Wordpress has served me well, but has become a bit of an antiquity when compared to some of the modern blogging platforms.  Some of the features here are very encouraging.

Here’s to a new year of fresh content!

A “Are you sure you want to do this?” confirmation when you attempt to run a query that contains a destructive update (delete/update) without a where clause.   With the hoards of database tables being accidently wiped in the world, why hasn’t this been done yet?  This feature would sure remove a lot of fear of pressing F5 *. * Those who are not afraid running a delete query query on a production database clearly haven’t lived long enough yet.  On a similiar note, those who trust their code still need to experience taking down a couple of servers with it.