I tend to fulfil the technical lead role on the projects I work on.  This role means that I’m overall technically responsible for the system.  Put simply: the buck stops with me!

As such, at the start of each new project I tend to spend a week or so working long hours getting the “framework” of the application in place and, attempting to provide the simplest end-to-end example of how the system will be structured that I can.  I also used to write a document that explained the shape of the system too, but I’ve found, through costly experience, that nothing matters more than an end-to-end example in code.

Despite protestations from the “truly agile” I believe this time is well spent getting the various architectural elements of the system , the levels of testing, and the tools we are going to use in place and thankfully I’m not alone in this.  Over the course of the project these decisions will bend, some may be completely reversed, but largely they’ll stay with the project until it’s dying day.  Once the framework is in place, more junior developers can be productive very quickly and concentrate primarily on business functionality and not technical “plumbing”.

Typically, I work on the project through to completion and work as a senior programmer on the project.  Unfortunately sometimes I’m forced to “step off” from a project before it’s completion.  It is when this happens that I tend to see something I’ve termed lovingly the “Sim City” effect.

For those who remember playing Sim City this scenario may sound familiar…

In the older versions of Sim City (I’ve no idea about the newer versions as I moved on to Championship Manager when I hit 12!), you could spend the first couple of hours of the game getting into loads of debt building you’re beautiful city utopia.  All shiny and new you marvelled at how good your Police and Fire Service coverage was and you watched the taxes roll in from happy citizens.  It was around this time that typically your mother shouted you for dinner and you left the city to it's own devices.  An hour or so would go by and eventually you head back to your bedroom and your beautiful utopia.  But what’s this?  Monsters eating your previously beautifully crafted bridges, mass civil unrest and power cuts all over the city.  Despair typically follows… followed by a shutdown!

So the same feeling of despair I got when I returned to my once utopian city can also occur when I return to a project I've started but never got to finish.  My once beautifully crafted tests are now broken or worse ignored.  CruiseControl is shot to bits, and where previously RhinoMocks nicely mocked out underlying system layers to facilitate true unit tests these have been superseded with hand cranked stub classes that have roughly as many lines of code as there are stars in the universe! 

Martin Fowler talked about Test Cancer and, despite some rather emotive language, I think that is just one of the “monsters eating your bridges” that you can see.  Architectural and methodological deviation in general tend to be common place.  That’s not to say it happens all the time and it’s worth remembering too that utopia is in the eye of the beholder but in my experience, the “Sim City” effect is all too common.

Submit this story to DotNetKicks Shout it


I believe that the main reason it happens is that one or two persons write the plumbing code and then leaves for other project assigned to them - leaving other (more junior) developers behind who haven't been there (or allowed) to take ownership and responsibility of the design and plumbing. If people don't understand what they have in front of them they can't see the beauty of it no matter how well written the code is

I agree with what you say in that clearly understanding or (lack of) is an issue - that's assuming my utopia isn't actually a "shanty town"! :-)

Addressing the issue of improving understanding is clearly at heart of avoiding the "sim city" effect. I'll blog on that later...