TCRM and Web Design Paradigms

So what sort of programmer are you? Do you sit there with your pad of paper working through the logical process of the website drawing arrows, boxes and those little annotations with curving little pointers all over the place? Or are you from the rough side of the geeky tracks? Do you play it fast and loose by hitting the code first and hacking away until you get something that works?


I belong to the former category. The idealist programmer. I like to think and plan through every aspect of the site before even thinking about producing one line of code. I like the boxes with arrows pointing to other boxes, lists of functions sorted by category, and roughly draw entity relationship diagrams complete with crow’s feet. When I do start to code I like proper indentation, good naming conventions and nicely written comments all over the place. But us idealists tend to produce at a slower rate, more concerned with how good the program is rather than the fact it is completed.

Kevin on the other hand, belongs to the latter group. The pragmatic programmer. He sits down in front of a screen and starts coding until a solution is reached. The resulting source is not pretty to look at (indentation is for wimps), can be hard to follow and naming conventions go out the window. I once saw someone’s code (not Kevin’s) in which they had called a variable ‘variable’. It’s that sort of thing that makes me and other idealists like me wince. However, it tends to be the quicker method for getting out the first version and usually results in a working product. Not pretty or elegant, but by god it works! They are pragmatists after all.

So you have an idealist developer from Bridgend and a pragmatic developer from Neath. Neath Web Design verses Bridgend Web Design! You would think that this difference of approaches would lead to many arguments, a lot of yelling and stamping of feet and sulking in the office. When I first thought of writing about this subject I though to call it ‘TCRM and the Clash of the Paradigms’, but the further I got into the content of the post the more I realised how this just wasn’t the case. There are very few actual clashes. No raging arguments about function names and third normal form and almost nothing more than a raised eyebrow when it comes to generating JavaScript using PHP echoes (I don’t care. It’s fiddly, difficult to debug and looks bad). Very odd.

It turns out that the best of both worlds for a development team is somewhere in the middle. Staff a team with idealists and you’ll be knee deep in relationship diagrams without a single line of code written with only two days of the project left. Fill it full of pragmatists and you’ll end up with lots of undocumented code that’s difficult to debug and almost impossible to move forward to version two. Get a nice mix and good things start to happen with your products. The pragmatists drive the project forward and the idealists insert a bit more structure. Pragmatists will rein in the idealist’s ever expanding requirements so version one is delivered and the idealist approach will mean version two takes less effort.

It is important to know what sort of programmer you are, and what the other members of your team are like. Would you say you are happy with the balance or is it too in favour of pragmatists or idealists? Don’t be afraid to mix it up. The results are pleasantly surprising.