Stars & Craftsmanship

The first day of Agile 2009 is in the books. While it’s great that the conference is packed with amazing sessions, it also means that it’s not possible to take it all in. Today’s highlights for myself included Programming with the Stars and the Software Craftsmanship tutorial led by UncleBob.

The Stars contestants did a great job and it was interesting to see the pairs work through some simple problems in such a short timeframe. It’s amazing what they were able to accomplish in only three and a half minutes. Languages represented in the contest included Java, Groovy and C. It’ll be a lot of fun to watch this play out through the remainder of the week.

Immediately after Stars, it was time to talk about the craft of software development. UncleBob is always an entertaining speaker who brings a lot of energy and passion to the stage. He began by highlighting his three laws of agile development (while also citing the sources from which he culled these nuggets of wisdom, which I have omitted here).

• In preparing for battle, I have always found that plans are useless, but planning indispensable.
• A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
• …the document-driven, specify-then-build approach…lies at the heart of so many…software problems.

He then went on to talk about general best practices, including some pretty thought-provoking comments. He spoke of incremental improvement, never being blocked, avoiding big redesigns, going fast demands going well, and the importance of clean code. The discussion certainly resonated with me, and the irony in which he presented the material kept the atmosphere light. Two of his quotes caught my attention.

When talking about the importance of TDD versus fancy architecture and design documents, he stated:

If you have a great design, you’ll still be afraid to change the code. If you have a suite of tests, you won’t.

This isn’t to imply that design isn’t valuable, but that our emphasis on spending a lot of time designing the system might be a big misguided. Instead, the real measure of progress is working code and a rich suite of tests means we have the courage to ensure that code remains clean. Then, when talking about testing, he stated:

Manual tests are like me handing you the source code without a computer and telling you to execute it.

He acknowledged that some manual tests are important, but that most manual testing should be exploratory. Acceptance tests, unit tests, and many other forms of tests can, and definitely should, be automated. All in all, a great kickoff day for what stands to be a great week.

From http://techdistrict.kirkk.com/