TITLE: Agile Themes: Working Code and Tests AUTHOR: Eugene Wallingford DATE: December 07, 2009 9:58 PM DESC: ----- BODY:

An undefined problem has an infinite number of solutions.
-- Robert A. Humphrey

It's always seemed to me that one of the best motivations for writing tests first is to know when I'm done. I am prone to wandering in the wilderness and to overthinking what I do. Writing a test helps keep me close to task. When I first heard Kent Beck ask, "How do you know when you are done?", a little light went on for me. I felt something similar when I first saw the above quote on the old "Thinking Again!" blog. A test helps to define my task, circumscribing the problem, taking me from what is usually an incomplete statement in the specification or in a list of requirements to a concrete answer to the question, "Am I done?" The idea behind test-driven development is that well-written tests can do more. They also evoke a particular design and implementation. This gives me not only an idea of where I am going, but also an idea of how to get there. That said, an undefined problem may have zero solutions, and executable code can help us avoid this circumstance, too. Adam Bosworth makes this connection in his blog entry on creating healthcare XML standards. He warns against writing standards in the abstract only:
5. Always have real implementations that are actually being used as part of design of any standard. It is hard to know whether something actually works or can be engineered in a practical sense until you actually do it.
Much like analysis and design done independent of any code, a standard written independent of a reference implementation may have big holes in it, not make sense to potential implementors, or even be implementable at all! This ought not be surprising. A standard is a specification for a set of systems that we envision, and our imaginations can outrun our ability to build clear solutions. The best way not to get ahead of ourselves is to build a clear solution as you go along. The working system we build is a proof of concept for the standard, a concrete implementation that helps us to verify that we are on the right track agile. If those who are intimately familiar with the standard being written cannot implement it, then almost certainly others will struggle more. This implementation is different than a test in TDD, a mirror image really. But it plays a similar role in helping us to know if you are done. If our reference implementation is unclear or are hard to build, we can find weaknesses in the standard as it is written. If we want to write a good standard, a usable standard, then we are not done. Bosworth's advice echoes the values that underlie continuous testing in the agile approaches: a preference for working code, a desire to test ideas against reality, and a desire for continuous feedback that we can use to make our product better. Other advice in Bosworth's article embodies agile values, too, especially a preference for people and simplicity. Consider:
1. Keep the standard as simple and stupid as possible. 2. The data being exchanged should be human readable and easy to understand.
Simplicity and communication, intertwingled. -----