TDD and Product Definition

Are you in a role of designing products (not necessarily a software product) and your job is to write Functional Specifications?

If yes; have you came across an article called "Painless Functional Specifications" by Joel Spolsky?

If yes; then you are already doing TDD even though you may not be a programmer!


If you haven't read this article I will urge you to read it first. Its concise, highly useful & written in an interesting (Joel's) style. I'm sure you will thank me after reading it.


I think TDD is the most sensible way to write functional specifications.

• The first step in writing specifications is to write Stories. User Stories with names that highlight how user will be benefited.   
• Something like ... Stacy is a Project Lead in a software developer company. She uses an issue tracking tool called FastTrack (disclaimer: if a tool by such a name exists; then it's a mere coincidence).On the dashboard she can see all th issues assigned to her. However there are dozens of issues on her name; but at present she is interested only in seeing a handful issues which are work in process. The tool can provide a wealth of data; but that's overwhelming to her.
• This user story is like a "Test".
• To start with you haven't designed the product. So user is not able to do what he intended. So the test fails. A very important step in TDD: See the test fails!
• Then you design your user interfaces that is just enough (yes, just enough) to make the story (I mean the test) pass.
• Then you go on to next story. You may have to refactor you interfaces while satisfying more & more stories.

Looks simple; isn't it? But the advantages are great!

• If you are into the business of making products; you might have experienced there are just a lot of redundant features in the product. Many times we add them because...
• 
  
  We want to make the product rich with features. More features means there is more stuff for the sales people to talk about & impress.
  
• 
  
  We think that might be useful to the user.
  
• 
  
  or we add it just because we can add it; we have the technology available.
  

• Users don't really want features; they want to get their job done. Unwanted features only confuses them.
  
• 
  
  If our product is old; then maybe we are adding features for many years together. We just go on adding features. Hardly we bother we reorganize the interfaces; because of many reasons. This is similar to programming. We go on adding code; we don't bother to remove code or refactor it. Why? Because many times we don't understand it; its written by someone else & its working. Also the code is being called; we don't want to break any existing users.
  

TDD lets you to free from all these problems.

One just need to have following descipline:

• I will not write a single line of specification ( or user interface) unless I describe a failing User Story.

• I will design the user interface that is just enough to satisfy the above story!

Once I came across a quote that was placed in email signature of one of my colleague:

A Design is complete not when there is nothing to add more; it's when there is nothing left to take out from it!

TDD encourages us to do the same thing; right?

• TDD Homepage
• TDD and Science