Troubleshooting Steps: Most Software is Broken, But Here is How to Repair It

### Why is Software Broken?

Software is broken most of the time. You probably don’t think much about it, but then again, when Microsoft or Apple push out an operating system (OS) update, you don’t pause to consider that, either. Those updates, usually automatic, fix bugs, patch security holes, and correct other problems.

In fact, the idea that software can be bug-free is a myth. No matter how amazing your process and methodology, you will launch an app, website, program, or operating system with some bugs.

One reason software is broken: the enormous complexity that comes with creating programs and apps. When people first began building software, the code was oversimplified, a leftover methodology from the days of calculating. Errors began appearing when software grew more complicated.

Why Software Breaks & How to Fix Broken Code

The first approach on how to fix software: Testers. For software troubleshooting steps, companies would release an Alpha version to a select group. Then, they cleaned up the code, fixed the bugs and then released a Beta version to a larger group. Once the Beta was in the wild for some time without issue, the program was released as production quality. Organizations still do this today.

A software engineer and professor of computer science at the University of Idaho called this methodology “cave art.”

“It’s primitive,” John Munson told Fast Company. “We supposedly teach computer science. There’s no science here at all.”

Of course, the Alpha-Beta approach was one step ahead of just releasing software with the assumption that it would work. Such was the case with Oracle version 2.0, named that to give the impression it was more established. Users found bug after bug.

The second solution to fix broken software came along when developers began using an architectural approach to building programs. By relying on the architecture principles for buildings, engineers form a stronger process of development and create better results. While this method has made significant improvements to software, the complexities remain.

Further, another reason for broken software lies within the business: speed. Many companies want to push, push, push the product out the door as fast as possible, whether the code works well or not. The idea is that you can always fix it later with patches and updates.

Another innovation or third approach to improve software is the use of Object-Oriented development. {Link to our post: 2018 Solutions: How We are Heading Toward Do-it-All Universal Software.} Coders reuse sections of code, called modules, for specific tasks or parts of a program. As they are used repeatedly and therefore tested regularly, they become better.

Object-oriented code may or may not have made improvements, but because companies are always pushing faster, it’s hard to say. Companies like Microsoft released large projects in record time. While they made great use of Object-Oriented Programming, the quick development cycle left little time for proper testing.

Another cause for broken code: culture. When you picture a programmer, you might imagine a group of young men, sitting around in grungy clothes, living on chips and soda, coding late into the night. This image somehow became glorified, but it’s more akin to the late-night college cram for finals than how business should operate in the real world. As Fast Company pointed out, those serious about perfect code, such as NASA’s space shuttle team, take a far more structured approach to code — as they must because people’s lives are on the line.

“Most organizations launch into even big projects without planning what the software must do in blueprint-like detail,” the author writes. “So after coders have already started writing a program, the customer is busily changing its design. The result is chaotic, costly programming where code is constantly being changed and infected with errors, even as it is being designed.”

Sound familiar?

Fixing broken software will require changes on multiple fronts. For example, the push for speed and the company culture surrounding the development team are two things companies will need to address. As companies mature in their approach, perhaps we can emerge from the “cave art” days and into something better.

Meanwhile, development teams must tackle the software itself. Many are now are pushing to measure software complexity. While software may require some complexity to function, many programs have added layers of unnecessary code due to poor design. By testing a software’s complexity, programmers can clean things up and simplify applications, making them less prone to breaking.

Developers are also now considering risk-based architecture. Every feature or requirement added to a software project also adds a definable amount of risk. The more risk, the harder it is to build without issues. By architecting a project with that in mind, we can consider and then decide whether the additional features are worth the risk.

The use of Artificial Intelligence (AI) will also change software programming. AI is now used for more front-facing tasks such as customer support and entertainment, but holds promise in improving our software. Humans can only test a small number of scenarios, even with a large group of people. The actual number of situations needed for an exhaustive test may be near infinite. However, an AI system can learn what is most important by monitoring issues in the wild (software currently in use), then developing its own test criteria for future releases. Also, with AI code could self-test and make corrections on a regular basis.

Talk to us about crafting clean code and using AI to improve the process.