There are three things that I think should be foremost in one's mind:

1. Design
2. Design
3. Design

Failure to take the time to really map out the data and logic flows of an application are one of the biggest problems that programmers seem to face when writing anything more significant than "Hello, World".

There are plenty of things to consider, but here are some other things that I look for (incomplete list, of course):

• Well-documented APIs.

  Simply listing what everything will accept and what it will return can clarify a lot of issues.

• Orthogonality.

  Each package, module, subroutine, whatever, should have ZERO side-effects. For instance, if you turn on your car's headlights, your wipers should not come on. Further, because there is a well-established API for the headlight switch, you can replace it with a generic brand and it shouldn't affect anything else in the car. This is orthogonality. If you have a module with a well-defined API, you could throw away all of the code and rewrite it from scratch and have nothing else in the system change, so long as you don't change the API.

• Always use source control.

  You are going to hate life if, after 7 revisions, you've realized that you made a horrible mistake and can't go back (or find out who to blame). Source control handles this for you.

• Do not assume that your code works.

  Prove it. Insert bad data into the system. Did the QA team catch all of the bugs? Assume that your data source will spit out garbage. Will your code catch it? Will your code realize that 13 is probably not a valid month? Test and retest all of your assumptions. Every time you release a build, you'll need to rerun ALL tests. Resting on your laurels is a good way to rest on your sofa collecting unemployment.

• Use bug tracking software.

  At the very least, use a discussion board. All too often developers will use email. When this happens, knowledge is not shared. If Alice has already fixed a bug similar to Bob's and she sees the bug on the bug tracking software or discussion board, she can communicate this. Otherwise, she may never hear about it. Knowledge sharing is important. Facilitate it.

• Learn how to normalize a database.

  Even if you never have to do this, you'll be amazed at how often normalization rules apply to program design. Plus, if you have a clueless DBA (I once had a DBA try to use a user name as a primary key), you can spot the issues.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.