Construction Myth in Software

-- reprint from Agile Complexification Inverter post dated December 2010.

I'm reading Scott L. Bain's book Emergent Design - The Evolutionary nature of Professional Software Development. I'm reading it because of the discussion in a work session on the nature of software just this week. One person was describing why we software developers needed to think long and hard on our problems and design the best possible solution to deliver value to our customer. He was advocating the BDUF philosophy. I asked if he thought software could be grown, as a tree is grown from a seed into a seedling and then many years later a mighty oak tree. He said software was more like the Sears Tower (a local to Chicago never refers to the building by it's current name - Willis Tower).

I'm constantly amazed by the power of a meme. The ability of this construction based mental model to remain within our industry is astounding. Discussing this with a colleague, we thought this one model to be one of the hardest for people in their transition to Agile to re-wire in their brains.

So this is why I'm re-reading Emergent Design. Is there something here that will help me in the dialogue with these Architects? I've place my mental model of software as a creative process, a work of art, an activity of design where the building or construction phase takes about 20 milliseconds (incremental compilation of modern IDEs). The test phase of software may require much longer up to 10 minutes (run a suite of automated user acceptance & behavioral test). Then we destroy the completed product (delete the compiled executable) and go back to design with the knowledge gained from the tests. This quick feedback loop is why software is not like the Sears Tower.

We could not build the Sears Tower and then check to see if the lights were in the preferred location on a sunny spring day to light the artwork on the executive suite wall; find that the lights needed to be relocated and then destroy the building. Blow it up and start again. Place the lights in a better location and now look at the electrical outlets, how do they work? A little to the left - blow it up again.

So I have great hope that Scott Bain's book will turn-on a new connection in my brain pathways.

In the section on "What sort of activity is software development?" Scott notes that licensing and oversight by the state are aspects of a profession, such as doctors, lawyers, accountants, engineers. He argues that "software should be conducted as a professional activity, but that it isn't yet." I find it funny that even my barber is licensed and has oversight. Yet many in the software industry believe they are professionals.

I wonder how many "professionals" that have say 5 - 10 years experience developing software do not know how to unit test their software adequately? I heard of a test manager (UAT) reporting that he didn't want to waste his tester's time testing the application that was being delivered from the development group because it had only 7% code coverage by unit test. In my opinion this is malpractice (accept that malpractice applies to a professional). I assume that a hiring manager could go to the local university and hire a CS graduate that not only knew how to unit test - but also practiced TDD. The company would be well served by hiring 2 - 3 college grads and putting them on the team, allowing them to train the old guys. Learn the accepted practices of your profession or get out of the job.

I suppose if software was a construction site job, then the architect could design a wonderful application on paper then give it to a programmer to code. The skills used would remain rather constant. There would be little need to refresh knowledge or to keep current with the best practices. Then the programmer would be much like a steel worker, highly skilled in a narrow focused specialized trade. No need for a profession for the programmer.

But architects are licensed professionals aren't they? Did you notice that we borrowed the construction industries labels for abstract roles. That's too bad. Anyone know the meaning of the word architect? The word comes to English, from French, Italian, Latin, and originating in Greek as arkhitekton, arkhi - 'chief' + tekton - 'builder'. It is not surprising that a word borrowed so many times has lost its original meaning. One who knows how to build. How many of your companies architects write code - build software?

-- 2010-12-19 reading Drive by Dan Pink -- David's Notes

Behavioral scientist divide what we do into two categories: algorithimic and heuristic. Building the Sears Tower is algorithmic (construction); designing the tower is heuristic. We use the term build the widget application when we mean design the application. Changing the terms changes the assumed behaviors that are required. Changing the behaviors that are required changes the management system we wish to use to view progress and assess success. The twentieth century was the age of algorithmic work. We don't live in Frederick Taylor's world today. It is a new world where the work is heuristic. Look at Ford's assembly line; we have hired robots to work the line.

Thanks to Taylor's methods the robots are very good at their jobs.