Archive for September, 2008

Tools of the Trade – Write it Down

Posted on September 5, 2008. Filed under: software development |

  • Source Control
  • Bug Tracking Software
  • Dedicated Build Environment
  • Testing
  • Documentation
  • Modern Hardware

    Write it Down

    How do you know when you are finished?  How do the testers know that you are finished?  How does the customer know that you are finished?

    Well, unless something is written down then there is no way that all three of you will agree that you are finished.  Everyone hears things differently and perceives things differently. 

    Take three people who just witnessed an accident and ask them what they saw.  You will likely get three similar but slightly different descriptions of the event.  Wait a week and ask them about the accident, and you will get similar responses from the first time.  Wait for a month and ask them and what do you get?  Vague recollections and feelings about what they saw. 

    Get all three people together and quiz for details and you will get three very different responses.  Each person, depending on their memory and emotional reaction, will remember different aspects of the event.  This is the classic problem that forces us to have judges.  They sort through the different viewpoints and decide what is fact and what is fiction.  They then make a decision and pass judgement on an event.

  • Now imagine that you are in the middle of your project and it is time for testing to begin.  The testers, who were not present in the requirements sessions are starting to test the software that was written by someone who received the requirements through word of mouth by the architect who is now working on another project.  Does this sound like a disaster waiting to happen?

    Well, at that point in a project it is a disaster that will take many stressful, conflict filled meetings to hammer out.  Much better is to take the time at the start of the project to write out requirements and reach agreement on what is to be delivered.  It doesn’t matter what form the document takes; what is important is that every stake holder in the project has read and agreed that the contents of the document accurately reflect the functionality that will  be delivered.

    You need something that can be referenced by everyone involved in the project and use as the arbitrating source when conflict arise.  You will need to have someone assigned as the owner of the document and who will be responsible for updating and maintaining the document throughout the project.  The document needs to be in a format that is understandable and useful for everyone involved.

    There is little point in writing things down if no one will read the document.  Try and avoid hundred page documents of dry writing.  Inject some humour, add lots of pictures, put in information that will be useful.  Remember the target audience of the document and tailor the detail to that level.

    Perhaps you have business and technical users?  Well think about creating two different documents: one for business requirements and the second for technical requirements and design.

    Read Full Post | Make a Comment ( None so far )

    Liked it here?
    Why not try sites on the blogroll...