Truth and Lies in Software Development

The essence of computing, as everyone who is reading this probably knows, is truth. 0’s denoting false and 1’s denoting true. At that very low level software development has something on other activities and professions at least in regards to its fundamental building blocks.

Larger scale phenomena have more complex relationships to truth. A building either satisfies or pleases it’s inhabitants or it fails to do so. There is a truth there at least at an individual judgement level. A person either likes the building or he doesn’t. Like is subjective, which means that what is true for some persons, namely that ‘it is a good building’ will not be true for others.

Finished software can have similarly subjective evaluations. A program can be good or bad. A website can be easy or hard to navigate. An API can be straightforward or squirrelly to use. The statement: “the API is a good one” is subjective. In it’s day Java Swing was a great API, yet if you showed it to a modern Javascript React/Redux programmer, they would judge it anything but.

 if( 1 == 1 ) 

Yet at it’s core software is simply about truth.

When the above comparison is made, some form of compiling, runtime or hardware logic is going to create two little memory locations and compare if the two numbers are in fact the same. Here they are. A very clean truth.

A couple of levels higher from the above if statement might be a unit test. The unit test either passes or it fails. The code either performs as expected or it doesn’t. A unit test is isolated. The inputs and environment is simplified. A block of code should not produce a false result due to a down database when run in the scope of a unit test. This is comforting. Unit tests give developers and their managers confidence that an application’s code is built on a sound foundation. The individual stones have been tested. The building should stand the test of time.

Larger scale phenomena are not evaluated so simply. Is it a good program? A console program that sorts an array of numbers and outputs the sorted numbers could be called good if does its job in a reasonable amount of time.

numberArray set = [34, 2, 10, 500, 3, 1, 10];
sortAndOutput( set );
Sorted Array:
1
2
3
10
10
34
500

Simple enough. Yet if the program took 10 minutes to do the job we would not consider it a good program at all. Or if crashed because there were two 10s.

As building blocks become more complex judgement comes into play. The statement “it is a good program” is not so clear as a unit test or the if statement was. This is the beginning of a problem for software programmers, and their managers, and it is one I would like to dig into more deeply in subsequent writing.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.