The Unwritten Requirement.

Your customer asks for a new feature. She describes the feature, the inputs, the outputs, and we get to work. We deliver the feature. But something bad sometimes happens; we introduce some undesired side effect, a bug.

Implicit in every requirement is "and the rest of the system still works".

We did what the customer asked. She didn't say we could not introduce a bug. Is this just bad luck? Friday the 13th or not, maybe your customer does not notice the side effect. Is this good luck? Absolutely not! Your luck just took a turn for the worse. The defect won't be found for a while, and maybe not until the end user finds it in the field.

You've all heard its better to be lucky than good. I'll take the good luck, but also do what I can to take luck out of the potential outcome.

When a system is young it's pretty easy to deliver the unspoken requirement. But as complexity grows it gets harder. Programmers cannot keep all the details in their heads. We need a backup memory system. The backup system I like is automated tests. With every change all the tests run and any violation of the unspoken requirement is quickly found. Usually it is a design/code problem, but sometimes our customer gives us conflicting requirements.

When teaching TDD to a group of programmers they often say "you would never really right those tests for that simple thing, it's too easy to just get it right". Maybe they won't but I do because the thing that is simple today has to work today and for the rest of the life of the product. Usually code starts out simple, and then is hammered with requirements changes. Today's simplicity goes away, but the behavior must be preserved. A small mistake can take down the system. "Oh, that was just a typo" can still cause weeks of debug time. So, go ahead and write those simple tests early and often. They might save you a lot of trouble. Good luck!

---

!commentForm