Writing software is already difficult; writing software fast is near impossible. And yet we perceive companies are doing it all the time when, in fact, they are not. What makes some companies appear to write quality software on-time without issue and other companies end up like Shadow Inc., who is front and center in the […]
Writing software is already difficult; writing software fast is near impossible. And yet we perceive companies are doing it all the time when, in fact, they are not.
What makes some companies appear to write quality software on-time without issue and other companies end up like Shadow Inc., who is front and center in the news this week for their app not working as expected for the Iowa caucus? We can only guess what exactly went wrong, and may never know for sure. I’m not going speculate, but rather present some facts about writing software and how to prevent bugs before they happen.
The essential factors to consider when writing software are in the “ity’s”:
Once you have a grasp on these critical concepts, you must still ensure you are developing the solution to the actual problem you are trying to solve, and we haven’t even gotten to the challenge of deadlines yet. Further, how do you deliver quality software on time without going over budget? Wait, did he just say budget? Yes, the budget just snuck into the conversation also. How can we provide this software solution on time, on budget, and have it work as expected?
People have been writing software for more than 60 years, and there are a few best practices that help mitigate the mountains of complexities that make writing software challenging. Two of the processes that help my teams deliver quality software on time and within budget while knowing the limitations of the software before users access it are utilizing Agile and Test-Driven Development (TDD).
Start by finding an ideal development process, such as Agile. Agile is a mindset, and there are multiple ways to implement Agile such as Scrum, Kanban, etc. Agile practices allow software developers to deliver small fully working functionalities in short (usually two-week) development cycles, allowing the most critical and high-risk features to get thoroughly tested by the time the system goes live.
Have you ever used software and an old bug appears again and again? Worse yet, have you ever seen an entire functionality stop working after another feature in the software was updated? We all have; these are known as regression bugs. When creating software, you can write code, known as “code tests,” that verifies all code is doing what you expect it to do. It’s like creating a built-in audit for your code, but before you even write it.
There are many benefits to writing these code tests. For starters, they are repeatable, meaning they can run over and over again. Every time new features are implemented, or bugs fixed, all tests can verify we existing functionality was not broken, allowing us to bid adieu to regression bugs. Knowing the new code broke existing software as soon as it’s written it allows us to address the issue immediately; not once the software has gone live for millions of people. 6 Compelling Benefits of (TDD) Test Driven Development is a great article for those interested in a deeper dive into the benefits of implementing TDD in an Agile environment.
We should know if our software works before it is used, especially in an environment as paramount as the Iowa caucus. As not only customers, but citizens, we are entitled to expect more. It’s time to raise the bar on best practices and proper testing by valuing companies with great track records and properly vetting companies that are growing.
Exelaration continues to build on our past successes in developing complex software in an Agile environment. We finish projects on time, leaving our clients happy and educated on how to avoid these issues going forward.