My Personal Manifesto of Software Engineering

Quality

I have read enough unclean source code to recognise it as such, and it was foolish to claim that i have never written such code myself. In this section i want to describe what i understand to be bad quality program code.

On a general note, what i understand as „unclean code“ is code that lacks transparency; such code, when provided as a software that is to solve problems of the real world, is a variation on the approach of keeping away relevant parts of the solution from the user or purchaser of the software.

Unclean code usually shows these symptoms:

  • No convention on formatting is upheld. This is the most significant indicator, because besides impeding analysis of what the program actually does it also makes it more difficult to understand if the code itself meets any of the other criteria described below. If code is formatted uncleanly, it is a safe bet to assume that the following symptoms also occur.
  • Names have no meaning or the wrong meaning. Object references are called $tmp2, loop conditions are called $goon, and functions spanning 1500 lines of code are called runItNow().
  • Silly workarounds persist. At some point it was neccessary to have the frontend running even though the layout was not complete, so it was released, even though it will break if the screen pixel density exceeds 160.
  • Copy and paste is all over the place, massive structural redundancies occur. All those meaningsless names and silly workarounds have been copied along and now persist throughout the program in a variety of revisions and mutations.

Further indicators are

  • dependencies on specific behavior of the environment of software development, and
  • dependencies on specific properties of the installation environment.

Above indicators may or may not be justified by the problem that the software actually addresses.

It may be acceptable that a program producing a website for a specific customer only works on the Linux operating system, if that explicitly is what the customer wants to run it on, but it is probably not acceptable if the program only works if installed on a host computer called „foo“, into a directory called „bar“, functions only on business days between 9am and 5pm, and only if bound to a domain name of  „baz.blah“.

It may be acceptable that a software only compiles when using the Microsoft C++ compiler if that is what the customer explicilty has ordered, but it is not acceptable if the program breaks unless it is compiled on computer „X“ with IP address „Y“ by user account „Z“ using compiler version „1.2.3“ and will fail to compile in any other setup unless disproportionate effort is invested.

In short, bad code causes problems, and lack of transparency is just one of them. Thus, problems that are solved by bad program code get replaced by several different problems. These problems are actual, and they generate actual costs.