Our last installment today is about the Great Ivory Tower of Standards and Architecture. In case you missed the previous bunch:
Seven Habits of Highly Dysfunctional Enterprise Developers:
- Blame Everyone But Yourself
- Confuse Motion With Action
- Use Complexity To Demonstrate Intelligence
- Keep Important Information Secret And Safe
- Fix It Later
- Reuse Is Overrated
- Principles Are More Important Than Results
Ever work on a project where some group (or some person) in your company espouses standards above all?
“You absolutely must follow our standards to the letter. We’ll be having daily code and design reviews, anything out of compliance will of course, be refactored to meet the corporate standards immediately”
Principles and best practices are great things to engender on a project. A highly respected architect friend of mine said to me over and over, “It’s better to be consistent than right”. Consistency gives predictability to people looking at code for the first time. They learn what to expect and it reduces up-to-speed time for new developers. It also creates mini “code templates” in your work patterns to speed things up as you develop.
You can take this too far. Projects where standards are used like a whip are demoralizing and turn action into motion purely for the sake of consistency. Remember: Your goal is to ship a finished product that meets the customer’s requirements, on time and under budget. Following standards is part of that but creating painfully complex standards and then demanding absolute adherence in this fashion is just torturing your developers.
Have standards, but keep them simple. Standards exist to create consistency, not some absolute right-or-wrong litmus test for code. Balance is important–shipping a product ad-hoc without any standards is a recipe for disaster during your first bug fix or maintenance release, but following each and every standard down to the comma is just wasting cycles. Don’t err on the side of extremes either way.
A good developer knows that there is more to development than programming.
A great developer knows that there is more to development than development.
Got a habit that I missed? Sound out below!