TCRM and the Moving Goalposts

One of the most fundamental problems that people can have when designing websites, and software in general for that matter, is the lack of a goal. ‘What am I trying to achieve?’ is the question that needs answering the most for it is one of the most influential. It guides the development of the site or software by providing a framework to design choices. You can ask yourself the question, ‘Which option will help me achieve my goal?’ and all of a sudden, choices become clearer.

Writing anything without everyone, including yourself, having a clear understanding of what you are trying to achieve is just asking for trouble. If you are trying to create a slick business site, you’ll want to steer clear of smileys and gimmicks and make it feature rich with good reporting tools. If you’re creating a popular social site, then you’ll want to spend real time and effort on the commenting engine while not worrying too much about every possible field an event can have. When you’re planning your ping pong club’s pub crawl, you don’t need to specify whether the facilities include an overhead projector and the number of available network points. Just the name of the first pub and what time the drinking starts.

Extreme examples of web design problems yes, but it does highlight the approach you need to take. Lack a clear vision and every feature that catches your eye can get thrown into the mix and you’ll find yourself knee deep in features, which all cost time and effort, and in the end you really don’t need. Worse of all though, you’ll be at risk from feature creep.

Without a clear vision at the start your system will grow and develop a life of its own as you try and find your way. As the system reveals itself you’ll gain a better understanding of what you want so feel the need to add more features. This is fine if you’re writing a system or site for yourself in your spare time. But if you’re contracting out the work or working with your IT team to put the system together for you, you’ll soon have a disaster on your hands. Code will be need to be rewritten or thrown out all together, designs trashed, object models broken. Programmers don’t like doing this at the best of times. Having it forced upon them by others is the equivalent of someone telling a builder they have to alter the house they’re halfway through because the buyer wants the kitchen to point south. A lot of blood, sweat and tears went into it and no one wants to see it lost in vain. This tends not to happen so much in the building trade though because everyone can see how much work goes into a house. How many times have you been asked, ‘Can I have a button which does this?’ After all a button is only a small thing isn’t it? Also, builders have really easy access to sledgehammers.

So in order to stop us Bridgend geeks or your fellow geeks coming at you brandishing their pencils which have been sharpened to a very fine point, work out what you want to achieve before you start putting the system together. Much blood, sweat and tears will be saved.