The Cost of Poor Software Quality
In 2020, in the US alone, operational software failures cost businesses $1.56 trillion! This is the first in a small series of articles I want to share in a tale of technical debt.
The CISQ report, which the article below is based on, highlights that biggest bucket in the cost of poor software quality is operational software failures ($1.56T). Their research further found that this cost is approximately 10 times costlier than finding and fixing the defects in the first place; and actually the best investment of our time and money is in preventing those defects from occurring as early as possible (when they are usually relatively cheap to fix). The second best place for our investment is having the ability to isolate, mitigate, and correct failures as quickly as possible to limit the damage of anything which makes it to production. So how should we start to consider these findings?
The 2020 CAST Crash report, which reviews 1.6B lines of code, across 533 organizations, highlights Robustness, Security, Performance and Maintainability (specifically Changeability and Transferability) as the best areas of focus for improvements in this area.
This boils down to the following:
- Greater attention must be given to secure coding and best practices as many applications had unacceptably high security weaknesses.
- Define a set of quality gates for things which could put operations or costs at risk and ensure that software passes through them before being released. Furthermore, give developers the ability to analyse their source code regularly against these rule.
- Treat structural quality improvements as an iterative process pursued over numerous releases and a consideration for every sprint cycle.
Some other key takeaways for me were:
- System-level violations are the most critical since they cost far more to fix and may take several release cycles to fully eliminate.
- Security displayed wider variation of issues than any other characteristic reviewed. So needs a system-wide view to be able to understand as effectively as possible.
https://www.theregister.com/AMP/2021/01/09/buggy_code_costs
Planning for Technical Debt
Technical debt can often be wrapped up with historical knowledge of deep technical information which isn't available easily to people who have spent their career in a totally different field. This means that conversations about where money budgeted for technical projects is best spent, can be heavily weighted on the new feature side when being compared against 'paying off technical debt'.
The article below introduces a twist on the term to make those conversations more balanced by talking about technical delta and functional delta instead. Technical delta is the difference between how an IT system currently works, with its known shortcuts, workarounds, even bugs, compared to how it should work to get the same functionality. Functional delta is more simply the functionality which currently exists vs adding extra functionality to grow the business.
- The cost of functional delta is how much the PMs project believe you'll need to spend on developers, extra software, administration, etc.
- The cost of technical delta is things like current operating costs and maintainability. The first is easier to explain. If an app needs more memory you have to pay for it. The second less so, but is generally a concealed cost of the app taking more developer time to update it, or constantly having to fix it, or worst of all - a damaging security incident. See my part 1 for more info.
I like the idea because it gets us thinking about the two values together. For example, when we're discussing a functional delta we can more easily compare it to the current technical delta but also how much technical delta we're prepared to accept in the new functionality. Can we reduce or increase any one over the other.
Developer Working Patterns During a Pandemic
In the final part of the technical delta (debt) articles, and because it is tied strongly to how we work, the last article looks at how IT work behaviour has changed with people working from home during the pandemic.
The good news is that we're definitely not less productive; and actually we're probably getting more done. However, it mostly seems like this is just because people are working more. There's also some evidence that collaboration has increased as well, so it will be interesting to see if that extra work translates to better work or just more and will companies see it as a reason to move to a remote model - possibly at the detriment of the individual?
We believe that the best place is somewhere in the middle. At Mesoform, we've always had flexible and remote working. Unless there was a specific need to meet up, we would get the team together frequently to maintain a good social environment but otherwise, let people work from wherever they feel most comfortable.Aside from productivity, remote working has benefits and consequences both environmentally and socially, but if nothing else we do now have a lot of data to be able to make radical improvements to how we work. Here's hoping we make the right decisions.
https://itrevolution.com/working-from-home-during-a-pandemic-a-tale-of-two-cities
