The evolution of mistake-making

Alexander Pope once said that “to err is human”, but when it comes to software engineering, who’s to say how much simple mistakes cost development firms in financial, reputational and clientele terms? 

Throughout the past 35 years leading in the software development space, BBD has tracked how companies formulate new approaches and methodologies to limit human error and curb mishaps and mistakes, and how they try harder than their predecessors did.

With the advent of each new methodology, the tech world overall is compelled to reflect on its track record of mistakes, consider where it has come from, and look to how the current approach can further improve this proclivity for mistakes. Two of BBD’s foremost Agile practitioners, DevOps disciple Patricia Draper and architect David Wilson, trace the evolution of software development mistake-making and how these mishaps ultimately lead to improved ways of working.

Waterfall: We all make mistakes

Developed in the 1970s, the Waterfall methodology was the first truly prescriptive software development process that dictated just how the software development life cycle should unfold. The method places emphasis on the logical progression of steps throughout the development life cycle, starting with the definition of requirements through to the maintenance of the final product. 

While the methodology forces a structured approach to organisation and output, and is well suited to milestone-focused development, it is not adaptive in nature, neglects client involvement almost entirely and delays testing up until the final phase of the cycle. The major downfall of Waterfall is the expectation with each step that the previous step was completed adequately and completely, leaving no room for error or iteration.

Agile: We all make mistakes… but quickly

This flaw in the Waterfall approach meant that delivery took a considerable amount of time, especially if development needed to be backtracked for changes or improvements. “As such, Agile was conceived and defined by the 2001 Agile Manifesto, which prioritises interactions over processes, software over documentation, collaboration over negotiation and responding to change over following a plan,” explains Draper. 

“Agile is iterative in nature, it is team-based, and it emphasises rapid delivery and a ‘fail fast’ mentality,” adds Wilson. 

A project is tackled in bite-sized iterations known as “sprints” and allows for high customer involvement. The only major sore point of the Agile approach is that timeous delivery can become a problem if priorities and outcomes don’t align, ie if work is budgeted for a time frame but is not completed as anticipated. 

Another concern is the potential for scope creep as a result of the temptation to adjust deliverables, because of the flexibility that iterative development offers.

DevOps: Let’s make less mistakes quickly and collectively

Although ideal in theory, Draper and Wilson assert the following: “While Agile sees development teams working more effectively and continuously delivering quality code, a problem remains: the division between the development and operations teams.” 

The proverbial partition between these traditionally siloed teams has resulted in an obstacle to the continuous delivery approach; any issues in code that crop up once it has been handed over from development to operations means code has to be sent back to development while both teams begrudgingly pass the buck back and forth for the problem.

“Enter DevOps, a collaborative approach to development that brings the two teams together in such a way that producing quality code becomes everyone’s responsibility, simultaneously,” say Draper and Wilson.

This approach aims to shorten the software development life cycle and to provide continuous delivery and high software quality. Consisting of the continuous integration / continuous delivery (CI/CD) framework, DevOps thrives on building, testing and releasing quickly. 

This approach, coupled with the Agile methodology, creates a software development process that is by no means perfect, but is the best approach we have so far. This approach allows all participants and teams to own their work, work harmoniously without physical or imagined borders, fail quickly, learn quickly and adapt accordingly. Best of all, it can be adopted across industries.

DevSecOps: Let’s stop making dangerous mistakes

The supposed next step in the DevOps evolution, DevSecOps is the latest industry buzzword. It places particular emphasis on security within the software development life cycle. The methodology proposes that security becomes everyone’s concern, across development, operations and security teams, from the very start of the software development life cycle (SDLC), throughout testing and with dedicated monitoring thereafter. 

This approach takes security from the production phase to an ongoing, real-time concern that is continuously considered. Luckily, many IT standard practices inherently support security efforts, including penetration testing and threat modelling, as well as containerised environments which make testing and throwing out problematic code easier, without drastically affecting outputs and speed.

Although relatively new and unmastered, as a leading custom software development firm, there are practical steps that BBD can recommend be taken in any DevOps team’s efforts to address security concerns, starting with ensuring that your DevOps practice is established and well run:

• Have automated workflows

Some useful automation tools include static code reviewers Codacy and SonarQube, Web vulnerability scanner Acunetix, Web application automator Selenium, dependency check software OWASP and API, Web, mobile and desktop application tester Katalon Studio.

• Foster a sense of accountability

• Encourage a shared knowledge base across disciplines in which all team members can share their expertise

• Ensure all team members contribute to an optimal working dynamic which allows security concerns to stem organically and easily

Tapping further into the collaborative nature of DevOps, encouraging more meaningful involvement from in-house security teams based within organisations would continue to make security more top of mind for everyone in the team, resulting in a more unified front when it comes to security concerns.

The BBD approach: Future-proofing with Agile

From banking and telecommunications to education and the public sector, wherever there is a client need, BBD ensures quick delivery of high-quality software using the Agile and DevOps approach as appropriate, allowing our teams to work autonomously while still giving our clients optimal involvement in our processes; a working dynamic made possible by Agile’s collaborative approach to working.

Although BBD is not prescriptive in how its teams work, preferring rather to adopt the approach most appropriate to ensuring that teams deliver business value for clients in their environment, Agile ensures that BBD teams are in a continuous state of readiness, meaning that whatever the next evolution in the DevOps methodology may be, the company is prepared and ready to adapt, ensuring its practices are always most conducive to optimal delivery. 

BBD believes that the key to being prepared for the future is being adaptable and ready for whatever comes next, even when “what’s next” cannot be predicted or prepared for, and especially considering ongoing advancements in AI, automation and machine learning. It is in this mind-frame of adaptability that the effectiveness of Agile and using it to be future-ready lies, ultimately minimising mistake-making as quickly and efficiently as possible.