Wednesday, January 17, 2007

Scrapping designs

When should you start writing down a design of a piece of software?

Some programmers put this off as long as possible. Once you commit yourself to paper, you start to become locked in to a particular direction. The more you write, the more you become wedded to a particular approach.

Others might advise skipping the design stage and getting on with coding. But the design lock in is even stronger once you have a swathe of code and a decent test suite. Refactoring is fun in small doses, but you'd have to be a masochist to want to spend a lot of time on it.

On the other hand, until I start writing down and organising my thoughts, I can't flush out most of the issues. Putting ideas on 'paper' forces me to define terms and helps me notice inconsistencies and omissions. Maybe I'm just a frustrated mathematician who can't solve a problem without a pencil in my hand?

No, seriously, writing a design down can be really helpful. Once you've done it, you can let the document go 'cold' for a while and then come back to it with a critical eye. It's hard to be objective when ideas are confined to your head. Also, dumping issues in a document helps me stop worrying about them - especially important when I'm trying to sleep.

The best compromise seems to be to start writing things down fairly early but to scrap a design and start again to free yourself from 'lock in'. If you use a decent version control system, you can always retrieve deleted versions.

No comments:

Post a Comment