Publish and be spammed

For many years now I have believed in the principle of "Publish and be damned" which I learned from my days in software engineering working with Stingray Software. I had never experienced having to write code that someone else would code review or criticise in any way. When I actually had a team of people to tell me what was wrong with the code I had slaved over in my darkened home-office, I grew both professionally and personally.

Code review nowadays can be automated. Systems such as FX Cop and Style Cop will mercilessly tear your code apart and dispassionately explain how much of an idiot you are several times a day, if your software factory is running correctly that is.

How much of this automated code review is really useful though? Microsoft cite the need for uniformity in the code. Because they have such a huge code generating body of workers, the way code is laid out needs to be standardised, homogenised and sanitised for reasons of continuity within teams. but honestly, the rules can seem to be arbitrary on the one hand and just plain stupid on the other.

Mobile work forces can mean many diverse styles, where each coder is conscientiously doing what they think is best and still generating a confusing mish-mash of coding styles for the poor sod who comes after. This is why MS have produced these Machiavellian code checkers.

Working, as I do, in a company that has a large body of legacy code in many different technologies, coupled with a developer workforce who are just ordinary programmers with few aspirations to being the next Don Box, I see a huge amount of code that can only be characterised as absolutely bloody horrible! Given such standard of quality and quality of coder, how can I, as an architect, hope to bring this code into line with even the minimum of compliance to what would be considered as acceptable for the crew in Building 42, Microsoft Way, Redmond?

My conclusion is that sadly, the people that "manage" said body of code have a vested interest in defending the stuff because many of them wrote it. Secondly, the will to change must be coupled with the acceptance that something needs fixing and so, if externally, your architecture doesn't seem to be teetering on the brink of the omni-flush toilet, then the budget is rarely available to re-write the stuff. Budgets are always available however to maintain the awful rubbish for as long as it functions even partially.

So. What's the conclusion you may ask yourself? Well, software is politics because its about egos. People believe that their solutions, however nasty are the right way and elegant and good. Politics is a human condition and someone has to point a finger somewhere.

On the other hand, computers are next to gods in our society. They are always right and they know everything worth knowing, or at least have access to it, so, I have come to the conclusion that if you want code that is readable or maintains the minimum standards, then you should get FX Cop and Style Cop tied securely into your TFS build process and spam everyone who checks in code with all 23,000 warnings a day.

This way, you can sit smugly by in the knowlege that the rules these programs apply are despotic, uneccesary and often idiotic but, when the manager who wrote said crap moans about the time it takes to add a simple function to the code you can put your hand on your heart and say; "Sorry, it's not me, it's the software factory rules. We can't check in till the warnings are fixed."