7. Work In Iterations
Okay, so you're already working in increments. What's the point of working in iterations? Well, unless you are psychic with a freaky mental connection, then you won't get what the customer wants on the first try.
Instead, structure your work iteratively within your increments. For example, if you're working on a web application that interfaces with a database, do only the UI in your first iteration. Don't implement all the functionality. This way the customer gets to see what the UI looks like and fine-tune it before you waste any time implementing the backend.
If you feel you must write some insanely complicated, highly optimized, undocumented inline assembly code that doesn't check its inputs, in one big patch, that doesn't actually work the way the customer really wants, refer to rule number 10.
8. Have Your Code Reviewed
I'm a big believer in code review (see the sidebar entitled "Code Review"). All code should be reviewed for correctness, maintainability, and sound design. The sooner you find and fix a problem, the cheaper it is to correct it. Another set of eyes is bound to catch errors that you've missed, and to double-check you've followed rules 1-7.
************************************************
Code Review
The company I work for, Macadamian Technologies, has its own method for code review. . But our's isn't the only way. Whether it's Fagan Inspections or something less formal, code review is one of the best quality practices in the industry.
************************************************
If you feel you must write some insanely complicated, highly optimized, undocumented inline assembly code that doesn't check its inputs or work the way the customer really wants, in one big patch, and not let anyone check it for bugs, refer to rule number 10.
The point of the review is to find and fix potential issues, not degrade or humiliate the developer who wrote it. If you feel you must publicly humiliate the developer who wrote the insanely complicated, highly optimized, undocumented inline assembly code that doesn't check its inputs or work the way the customer really wants, in one big patch, refer to rule number 10.
9. Don't Stay Blocked
Sometimes you encounter a tantalizing problem. It's an intricate web that draws you in, challenging you and firing up your brain cells for days.
Yeah. Or you could just ask the guy in the cubicle next door.
Unfortunately, your main goal as a developer on a project is to deliver business value to your customer as quickly and efficiently as possible, not to spend days taking on the personal challenge of unraveling some insanely complicated, highly optimized, undocumented inline assembly code by yourself. You may take it as an insult to your technical kung fu, but it's far better to spend a few minutes asking a guru for help than waste hours gnawing on a problem before working out the answer for yourself.
The flip side of this is that you should share your expertise when someone else is blocked. If you feel don't have time to help out a teammate who needs it, refer to rule number 10.
10. Do Unto Others As You Would Have Them Do Unto You
The most important rule of them all. In fact, all the other rules in this coding convention actually come out of this one.
When you start on a new project, what do you want the code to look like?
- Do you want it to have a consistent style so you can understand it?
- Do you want a simple design?
- Do you want to see familiar APIs?
- Do you want to see documentation for the code?
- Do you want it to be secure?
- Do you want it to be full of bugs?
Write your code with the next guy in mind--the one who will inherit the code and not have you to talk to about it.
You're on a team and everyone on that team must be able to trust and rely on each other. If you do something that jeopardizes that, the whole team suffers. Your teammates must be able to trust you to follow these simple rules so that the whole team can be more agile and efficient.
