In addition to the code that developers write from scratch, they are often using 3rd party modules to incorporate more functionality. Payment processing is a great example. There’s no reason to build a payment processor from scratch if you can incorporate one from an existing provider like Stripe. API’s (application program interfaces) are another popular way to incorporate other features and data into an app. If you want to incorporate live weather data, the developer will find an open API to connect and provide that data. Another layer to account for is the hardware and software the application will run on. For example, a mobile-friendly web app has to be able to run on at least the last two versions of Windows and macOS, at least the last few versions of Chrome, Firefox, and Safari, and that same set of mobile browsers for the last couple versions of Android and iOS.
With all these frameworks, versions, modules, APIs, operating systems, and browsers, there’s one more technical hurdle; updates. In most cases, it’s best practice to try to stay current with updates. Since updates involve changes to the code, it can have major impacts on how applications run and need to be monitored with constant testing before updates are rolled out.
That said, managing this stuff is the easy part. A foundational concept in software development is modularity. This basically means that software is written in chunks that are supposed to be independent of each other and then tied into one big app. This allows for new features and upgrades to happen in one part of the app without affecting the other parts. Easier said than done. Since all parts of the app usually work together in some way or another, adding or changing code can cause bugs in places that you wouldn’t expect. The result here is that, just like before, extensive testing is needed to make sure that super cool new feature doesn’t break the rest of the app.
I’ve saved the best, and most importantly, for last. This is by far the biggest cause of bugs in the software development process. But first, a point about the term, bug. According to Wikipedia, a bug “is an error, flaw or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.” This means that something is only a bug if the expectation you have is different than what happens in the software.
So…the biggest reason bugs appear in software is unclear expectations and requirements. Go ahead and open your most used app. Is it Twitter? Instagram? Candy Crush? Now click on buttons, notice the animations and page layouts, think about what the app is doing when you interact with it. Everything you see and every action the app performs is intentional and has anywhere between a single line to thousands of lines of code to make it work. And that’s just the frontend. If the time isn’t taken before development starts to carefully document requirements, the project is off to a terrible start. Now the development team starts making assumptions about what the requirements are. When testing begins with users, their expectations are different than the developer’s, so they report “bugs”. But the development team doesn’t see it that way. They coded things to work exactly like they are and are not happy when you tell them to redo their work. And just like you don’t want the people making your food to be mad at you, the same is true of the people building your business-critical applications. All this to say that good communication, clear requirements, and detailed feature roadmaps are essential to reduce the number of bugs of any given software development project.
Bugs will always happen; perfect software doesn’t exist. It’s a complicated process with lots of people, teams, technologies, and no two projects are the same. A good development team will have the processes and experience to mitigate problems before and when they eventually arise. FarShore is one of those teams so reach out if we can work together on your next (not-so-buggy) website or app.