The Mu

Agile development encourages iteration. We all know by now the theory that this speeds up development. It meets customer needs because the end users can provide feedback quickly and changes can not only be made in time, but embraced throughout the software creation and maintenance process. But there are other less obvious benefits to agile methodologies.

One of my brothers-in-law was trained as an aerospace engineer. He is now in the software game too. His insight into the differences between these two pursuits is very instructive. In his former profession, mistakes were something to be feared and avoided at all costs. A single oversight when maintaining a jet aircraft could spell death for the pilot or others on the ground.

Some software has equally dire need for mistake-free development. But let’s face it, most of us are not creating life-or-death applications. Iteration in an agile world encourages mistakes. Those who claim they don’t learn better by doing than thinking… have neither done enough nor thought about it enough.

The excellent story about a pottery teacher who encouraged two groups of students to achieve their marks in very different ways illustrates the power of this concept. One group was told that quantity would determine their mark, the more pounds of finished pottery, the higher the grade. The other group was told that they could produce just a single piece, but that its level of perfection would dictate their mark. Regardless of the grades achieved, the group producing more pottery also produced the more perfect piece. Iteration had taught them how to avoid imperfections.

Coincidentally, today Coding Horror provided a great piece about the theory that worse is better which is a variation on the themes my brother-in-law is discovering. Jeff’s conclusion adopted from Steve Martin: “Strive to be consistently good and great will take care of itself.”

When desktop publishing was first introduced, people jumped on it with all the fervor of an incensed mob. They wanted the control that being able to do typesetting for their own projects gave them. They went crazy, using five different typefaces in the first half of every page. Professionals in the industry dubbed these abominations “ransom notes” because it looked like the desktop publishers had purposely cut disparate fonts from various sources to throw off the authorities.

Things settled down eventually and people realized that some level of training is needed in addition to a powerful tool-set. The strange thing is, this cycle repeats itself with each new and cool technology. Blame must partially lay at the feet of the innovators themselves. To get buy-in they oversell. “Visual programming will allow people with business domain knowledge to code up their own applications.” Remember that one? Ever see some of the poorly made Visual Basic programs that have been bolted on to Word and Excel? Ever see some of the good ones? It is not the technology itself that is to blame (well, that is a completely separate argument at least). The users of the tools need training.

The good part of the story is that, just as in desktop publishing, people who have the right domain skills — or develop them — eventually eclipse the casual and unskilled tool users. For example, some of the scary PHP web sites that were thrown up in the early days have reached their breaking point and the new crop of PHP-savvy coders (who in my opinion are indeed real coders) are actually pretty good, producing nice stuff. After all, concepts like scalability and security may not matter at first. But anything can smother under its own success.