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 on 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 assume 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 that's why there are bugs in every software.
I bet a crate (Austrian for "Kasten" 😁 ) of beer that even the calculator software on Windows, Linux, and macOS produces different results when the calculations are at all complex.
So we can't 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'll 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, meaning ballast, time, money, and productivity killers. "Defects" are among the worst representatives of WASTE, as they consume a lot of resources in many different areas:
- End users lose time and patience when the software doesn't work correctly
- Software developers have to painstakingly reproduce the issues before they can work on a fix
- The entire project machinery is additionally burdened: Bug fixes also need to be integrated into the project plan, a new release is required, a new testing cycle must be conducted, and possibly even requirement descriptions need to 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 provide the most value, we need to understand the types of bugs that 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, meaning bugs that are discovered either by (ideally) software testers or (less ideally) end users.
The found bugs are thus a subset of all bugs in the software. For better understanding, I've created a rather professional Venn diagram:
It's important to understand that software testing simply increases the number of found bugs while the other measures directly aim to reduce the number of all bugs or at least keep them from growing too large.
Measure 1: Software Testing
The classic. The panacea for many (and yet often only half-heartedly executed). But as mentioned above, it's 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 found by testers rather than end users (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 key processes
- Ideally run automatically, so re-testing after expansion or modification of the software can be done quickly
What types of software tests are there?
There are different types of software tests, 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 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 two 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 on LinkedIn, Twitter or Instagram.
Measure 2: Code Quality
This topic fills books, lectures, and even entire studies. While I want to give a few tips here, I mainly want to show: It is massively worthwhile to invest in code quality, as it can significantly reduce the number of bugs produced in software. Here’s a brief overview of concrete measures we can take:
Clean Code
Mandatory reading for everyone at LEAN-Coders is definitely Clean 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 of Clean Code is: Code is written once, but read 100 times. Every time a software program is expanded, code must be read. Good code is optimized to be easily read. Even simple 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 supposed 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've never written a line of code, you can probably recognize what's going on here within seconds. Now imagine if the functionality of these 3 lines were simply programmed flat. You would first have to read and interpret dozens 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’s 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 like Clean Code I can recommend the book Clean Architecture also by Robert Martin.
It's 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 significantly.
One can usually achieve a significant benefit in a short time by looking at the most common architectures - a glance at Wikipedia is sufficient: Wikipedia Architecture Patterns
Like 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.
So it is 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 make a lot of sense for their respective applications. An MVC architecture has proven itself in the backend for APIs over the years, for example. However, if you want to implement data integration solutions in the backend, it’s 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 detect code smells
- Source 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 deployed
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 manpower. 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 nasty (cost) surprises towards the end of the project, the following components should ideally be fixed in the project plan from the start:
- 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 a thorough analysis and learning of the processes to be automated. The better you understand a problem, the more effectively you can program a digital solution that truly provides the greatest value to the end customers from the software being developed.
- Time for regular feedback & Continuous Delivery - for example, 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 essential for a long-term partnership. Thinking early about how to manage error handling processes, along with transparent communication about it, has definitely proven effective 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 customers.
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 :-)
