Index

How to Write Good Software

Chinese translation is available.

Widely accepted tools and languages

Good software is written in language that is widely used. That guarantees that there are people who can read and modify the code. Good languages, for example, are C, Python and Java. There are of course exceptions where some less used language is a better choice.

Keep it simple

Good software doesn't do things it doesn't need to do. In other words there aren't unnecessary features. Implementing features that no one uses will only introduce bugs. Keeping things simple should be a top priority when designing software. Like Albert Einstein said; "Make things simple as possible, but not simpler."

Too much abstraction is bad. If you hide the code behind multiple levels of abstraction you will also hide the bugs. Too much abstraction makes the code hard to understand, makes it hard to follow the execution paths and it makes it hard to debug. Often it will also decrease performance. Abstractions over abstractions are often a problem found in enterprise software written in Java. Good software can be written in Java, but Java also makes it very easy to write horribly over complicated code. Same goes for C++.

Don't make it rocket science

Use variable names that has a real meaning. Don't use one character variable names. They're almost impossible to understand and to keep track of. There are one character variable names that are commonly accepted. For example in coordinates, it OK to use x and y. In for loops it's OK to use i, j and so on. Other than that, do not use them. Generally, in good software the code is structured in a clean manner and there are documented coding conventions available.

Documentation is important

Despite how boring it might be, good software is documented. Code has comments that are meaningful, software has manual pages which are installed with the software. For web applications, make the documentation available online.

Often developers think that it's enough to write the documentation once the software is done. That's completely wrong approach. Documentation must be a thing developers do while they develop the software. Documentation is part of the development, not something you do after the code is written.

Use a version control system

Good software uses version control system. Always. Nowadays, I will almost always recommend Git for version control, but there are cases where something like SVN does the job equally well. Version control makes it easy to roll back possibly problematic changes. Consider the following example what could (and will) happen without a version control system:

      Developer A makes a change in a file program.c. The file program.c
      is copied over to the source tree and the old file is replaced.
      Later on a bug is found that originates in the changes developer
      A made for the file program.c. Developer B,C etc. will have hard
      time finding out what was the change developer A made. With
      version control system this would not be a problem. Developer B
      could easily see what the change causing the bug was. Of course any
      smart developer team should have backups, so in this case they could take the
      original backup before the change and use diff tool to see what the change was.
      However, that takes time and is a hassle. Not to mention how error prone
      it's to copy files over from backups and replace the files.
    

Extensibility

Extensibility is not strictly a requirement, but often it makes the software more useful. One good approach is to develop the software so that it can be used together with other programs.


Copyright © 2017 Niko Rosvall