If I started a project at work and leapt straight into the code without a specification and only a vague idea of where it was going, I would think myself crazy – and think those that got me into this situation beyond polite description – so why on earth have I done this to myself on a larger-than-usual personal project?

Do I really think it’s not important enough to spec?! Does it mean that little to me? Ha!

For the past week or so I have been “tickling” at an idea I’ve had – I need something to work on to make me learn Zend Framework as there just wont be time for me to learn it at work (oh that could fill a blog post all of it’s own!) and last night I got frustrated with the whole thing – it was only in the cold light of a meeting at work today where I went off on a 2 or 3 minute rant about doing something without a spec that it hit me, I couldn’t get going on this project because I hadn’t clearly defined my goals.

As the internet of today would say… Face Palm!

Why does writing down what you want help? In the corporate world a specification can be thought of as an agreement between the client and the development team – this is what we say that you said you wanted. It can be signed off against and gone back to after delivery to make sure things happened as everyone expected.

There is no reason why you shouldn’t hold yourself to the same high standard as your clients hold you.

This is why I’ve called a halt to messing about with code in a vague hope it’ll magically shape itself into the half-baked idea I have in my head and I’m pinning myself down (quite a feat I can tell you) to shaping my thoughts and, shock horror, writing not only a technical specification but a requirements document as well.

And you know what? It feels darn good!