Yesterday was a day of mistakes. Not so much making mistakes, but talking about them. It started with Bret Pettichord’s tweet
Agile requires the courage to make mistakes in front of others and the maturity to admit them when they happen.
There were a couple dozen people who showed up at the Fool, last night, for my presentation on A ”Lingua Franca” to Ensure You Get the Right System. I’d like to thank them all for coming and for such lively participation.
These are exciting times. The tools of acceptance testing and behavior-driven development are progressing beyond the domain of the techies. They are entering the realm where they can help the Whole Team. (Continued)
Maybe you’re starting your first Agile project. You’ve read books and blogs. You’ve had training. You think you’re ready, but it’s still a daunting prospect. There’s just so much to remember—so many details.
Here’s a little cheat sheet. Forget all the details and the various ways you can implement Agile for the moment. Let’s simplify the picture. There are just three essential legs that your Agile project needs to stand. Get those in place, and you’ll do OK. Keep improving all three, and you’ll do fantastically! (Continued)
It’s a very common complaint, such as this one left on the Scrumdevelopment yahoogroup:
Usually in different phases, workload for tester and dev is different. E.g. when a project is coming to the end, most of the tasks will be test.
There are a couple of big red flags waving at me in those two sentences. One is “different phases.” Why should a software development project, especially one only a couple weeks to a couple months long, have phases? The other is, at “the end, most of the tasks will be test.” Postponing testing to a phase at the end has never worked very well. It always results in the testers being behind at the end.
Does this situation sound somewhat familiar to you? If so, what can we do about it?
Much of the time, the test-driven development yahoogroup is pretty quiet, but it has recently awakened from winter hibernation. The question “Is it OK to add code to a class only to improve its testability?” stirred up a wide-ranging discussion that brought in the topic of what constitutes good design. “Uncle Bob” Martin drew a bold line in the sand with his comment,
One reasonable definition of good design is testability. It is hard to imagine a software system that is both testable and poorly designed. It is also hard to imagine a software system that is well designed but also untestable.
I greatly sympathize with this statement, though I wouldn’t go quite that far. I don’t think it is so hard to imagine code that is testable, but poorly designed. For a trivial counter-case, there could be rampant duplication of testable code. I would call that poorly designed, but it doesn’t affect it’s testability. Therefore I would soften Uncle Bob’s definition to “One reasonable component of the definition of good design is testability.”
To me, the notion of “testable code” is the same thing that “testable circuit” was back when I worked on a custom integrated circuit. Mostly, that depends on the ability to put the circuit or code into a known state, exercise it, and see the interactions with its collaborators and its resulting state. (Continued)