From the moment we started recognizing testing as an essential activity during software development, people were trying to optimize testing. That optimization has many faces: faster, better, deeper, wider, cheaper, …
Every so many years, a new hype emerges, promising to be the silver bullet that solves all issues related to software quality. And pretty soon afterwards, disappointment surfaces, when few to none of the initial objectives were reached.
If you would be in the driver’s seat, allowed to take any decision that could make your team more productive, more efficient, more effective, which would result in less buggier code, what would you implement? Some agile framework? DevSecOps? A multi-level automation framework? UML modelling? Pair programming and testing? There are books, articles, keynotes, training on workshops on each of these subjects, and their advantages.
How do we predict whether something will solve our problems? We might consult the “experts”, but they typically disagree. Our own experiences are biased and limited, as no one has tried and compared everything. We could launch questionnaires, but there’s a difference between popularity and effectiveness. What we’re missing is scientific study and empirical research.
Contrary to popular belief, certain must-haves have absolutely no positive effect on software quality. Static typing? No positive effect (Ray et al, 2014). Coding standards and templates? These have a negative effect on software quality (Boogerd et al, 2018).
There’s only one technical trick that actually performs magic on software quality: code reviews (McIntosh et al, 2016). That should not come as a surprise, but you will have trouble convincing management that you’ll fasten your delivery by performing more and better code reviews.
It’s not that technical solution don’t help, but we’re putting too much emphasis on them, considering the decision on their usage as critical for the project’s success.
Where there’s a lack of evidence on the positive impact of technical solutions on software quality, there are some questions that will reveal a negative impact on software quality. “Do you sleep less than 8 hours per night, on average?”, “How many weeks per year do you work more than 40 hours?” and “Are you unhappy at your current job?”.
Acute Sleep Deprivation (ASD) causes novice programmers to lose most of their skills (Fucci et al, 2018), while Chronic Sleep Deprivation (CSD) make people make more serious mistakes (Rogers, 2008). On top of that, most sleep-deprived people don’t realize that they’re performing worse and can’t tell that they’re making programming mistakes, making it much harder to self-regulate.
After four hours of continuous, sapient work, our productivity nose-dives (Collewet & Sauermann, 2017). Teams working more than 50 hours a week are 80% less productive (Business Roundtable, 1980)
Stressed workers are both significantly less productive and significantly more likely to make serious mistakes (CDC – Sauter, Murphy et all, 1999). Developers performing extended overtime produced software that performed worse on every other aspect measured compared to software whose teams reduced scope in order to meet deadlines or opted to extend the go live date (Tozour, 2015).
Finally, happy developers solve complex problems faster (Grazition et al, 2014) Now, repeat. If you would be in the driver’s seat, allowed to take any decision that could make your team more productive, more efficient, more effective, which would result in less buggier code, what would you implement?
