Coding Standards
Hopefully I'm not divulging anything I shouldn't, but I got this email recently:
<<I know everybody gets tired of me harping on this, but please follow the coding standards. Some places that these were not followed are:>>
I could show the exact examples, but I had 5 violations of our coding standards. A few years ago, I probably would have gotten all defensive and had some rationalization like “Well, if this is the worst I did than I must be doing pretty well.” But to be honest, all it would have been was a rationalization.
Where I work currently, we have more than a few very large roll outs in production. When I say large I mean 30+ assemblies, with a LOT of functionality in them. I've been there since August 20something of 2004 and to date, we have not taken one single support call due to a bug or us missing a requirement. Your first thought is B*** F**** Sh1t - no body gets it that right - or there must be something else to it. Well, there isn't. Typically one of our smaller projects is probably at least a 1/4 million dollars and a few of them are substantially larger. But a few things I can say that we get VERY RIGHT!
1 - Understand the problem and the solution - Period - end of story. We put a tremendous amount of effort into this - a LOT. When I first started working there, my biggest deficiency was my skills in Word and Visio. If you don't know what you're building then you have issues. But at more than a few places I've worked - the Programmers would build what they thought the users wanted - and if the users didn't like it - well, we'd either change it or blame it on the stupid users.
2- Doing things right the first time is always quicker and cheaper than doing them over. Or, “Measure twice cut once”. Or, “the longest distance between two points is a shortcut.” This means we spend a lot of time writing and reviewing specs. As a developer, this sort of blows. But, it's necessary and having worked in NO spec environments, I wouldn't change it for anything.
3- Ownership - Everything is owned by the person that wrote it - but the whole team shares ownership on the success of the project. The whole notion of “Well, it's His problem” doesn't exist, not at all. That's simply not an excuse
4- Testing. I actually worked at a place with Kim that had their quality control policies written out on an Index card that was photocopied. It basically came down to “Make sure you test your stuff becuase if you don't, it'll be bad”. We had testers OBSESSED with Tab Stop issues, color schemes, and all sorts of other stuff that 'matters', but only if the product worked. On our payroll program, we paid someone like 10 or 11 million on week because of an overflow that the developer missed, and so did our genius testing team. But dammit, our Tab stops were right, even on those screens that no one ever used. The only reason we found out was becuase the IRS stopped the transaction b/c it set off all sorts of Money Laundering Alerts. They contacted the bank, who contacted the client, who contaced us (Next time you hear someone tel you that we can't lower taxes without cutting vital services, please drop me a line btw). Guess who that company blamed for this? Come on, Guess! Yes, the Client - they should have run reports that would have caught this. Literally, our response was that it was THEIR fault for not catching it - we gave them reports after all. [Since you may be disinclined to believe me here, hit google, go to Groups and search on Smithdata.net - most of those questions were asked by the all - star developer). The truth is, all of it matters. If you are too busy or too smart to please your clients - no worries, someone else will [See, I did learn something in MBA School].
5- Taking pride in your work - at every level, particularly the higher up you go, you see Pride in the company and pride in the product. As such, you couldn't really miss the fact that if you did something knowing full well that it would affect the customer - it wouldn't go over well (to put it mildly).
6- Turnover - as in almost none.
----------------------------
As someone who's favorite variable name is 'x', I've had to adjust. It's frustrating at times b/c the learning curve on coding standards is not small. But think about it - if you can't even camelCase your variables when they should be PascalCased without it throwing up flags - if you can't even forget to comment a code block in its entirety without it getting caught - what are the chances major code flaws are going to slip through the cracks? Nope, because code reviews start with the important stuff (like do the numbers add up, how much stress can things take etc) and work down until the smaller issues, like variable names and case.
We hear tons about how companies screw up - but not nearly as much about how they get things right. What are some things your company gets very right?