Marc Andreessen’s adage has never been truer – software is eating the world.
In every walk of life, computer programmes now help us understand and manage our business, workplace, health, society and home. That means the stakes for software efficacy have never been higher.
The problem? Just as software is eating the world, bugs have now started eating into that software.
Just ask British Airways. Or RBS. Or the National Health Service. Or countless other organisations and their consumers whose software failures became global headlines.
Putting software on the c-suite radar
One big reason for continuing – and escalating software problems – is that software integrity is still not recognised by the boardrooms of the biggest companies in the world.
As a result, there is precious little accountability. Expect more instances of serious software failure to emerge in 2019. And expect their severity to increase, too – it’s very important that the software controlling your car or your pacemaker doesn’t crash as often as your smartphone does.
Prioritising clean code
But another reason for bad code is, well, bad development practices.
In software circles, we still revere a vision of the developer as a master. Sites like HackerRank and CodeWars feed the idea by scoring, essentially, proficiency in languages. We don’t score the languages we use to communicate in this way, because effective communication is about so much more than recalling a large vocabulary or reciting the rules of sentence structure.
Yet, in development, code cleanliness is still assessed as though the code itself were the only thing that mattered. Many modern tools and methods developers use only feed this misapprehension.
Lexicon over function
Syntax checkers and code linters may be useful add-ons to your development environment – but, whilst they help developers write technically correct functions, they don’t come close to highlighting the underlying reasons for problems in enterprise-sized software.
Foundations overlooked
Code review tools from the likes of Synopsys may help you find that memory leak or null pointer, once it occurs – but fundamental software issues are often introduced from the very incept of software development in terms how the software that is being written, is structurally designed. When you build a house, you don’t start by checking the bricks and walls straight away; you usually start with assessing the design of the house, e.g. the load-bearing viability of beams, the make-up of the foundation. In software, too, most anomalies are often found in the inherent way software is structurally designed.
Moving fast and breaking things
Agile development practices now allow teams to quickly spin through sprints. That may seem productive but, if you’re not careful, agile can be unbalanced, necessarily preferring output velocity over integrity.
Issue severity unhinged
Every development team needs to rank by urgency. But, in today’s agile kanban world, the blunt buckets of “critical”, “major” and “minor” don’t really offer sufficient context to move on with. Why is it an issue critical, what will fixing it unleash?
It’s not that developers don’t have tools at their disposal to help. For planning, we use Atlassian’s suite; Jira is the friend we love to hate. And, for version control, we are spoiled, of course, by Github and more. But, what’s noticeable about these tools is they each address problems around the code, not with it.
Three-steps to a more hygienic software
Development teams need help. And, for catching bugs, pair programming just isn’t enough. In fact, when I hear of people throwing two fallible programmers at the problem, I am often reminded of how Henry Ford remarked that customers had asked merely for “faster horses”.
Instead, a step-change is needed. To write cleaner code, developers are going to need a new set of tools, premised on three simple aspects…
1. Prioritised problems
Okay, so your web app has 55 syntax errors and 87 warnings. What should you attend to first?
In 2018, most code analysis tools are built on imagined experiences, based on recognisable rules – broadly. But binary rules are not enough; context is crucial.
The critical missing dimension, context could help a team figure out which code issues are most pressing. The customer software for both Deutsche Bank and ticketing system for Deutsche Bahn, the rail company, may both run on Java – but the nature of issues in them are vastly different. And, more than simply flagging code issues, that should vastly affect the the weighting given to issues for attention.
2. Recommended actions
But what exactly should that attention look like? In agile today, teams end up at a point where they have 100 issues to deal with in a two-week sprint. But where should they start?
Look at it this way – if a function has been coded very poorly but isn’t used often as often versus a function coded slightly poorly which is committed more frequently, which one would you want to fix first?
The answer lies in every company’s unique set of circumstances. That is why they modern code-checking tools must go beyond one-dimensional “fix this” advisories, mining specific imperatives and historical outcome records for what actions really move the needle – and making the right recommendation as a consequence.
3. Usability
There is an irony here. For most developers, writing software that is easy to use and effective is paramount. Yet we, as developers, are often contending with code analysis software that, itself, is kludgy.
Programmers shouldn’t just see the error of their ways at compilation time, or at the end of each sprint. Feedback about fixes should be given in real-time.
And it should be visual. Who out there gets a kick out of the way their linter pulls them up on syntax errors? Nobody. Today, we are all used to using beautifully-crafted web apps, rich in charts, graphs and colour-coding. That is the kind of feedback tool users should expect.
And they may get it. Such tools are now coming on-stream – turning companies’ commit histories into vast repositories from which to learn how to recommend fixes, functioning as an always-on coding buddy, providing active recommendations for improving their code.
It is a change that will mark a significant shift in the history of computer programming.
We rightly prize the skills of the developer. Programmers are making the future of the world. But a world in which all the skills and knowledge stay locked in coders’ precious heads is not one that is viable or scalable. One in which we celebrate only syntax formulation is not a promising one.
We need to augment developers and their teams with the tools they need to course-correct, to build on their code skills with smart guidance that train them toward the best outcomes.
In that world, the developer, the product manager and the scrum master don’t fall by the wayside, they become unleashed to deliver more features, faster.
I have seen it myself. When you introduce tools that help programmers perform, they begin stepping back, to focus on the macro, structural and design issues which underpin their code itself – and the outcomes are fantastic.
As artificial intelligence and machine learning starts to get injected in developer tools themselves, it is a future that is coming more clearly in to view.