Bugs Should Be Fixed Before Being Found

An Incredible Acceleration in Releasing Software

by
Jarosław Błąd
Vertabelo Product Manager

Posted: November 20, 2014

There are many signs that our civilization is on an exponential growth path and, based on my own observations, there are signs of this growth in the area of software engineering. A few days ago yet another Vertabelo user expected an immediate production update for a small bug fix. It led me to think about how often software was released due to bug fixing from the historical point of view. I started in the 80s when personal computers became very popular and, as consequence, a software market for customers was born.

Let’s take a look at how software releases started out and how they’ve sped up over the years.

Software Releases in the 80s

In the mid 80s, releasing software due to bug fixing was very rare. New releases were related to new features rather than bug fixes. Do you remember patches for the River Raid game or the Visicalc spreadsheet? I don’t. I think there were two simple reasons for the dearth of bug fix releases:

  • The software was really small. Think about 20-30kB binaries. So it was possible to test software deeply.
  • The distribution process was cumbersome and complicated. Everything was distributed on physical mediums - audio cassettes, floppy disk or cartridges. There were no efficient ways to distribute patches. So software had to be ready to work for years without changing (see previous point).

Of course, this doesn’t mean that software from the 80s didn’t contain bugs. Bugs existed but usually weren’t big and destructive to the software’s main functionality. So bug fixes and new features went together in new software releases. Years passed between releases.

Software Releases in the 90s

Things started to get even more complicated as the software grew bigger and bigger. In the 90s we talked about megabytes not kilobytes, which quickly transformed into CD size (650 MB). Bigger and more complicated software meant more bugs that couldn’t be eliminated during testing and the release process.

Users started to complain about quality and enforced shortening the development/release life cycle. However, software distribution was similar to how it was in the 80s. Customer pressure from one side and limitations in distribution from the other side meant that binary patches became an everyday reality. If you took any CD attached to 90s software magazines you saw tons of binary patches for existing software. This way, time between releases shortened to about half a year.

Software Releases in the 2000s

The Internet revolution that exploded in the 2000s changed everything about the software distribution model. Physical mediums died. Software as well as software patches were distributed over the Internet. In the case of downloadable software, the time between releases shortened to a month or less. Also a huge number of internet applications emerged and installing a new version of software became extremely easy. This movement also increased user expectations in terms of the time required to release bug fixes.

Software Releases in the 2010s

The 2010s seem to be the twilight of downloadable software. Now you can do most of your work by using Software as a Service (SaaS) applications in a Cloud environment. Everything runs directly in your web browser, which has became some kind of operating system for your apps. However, a web browser is still a standalone (downloadable) application.

From a bug fixing and software release point of view, the Internet revolution has left a huge imprint on user behaviour. Being online all the time, users expect the same from the software they use, including SaaS applications. This demand presents two main challenges:

  • High availability requirements for services. Zero down time is expected, which causes complications in deployment processes and infrastructure.
  • Shortened bug fixing time - once again. From my observation, users can accept a turnaround time of one day to fix a serious issue and a few days for minor one. Just try leaving a critical bug unaddressed for a few days and then read user forums. With luck, not fixing a critical bug immediately won’t kill your business.

As you can see on the following picture, software release time shortened from years to days over last thirty years. From this picture you can draw a classical exponential curve.

Accelaration in software release cycle over the years

Software Releases in the 2020s and Beyond

Extrapolating user expectations, we will soon see a bug fixing time near zero. How will we achieve this? Two approaches come to my mind:

  • In an ideal world, the software shouldn’t contain any bugs. Looking at the way software complexity grows, this seems impossible.
  • Shortening bug fixing time.

Bug fixing requires time to do four main activities:

  • bug analysis
  • fixing
  • testing
  • delivering fix to end-user

The third and fourth items in that list can be automated, but what about the first and second?

From the human perspective, it is hard to imagine that we can analyse and fix a bug in less than an hour (assuming that we have great tools and the nature of the bug is not complex). This way, the expotential process of shortening bug fixing time will saturate and won’t go any further. It may be an unsatisfactory solution for users. Lets try to go further.

The next natural step is to give all activities to a computer. Is that possible? Can a computer fix bugs itself? I think yes; the only requirement is to write a program which can analyse and modify another program (or even better, modify itself). This idea is not new and works in some narrow matters. But the problem is writing a program that can analyse and modify any program. It requires some form of intelligence. It’s hard to predict and can be treated as science fiction for now, but nobody knows what will happen in the future. As far as I know, there is no formal evidence that another form of intelligence can’t be born.

Lets assume that such intelligence can take the form of a computer program. It is obvious to me that we will be responsible for writing such computer programs before computers start programming themselves and finally programming us. Are you afraid that you will be replaced by a machine? As someone in the middle of my life, I’m a little bit afraid. But if you are younger...

 
 

Try our online database modeler. No registration. No commitments.

 
 
Tags
 
Subscribe to our newsletter

If you find this article useful, join our weekly newsletter to be notified about the latest posts.

 
 
 
It's Time to Master Python Gain practical knowledge of Python or prepare for a coding interview. Let's Do This Other Python courses: