Wednesday, November 5, 2014

Writing a spec

Over the last few years I've been developing at a crazy pace, and I haven't had the time to write long specs. Instead, how I write specs has evolved to adapt to the pace of development.

First im making the assumption that I'm given the requirements in some form, from highly detailed specs to vague UI mockups on napkins.

Steps to write the spec
1. For each requirement break it down into concrete coding tasks. These should explain the name (ex: a function name) and what it should do (ex: insert new record into table)

2. From this list of coding tasks a design will emerge. 

3. Illustrate the design with diagrams (ex: database, classes, data flow) 

4. Review and refactor the design until duplication is minimized.

Benefits
1. Instructions for writing the code.

2. Precise estimates. Because the coding tasks are concrete, ie not vague, explanations, precise estimates can be made.

3. Explanation of the design, which makes future maintenance easier.

4. Minimize design changes during coding because the design was reviewed and refactored. That doesn't mean it won't change if something was overlooked.



No comments:

Post a Comment

There was an error in this gadget