Monday, August 8, 2011

RetroSpec: The quick long way

RetroSpec: The act of writing the spec after the code has been written.

For various reasons, sometimes it makes sense to first write the code and only afterwards to write the spec. 

For example: You may not be sure what is technically possible, you hope for at least some minimal functionality, but discover that it's trivial to implement a fully-blown feature.

Sometimes it doesn't make sense, but it simply happens; a quick fix or tweak turns into a feature. This could be the result of a programmer having a sleepless night and dedicating it to the cause, or a team having an internal competition.

Or it may simply be a case of feature-creep.

If it's already coded, why the spec?

If nothing else, QA needs to be know what to test, and without a spec that cannot know what is broken or purposely missing.

If you keep documentation up-to-date, then you will need a spec so that the technical writers have a starting point.

But the most important reason to RetroSpec is to enable a spec review. Experienced Project Managers are adept at discovering the corner-cases, but can only do so if there is a spec to review.

If need be, the Project Manager should write a spec, simply in order to ensure that the corner cases are covered.

In a future post we will give examples of typical corner cases, and how to find them.


- Danny Schoemann



No comments:

Post a Comment