fbpx
Tech & business consulting

The evolution of mistake making

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, reputation and clientele terms? Throughout the last 35 years leading in the software development space, we have tracked how new approaches and methodologies try harder to limit human error and curb mishaps and mistakes than their predecessors did.

With the advent of each new methodology, the tech world overall is compelled to reflect on our mistake track record, consider where we have come from, and look to how the current approach can further improve out mistake proclivity. Two of our 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 lifecycle should unfold. The method places emphasis on the logical progression of steps throughout the development lifecycle, 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 down fall 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, team-based, and 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, i.e. if work is budgeted for a timeframe but 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 iterative development offers.

DevOps: Let’s make less mistakes quickly and collectively
Although ideal in theory, Draper and Wilson assert that “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.”

This approach aims to shorten the software development lifecycle and 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 lifecycle. The methodology proposes that security becomes everyone’s concern – across development, operations and security teams, from the very start of the 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 we can recommend be taken in any DevOps team’s efforts to address security concerns, especially since a big part of what we are seeing is that not only do we have to worry about the vulnerabilities we ourselves create, but in the tools and libraries we use. We suggest 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 inhouse 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: Futureproofing with Agile
From banking and telecommunications to education and the government sector, wherever there is a client need, we ensure 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 we are not prescriptive in how our teams work, preferring rather to adopt the approach most appropriate to ensuring we deliver business value for our clients in their environment, Agile ensures that our teams are in a continuous state of readiness, meaning that whatever the next evolution in the DevOps methodology may be, we are prepared and ready to adapt, ensuring our practices are always most conducive to optimal delivery. We believe 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.

What’s next? We’re ready!