There are an estimated 10^82 atoms in the visible universe.
The source code of my last API was about 3MB in size (not counting libraries/frameworks, of course...). That's 24 million bits, which can take about 10^722772 different states. That's unimaginably more than atoms in the universe. If just a single bit is not set correctly, you can already assume that we are dealing with a bug. (Yes, I know the comparison isn't quite right, but you get the point...)
One thing is clear: Software is incredibly complex, and therefore there are bugs inevery software.
I bet a crate (Austrian for"Kasten"😁) of beer that even the calculator software under Windows, Linux, and macOS will produce different results if the calculation performed is at all complex.
So we cannot prevent bugs from appearing in software projects. But we can try to minimize the number of (critical) bugs. In this article, I will present three central measures:
- From the perspective of software testing
- From the perspective of programming
- From the perspective of project management and procurement
In less than 10 minutes of reading time, you will learn how to significantly improve your software projects, because one thing is clear:
Bugs are one of the worst types of WASTE ever!
The LEAN software development method defines seven types of WASTE, i.e., ballast, time, money, and productivity killers. "Defects" are among the worst representatives of WASTE, as they cost a lot of resources in many different places:
- End users lose time and nerves when the software does not function correctly
- Software developers have to painstakingly reproduce malfunctions before any correction can be worked on
- The entire project machinery is additionally burdened: Bug fixes must also be integrated into the project plan, a new release is needed, a new testing cycle must be conducted, and possibly even requirement descriptions must be revised
Bugs have varying impacts depending on when they are found:
To prevent the worst, it is essential to conduct software testing phases. However, it is also important to try to avoid bugs as much as possible - even during requirements gathering and programming. In this article, we will also discuss ways to actively combat bugs during these phases.
It quickly becomes clear that any initiative to avoid bugs saves massive time and costs in the medium term. To find out which steps create the most value, we need to understand what types of bugs exist:
Two types of bugs
There are various categorizations for bugs/defects. For this article, only one of them is truly essential:
- Category 1: All bugs that exist in a software program
- Category 2: "Found" bugs, i.e., bugs that are either discovered by (ideally) software testers or (not so ideally) end users.
The found bugs are thus a subset of all bugs in the software. For better understanding, I have created a rather professional Venn diagram here:
It is important to understand that software testing simply increases the number offound bugs while the other measures directly aim to reduce the number ofall bugsor at least prevent them from becoming too numerous.
Measure 1: Software Testing
The classic. The panacea for many (and unfortunately often only half-heartedly implemented). But as mentioned above, it is important to understand exactly what software testing does:
- Software testing shows us a subset of all the bugs present in the software. Software testing does not prevent bugs from entering the software.
- Software testing helps ensure that bugs are less likely to be found by end users, but rather by testers beforehand (better customer experience)
Software testers do detective work and search for bugs. There are now many experiences and theories on this. Ideally, software testing is set up as a structured process based on best practices. A good software process can be optimized to:
- Find those bugs that would most disrupt program usage
- Test the most important functions in the program with as many combinations of data and user behavior as possible, ensuring smooth operation of the most important processes
- Ideally run automatically, so that re-testing after expansion or modification of the software can be conducted quickly
What types of software tests are there?
There are various types of software tests, which are usually conducted by different engineers:
- Unit tests - yes, dear programming colleagues... this is our area :)
- Integration tests - useful depending on project size to test the interaction of individual components
- System tests / End-to-End tests: The "classic" software tests conducted by the testing team. Nowadays, a lot is also automated in this area, and especially for web-based technologies, there are numerous frameworks available.
- Acceptance tests: End customers should also briefly check the software before it is released. Any misunderstandings that may have occurred during requirements engineering can be uncovered here before release.
In agile software development with Scrum, for example, the entire software development process is run every 2 weeks. This is usually only possible if the software tests are highly automated. Corresponding development capacities must be fixed in the project plan.
Are you a software tester or interested in a career change into this field? We are always looking for motivated technicians - just send us an email or a message onLinkedIn,Twitter orInstagram.
Measure 2: Code Quality
This topic also fills books, lectures, yes, entire studies. I would like to give a few tips here, but above all to show: It is massively worthwhile to invest in code quality, as this can significantly reduce the number of bugs produced in software. Here is a brief overview of concrete measures we can take:
Clean Code
Mandatory reading for everyone at LEAN-Coders is definitelyClean Code by Robert "Uncle Bob" Martin - available on almost every book sales website 😁
The basic principles can also be learned on YouTube.
The core message ofClean Code is: Code is written once, but read 100 times. Every time a software program is extended, code must be read. Good code is optimized to be easily read. Even the simplest measures can contribute to making code significantly more readable:
- Descriptive variable and function names
- Short functions
- Little code branching within individual functions
- Structuring functions hierarchically. For example, if a function is to read the content of a file and then save that content in a database, one could write a "high-level" function that looks something like this: const fileContent = await readFileContent(path) const dbData = transformFileContentToDbModel(fileContent) saveContentInDatabase(dbData) Even if you have never written a line of code, you can probably recognize what is happening here within seconds. Now imagine if the functionality of these 3 lines were simply programmed flat. You would first have to read andinterpretdozens of lines of code before you could grasp the "big picture". The introduction of these 3 additional helper functions pays off here because readability is significantly increased. Moreover, functions can also be reused - that comes as a bonus.
If you want to learn more about Clean Code, you can also check out the lecture series by the author himself:Clean Code - Uncle Bob / Lesson 1
Software Architecture
Software is usually (more or less well) divided into individual components (functions, classes, modules, ...). How this division is made, and how the individual components are ultimately wired together to form a cohesive whole, is determined by the software architecture.
This topic can also fill entire books and studies. For a first introduction, and if you likeClean Code, I can recommend the bookClean Architecture - also by Robert Martin.
It is important to understand how crucial the selection/creation of a suitable architecture is for our software. Often, enormous focus is placed on design patterns, but the architecture influences the structure of our software even more strongly.
A significant benefit can usually be achieved in a short time by looking at the most common architectures - a glance at Wikipedia is sufficient:Wikipedia Architecture Patterns
As with design patterns, it is not crucial to memorize all architecture patterns. But one should have a basic overview of what architectures exist and what problems can be solved by "standard architectures". The details can always be looked up as needed.
It is therefore worthwhile to think about the architecture at the beginning of a software project, or whenever new subsystems are created. There is no one-size-fits-all solution. This is often implicitly assumed because modern frontend and backend frameworks already prescribe architectures. These also make a lot of sense for their respective applications. An MVC architecture has proven itself in the backend for APIs over the years. However, if you want to implement data integration solutions in the backend, it is worth looking at the Pipes-and-Filters pattern. The integration subsystem can indeed have its own architecture and can be embedded in the (MVC) API - or even developed completely as a standalone system...you get the point, right?
Technological Helpers
Additionally, there are some tools that can potentially make our lives easier and improve our code quality, including:
- Linting to automatically detectcode smellsSource code management with PR reviews to review the code immediately after creation
- Automated CI pipeline to systematically and consistently execute linting and automated software tests before parts of the program are released
- Measure 3: Project Management & Sales
We don't program (only) for fun. In most cases, the available resources are limited: time, money, and ultimately pure labor. The success of a software project is directly related to the number of critical bugs produced during programming and not caught during the testing phase. To avoid unpleasant (cost) surprises towards the end of the project, the following components should ideally be fixed in the project from the beginning:
Time to set up a high-quality tooling environment
- Automated CI pipeline
- Time for creating automated software tests
- Time for creating and conducting manual software test cases
- Time for fixing critical bugs
- Time for accurately analyzing and learning the processes to be automated. The better you understand a problem, the more likely you can program a digital implementation that allows end users to derive the greatest value from the software being created
- Time for regular feedback & continuous delivery - e.g., agile with the Scrum method
- We can't find them all
No matter how hard we try: Bugs will always occur in production software. Good handling of bugs and corresponding customer service inquiries is therefore the be-all and end-all of a long-term partnership. Thinking early about how to handle error processes and having transparent communication about it has definitely proven itself in practice.
A never-ending story
Software bugs are immensely costly and will always accompany us, that much is clear. However, there are means and ways to reduce the number of bugs in delivered software and ultimately generate more VALUE for end users.
In addition to developing custom software, LEAN-Coders also offers consulting around the software development process - from reviewing existing processes to training and workshops, because our mission is clear: We want to spread the LEAN mindset to the world - step by step :-)
WASTE Alert! 3 essential measures against bugs in Sof...
