Is the software development industry trapped in a cycle of being ‘perpetually immature’?

A while back an xkcd comic on Voting Software attracted a lot of attention on Twitter for it’s alarmist comparison of the attitudes of the software development industry to other engineering disciplines and in particular, this statement:

“our entire field is bad at what we do, and if you rely on us, everyone will die”

Voting Software

This was widely shared and quoted on Twitter, and even shared by industry leaders such as Grady Booch:

There was one comment in reply to Booch’s tweet that particularly resonated with me:

“I fear that perpetual adolscence is our curse and our gift – (we’re) always chasing the next shiny thing”

Joerg Muller-Kindt

This thought that as an industry we’re stuck in “perpetual adolescence” caught my attention. As an industry we struggle to advance. What’s unusual when you think back over the past 20 years and even further back looking at the history of our industry, there are developments and ‘movements’ where groups of individuals come together to champion an idea that at first seems to make a positive improvement to our industry as a whole, and then over a few more years the ideas fade away and seem to be forgotten. Some are even occasionally rediscovered again by another group of like-minded individuals years later.

The ‘perpetual adolescence’ of our industry as I see it is not that we’re stuck at a particular point in our industry’s growth and unable to progress, we do progress and advance. This growth however, appears to be in short cycles where we move forward, but then we go back to what we were doing before, and we’re stuck in a cycle of discovery and rediscovery. It’s not as bad as one step forward, two steps back, but it does appear to be something like one step forward, one step back. We’re never continually advancing, occasionally we move forward but we end up going backwards again. The progress of our industry never seems to be continually moving forward. Maybe this is typical of any industry in its infancy.


  • The ‘software crisis‘ of the 1970s
  • Structured Analysis and Structured Design
  • Formal methods
  • 4GL development tools focused on developing specific styles of application (e.g. PowerBuilder, and client/server type systems)
  • The hype of Object Oriented languages
  • Fred Brooks seminal article “No Silver Bullet
  • CASE (Computer Aided Software Engineering) tools and code generation – mid 1990s
  • UML, Rational Unified Process (RUP)
  • The Agile Manifesto
  • The cycle of centralized vs decentralized (distributed) systems
  • The hype of Functional languages
  • Strongly typed vs dynamic languages
  • Platform independence vs platform dependence (of languages and technologies)
  • Software development as an engineering discipline or an art, and everything in between
  • Serverless, as the solution to all problems

There’s plenty of other ideas and concepts that could be part of this list, and I’m not highlighting anything in my list to say these ideas good or bad, but when you look back it’s interesting how ideas come and go over time. People come and go too, some noticeably bringing new ideas and passion with them, sometimes rediscovering ideas again from the past. Sometimes as champions leave the industry their ideas no longer have a voice and their ideas disappear with them too.

If our industry is still in its infancy, is this cyclical, repetitive behavior just the industry trying out new ideas to see what sticks? Or is it that the people actively involved in championing ideas come and go too, bringing ideas in and sometimes taking ideas with them when they move on? Does this mean that as an industry as experienced developers leave the industry and new generations of developers come in, are we doomed to continually repeat our mistakes of the past?

Why do we Unit Test (and what’s the purpose of Code Coverage)?

What is Unit Testing? Unit Testing is the approach of testing the smallest parts of our code in isolation from other code. In Java these are methods in our classes. In Javascript these are our functions.

There are many unit testing frameworks that help us with our unit tests. In Java we have JUnit and TestNG, both have been around for a long time. The key part they help us with is making ‘assertions’ about the results of our code under test, to check the results and confirm when we call our code, it returns the expected results.

Why do we Unit Test? As developers we want to know our code works, that it does what it is supposed to do. We use unit tests to give us confidence about our code, so we know it works.

We can use unit tests to help with code changes or refactoring efforts to improve existing code. If existing tests are available, you can use them to check that they are showing you were the issue is that you need to fix (assuming there’s a test for that part of the code), or check that the existing code is working before your refactoring changes.

A typical flow for using unit tests to help with a defect fix looks like:

Run test, confirm test fails. Make code fix, confirm test passes. If the unit test for the related code doesn’t have an existing test for the code where the issue is, add a new test. Write a test for the expected result which should initially fail, rerun after the code fix and now the test should pass to confirm your fix is working.

Run other related tests in the same area to check there are no unexpected impacts to other existing code.

We can also use unit tests as part of a CI/CD pipeline – when our tests pass, the code is ready to include in a new build, and depending on your development process, ready for additional tests, integration testing, UAT testing and promotion into production.

Many industry studies have shown that it’s always cheaper to find and fix defects in our code earlier than later. The time invested to develop unit tests saves us in the long run if we can find issues earlier and avoid finding issues later, e.g. in production.

Any number of unit tests does not prove that our code is 100% correct however, neither does it prove the absence of bugs. If our unit tests are effective though, they can give us confidence that our code is working as expected for a range of tested inputs.

What is an effective test?

An effective unit test must have assertions to check and confirm the code when executed with given parameters returns the expected results. In JUnit, the framework provides a number of assert statements, like assertTrue(), assertEquals() that you use to confirm the expected results.

A unit test without assertions that only calls the code under test is not an effective test. Without assertions, the test is useless if you’re not checking the expected results.

Similarly for assertNotNull(). If the only thing your test does is check that there’s a non-null result, this doesn’t confirm that the code is returning the expected result, it only confirms a value is returned. This is not particularly useful when we expect a unit test to confirm that the code is returning the expected results (i.e. it is working).

For any given method that takes parameters, you should have a range of test methods to confirm the expected results for that range of input values. You should obviously test with expected/valid input values, but you should also test with a few unexpected/invalid values: high values, low values, empty, short and long strings. In all cases you should assert and confirm that the method returns the expected results.

How does Code Coverage relate to Unit Testing?

Code Coverage tells you how much of your code was execute by your tests. As a tool it is useful during the development of your unit tests, because it helps highlight where your tests may have missed paths through the code. For example, if the code you are testing has an if..then..else condition and your test calls the code with parameters that causes the if condition block to be tested but not the else block, Code Coverage helps highlight untested code.

The problem with Code Coverage though, is that by itself, Code Coverage is not an indication of effective tests or even working tests. If you have a test without an assertion that calls a method with a single block of lines of code and each of those lines executes, Code Coverage will report 100% coverage on this block. Without an assertion, this test doesn’t test that the code works, and therefore is worthless. It does have 100% Code Coverage though. This is why relying on Code Coverage alone is not useful, or sensible, because it doesn’t tell you how effective your tests are. It only tells you how much of the code was executed. Code that is executed by a test but is not confirmed if it is returning expected results or not with assertions, is just executed code, not working code.

Remember your assertions.

Use Code Coverage as a tool to help you find untested code, not as an ultimate goal: writing tests to achieve Code Coverage is not useful. Developing effective tests is your goal.

My software development blog posts from 2018: AWS, Twitter bots, Machine Learning, Docker, Kubernetes and more!

Looking back, I’ve investigated and played with a lot of interesting stuff this year, I was pretty busy 🙂 Early in the year I was doing a lot of experimenting with AWS as part of my prep for the AWS Solution Architect Associate exam, so a lot of my posts this year were AWS related, but I did some a some time working on some other projects too.

Here’s a look back at some of my favorite personal projects and blog posts during the year:

  • Using AWS Sagemaker to train Machine Learning models – here and here
  • mvmdvm and Pi-Star setup – multi digital voice Amateur Radio modes on a Raspberry Pi – here and here

Phew that’s quite a lot! I sincerely appreciate the feedback and comments I receive on my posts and hearing that at least some of my content is useful to others. I look forward to continuing to share my thoughts and write more content that hopefully will be continue to be useful in the coming year.

Happy New Year!

Observations about common IT technologies in 1988-89

Sometime around 1988-1989 I did some part-time data entry work for an IT Recruitment Agency that my Dad worked for. Tucked away in some papers I found these two sheets listing a range of different programming languages and other in-demand software packages/systems at the time. From memory, I think this list was what I used to code each of the job applicants tech skills as they were entered into their recruitment CV/resume database.

There’s many things interesting about this list from 30 years ago. The first that caught my attention is how many of the tech skills on this list are no longer in use today, and some I’ve never even heard of since.

The second point that’s interesting is how many technologies and languages we commonly use today are not even on this list, meaning they were developed and introduced at some point after 1989. Every web technology in common use today was introduced after this point – HTML, CSS, JavaScript and any of the various popular JavaScript libraries, all introduced at some point after 1989.

Even other popular languages and frameworks/platforms, Visual Basic, Java, .NET, Ruby, PHP … all introduced after 1989.

This reinforces the fact that commonly used IT technologies come and go pretty quick, and what’s common today can easily be replaced with something else tomorrow. If you’re planning to stay in IT for the long run (longer than a few years), be prepared to keep your skills up to date, stay flexible and adapt to change.