Home > Software Development > A developer’s 10 commandments

A developer’s 10 commandments

March 1, 2007

After reading an article about 19 Things NOT to do when building a website, I thought I’d post here the top ten things not to do when developing a piece of software.

1 – You won’t copy and paste code

Programming is about organising ideas, if you duplicate a chunk of code and it contains an error, then if you want to correct this error, you’ve got to track and debug both occurrences of this chunk of code, providing you remember perfectly where you pasted the chunk. If you’re clever, you might want to use a tool to find code chunk duplication, hopefully, there’s Simian (Similarities Analyser).

2 – You won’t copy and paste files

It’s the same problem as with the code chunks. If two files contain the same code, they also contain the same errors or imperfections. If you want to correct or to improve one file, you risk to do the work twice or to confuse the two files. If you need to make backups, this is not a good excuse. Configuration Management Systems keep a backup of each modification of important files without making unnecessary copies (tools like CVS, SVN or Darcs only save the differences between versions).

3 – You won’t develop too much features

You should avoid the error to put too much things in your software. A software project is not a demonstration of your development skills. You should develop a software that responds exactly to the user needs, neither too complete nor too simple. This is also true for performance, memory usage and graphic finition. In everything the middle course is best: all things in excess bring trouble to men. If you really want users to be passionate about the product, you should give them what they want transparently, and not try to impress them with a feature list.

4 – You won’t steal what others have done

Open Source software is a great thing but you shouldn’ t take advantage of publicly available source code to make commercial applications. If you use some source code under GPL as a part of your project, it must be an open source project. Putting apart legal and moral considerations, you shouldn’t use source code that you don’t fully understand. If the code is too complex or poorly documented, you should consider redesigning or rewriting it.

5 – You won’t code on the fly

Sometimes, software projects don’t have a requirements document and the design is mostly done in the head of one programmer. In this case, the programmer chooses himself the required coding activities. It often turns into a failed project because deciding on WHAT to do with the user and thinking about HOW to do it are crucial steps needed before going through coding. The worst thing that can happen to a software project is a constant adding of features on a day to day basis without feedback from the users or at least from the testers.

6 – You won’t forget to verify

When you have completed a coding activity, you must verify that it is working. Automated unit testing is great but exploratory testing is sufficient and cheaper. The verification process must also ensure that the previously working functions still work after a new release. The point is that if you haven’t verified everything you cannot called the coding task done.

7 – You will write to be read

You should name your variables, classes and functions with relevant names. You should use a coding convention consistently, if you don’t have one yet, pick a popular one like this. You can use a tool like AStyle to automate code indentation. You should comment the less straight forward sections in order to reduce the cognitive charge needed to maintain your code.

8 – You won’t do repetitive tasks

You should automate the build process and the unit tests. You can use tools as AutoIt or scripting languages like perl, ruby or python. The overall build process and the tools used should be documented and this documentation should be kept up-to-date. Ideally, a software development environnement document should be customized for each project and out-of-the-shelf software products or middlewares should be documented.

9 – Plan for change

You should identify amongst the requirements the ones that will likely change and design the software for easy modification to reduce the effort needed to modify the code. Usually, all user visible strings and all numerical values used for initialisation are kept in separate files from the source code.

10 – Verify that your documents are good enough

You can do source code reviews between developpers for important coding sections. You can use a checklist to verify if your requirements document is good enoug to be used by the software designers and the testers. If you don’t have enough time for writing and maintaining every document, including the user manual, you should consider hiring a technical writer.

Categories: Software Development
  1. mk
    March 3, 2007 at 6:12 AM

    Re: a-webmasters-19-commandments — #20 should be; if you have a blog (http://www.josiahcole.com) then make a decision to either accept comments or not. Don’t just allow a few people to comment and then turn it off. It’s just rude and elitist.

    As for this post, I think the more “Do, Don’t Do” lists there are, the better. Problem is, the developers making those mistakes probably don’t care anyway.

    Thanks for allowing comments.

  2. March 4, 2007 at 3:30 PM

    You’re welcome. It’s too bad that some developers don’t take some of their time to improve their practice.

  3. March 20, 2007 at 7:53 AM

    10 – Verify that your documents are good enough – did you check the spacing on this one?

    you say verify that your documents are good enough yet you have a formatting issue on THIS particular item. how deliciously ironic.

  4. March 20, 2007 at 8:59 PM

    > you say verify that your documents are good enough yet you have a formatting issue on > THIS particular item. how deliciously ironic.

    lol, thx, corrected

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: