As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs superimposed one upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships. These graphs are usually not even planar, much less hierarchical.

...

In spite of progress in restricting and simplifying the structures of software, they remain inherently unvisualizable, and thus do not permit the mind to use some of its most powerful conceptual tools. This lack not only impedes the process of design within one mind, it severely hinders communication among minds.

This post by Joel made me smile and got me thinking about an interesting way to highlight the differences between the various ways we software developers perceive what it is we do. I haven't gotten around to describing the perceived benefit/reason of the As a user, I want user story template yet, but here goes:

Sunday, March 08, 2009

Ideal Time estimates are almost inevitably perceived as estimates of duration leading some (especially managers) to compare the Ideal Time estimates with actual Elapsed Time. Velocity then becomes a measure of efficiency, used to determine how close they are to removing the impediments that the developers encounter everyday. This might make sense, except that Ideal Time is not really about time and the good intentions might actually be detrimental if the developers find themselves explaining why they only got x Ideal Time of work done in x+y Elapsed Time.

The root of the problem is the assumption that the x in the x+y Elapsed Time is the same as the Ideal Time x.

Tuesday, March 03, 2009

By measuring the team's rate of progress (velocity) in terms of the number of size units of work [1] done in an iteration [2], you can arrive at an estimate of duration in terms of the number of iterations required to complete the remaining tasks: remaining size units of work divided by the teams velocity.

Instead of having to think about and account for the inevitable overheads that occur everyday, velocity gives us a way to map ideal time into elapsed time based on historic data.

Ideal time (or ideal development time of effort) is the amount of time it will take you to finish a task if you had no interruptions or impediments. It is an estimate of size or effort and has little to do with time, since you rarely ever get contiguous blocks of productive time.

Estimating in ideal time is affected by various factors like the developers own cognitive biases, their skill and experience levels, complexity of the problem, the design of the software, and available tools, to name just a few.

Monday, March 02, 2009

Traditionally, software developers are expected to give estimates of duration in elapsed time. Elapsed time is the actual time (working hours of working days) it takes to complete a task. This includes time spent on things (inevitable everyday overheads) other than the task at hand.

Estimating in elapsed time is inherently difficult because, apart from the various factors that affect the estimation of effort for a given task, you also need to worry about: distractions and interruptions [1], unexpected events or obstructions [2], and just about anything else.