The difficulties of visualizing software

Since software is not spatial, it is inherently difficult to represent in a way that is easy for the mind to visualize.

From No Silver Bullet (PDF) by Fred Brooks:

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.

Stories

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:


As an engineer,
I want to build software
so that ...

As a coder,
I want make software
so that ...

As an author,
I want to write software
so that ...

As a craftsman,
I want to create software
so that ...

As a developer,
I want to evolve/grow software
so that ...

Estimating in Ideal Time might not be ideal

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.

Relative Measures of Size

Story Points
NUTs (Nebulous Unit Of Time)
Gummi bears
T-shirt Sizes

Velocity, and deriving an estimate of duration

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.

1. ideal time or a relative measures of size
2. fixed length, comprised of working hours of working days

Ideal Time, an estimate of size

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.

Ideal time can be used to derive an estimate of duration.

See also:
Estimating in Ideal Time might not be ideal