Dave McDermid

During particularly tight projects, particularly those for valued clients or high profile websites, there is often a tension between the project manager and the developer. This is my experience, anyway. The reason for this is pretty straight forward, and understanding this is key to a productive relationship. The project managers objective is to make the client happy. For them, this means keeping the developer focussed and on track to complete the work within the time allocated. For the developer the objective is less clear. On the one hand they must keep their project manager happy, by producing work the client will like, even be excited about. On the other hand, they have a responsibility to produce good, clean, manageable code.

The favoured approach is far too often the quick and dirty solution that gets the work done and paid for with a healthy margin. This is great until the project is revisited, and invariably it will. As average solution on top of average solution builds up, there comes a point when something breaks and there is no easy fix. Often, there is nothing the developer would rather do than scrap a bunch of code and rebuild it from the ground up. This is invariably time consuming, and frightening for the poor sod who’s job it is to test it all. There is also the consideration of who swallows the cost of this, as the client / project manager won’t see the immediate benefit of this kind of work, making it hard to justify.

The dangerous middle ground is the point at which trivial tasks become time consuming with unexpected repercussions and legacy code wrecks havoc with a beautiful solution. This guarantees stress for all involved and can strike fear into the heart of anyone threatened with involvement in the project.

So, what’s the solution? I had the first half of this post all planned out in my head, but now I’m kinda winging it. One solution is progressive deprecation. The strategy here is when tasked with implementing a new feature for project, to decide not only what needs to be built to fulfil the requirements, but what existing parts can be made redundant in the process. The process of evolution within a project critically must involve replacing old code with new, rather than just adding to what exists.

There is understandably a fear shared between the PM and the developer for work that stretches the scope of a job. At the end of the day, it boils down to the developer’s responsibility to look after his work. The projects I feel really good about are the ones where I’ve left the code in a better state than when I started. Often it’s tricky to convey this achievement to a PM, who is generally only interested in things that they can show off to the client.

This is where peer review among developers really comes into it’s own. I know from personal experience I write better code and make better technical decisions when part of a team. This is natural, it taps into the desire to show off and prove your worth to colleagues and when harnessed correctly can be powerful.

Thanks for reading, would be interested to hear your thoughts..