Channels ▼
RSS

Design

Coding Conventions: Make Them Agile


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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video