Most of us are pretty savvy when it comes to buying things and not getting ripped off. If something sounds too good to be true, our spider sense starts tingling and we are on the look out for the catch, or if we are getting scammed.
Yet when it comes to buying or building software, we often find teams in positions where they are blindsided to the true cost of their decisions.
Focusing on business value only
Great software delivers value to people and organizations; its primary goal is to bring about positive change and impact. As a consequence, however, technical considerations can sometimes take a backseat to business ones, and perhaps justifiably so.
However, a badly written codebase is a major liability that will bite in your rear when you least expect it and needs also to be dealt with as a business concern. Often times, building things the right way may seem more expensive initially, but this is one classic case of penny wise, pound foolish.
Software that is not maintained well will be more prone to bugs and will require more time down the road to fix up. As the codebase grows, and more features are added, this complexity is compounded and your development team’s velocity will fall dramatically.
The worst case scenario is that your team will lose morale as business stakeholders balk at the glacial pace of the development, and developers start to lose morale and leave for some place with better software engineering practices.
As with most things, a balanced approach is necessary to get from point A to B in the software world. At the very least, a well-oiled software engineering team with great practices and code can be attractive to the right kind of software talent.
Technical debt is unforgivable debt
Technical debt is a term coined to describe how bad technical decisions can weigh down a team’s productivity. Often times, such decisions are driven by a tight deadline, leading to shortcuts being taken.
As an example, a lot of software developers frown upon copying and pasting code, especially if it is not well understood, and is thus more bug prone. The ideal case is that developers find code that they can use as reference but take only what they need to add to their codebase.
When such suboptimal code is left unchecked, each developer that happens across this part of the codebase has to stop and try to understand what is going on here. This may be confusing if there are properties of the code that foreign to the codebase, and thus becomes a tax on the entire development team.
As more technical debt piles up, the effect is not unlike compounding interest to borrow a financial term. You can ignore it, but you end up paying anyway through lost productivity. All is not doom and gloom though, teams may choose to take on some technical debt to chase deadlines, but must be mindful of paying it down later.
To do so, some time and budget have to be catered to refactoring the codebase, which means to improve the code without changing its output. Software developers typically already have a list of things to work on to improve the codebase, which they will deal with if they get time. As a business concern.
Automated testing is like buying insurance for your software
Dealing with software defects is part and parcel of building software. The unfortunate truth is that most businesses with complex software cannot eradicate bugs completely, and sometimes may decide not to fix a bug. Case in point, even with the constant stream of automatic updates for Windows, bugs still inevitably exist.
Bugs can cost real serious money too. In 2014, Jollibee lost millions of pesos per day when their system migration failed and they had to close down 72 physical stores. The project had a very aggressive schedule, and given the scale of the operations was a very risky move.
In any software project, testing is carried out on the code to ensure that it works. It is one of the major pain points in any sizable software project. Typically, we have a testing team that will pour over the User Acceptance Test (UAT) document, which outlines steps for someone to test the project. However, manpower is costly and this becomes really expensive an entire UAT process may be required each time changes are made.
One way to deal with complexity and risk is to invest in an automated testing suite. An automated test suite cannot fully replace human testing, but can significantly reduce the menial work. It reduces the need for developers to test the software through the user interface, which takes away time from development work, and does not ensure thorough testing in development.
More importantly, a well-maintained test suite also gives developers the confidence to take on new features. As software gets more complex, even simple changes can have cascading changes throughout the codebase (even if it was well designed). More risky changes can be made, and the test suite will alert the developers to which places code is broken.
However, many teams make excuses for not doing automated testing. The claim that doing automated testing is more costly is true, but only at the start; once the team gets comfortable with writing tests, it becomes part and parcel of writing code. When considering the risks, and hidden costs (it is difficult to measure productivity loss), it becomes a lot cheaper than not doing it.
Businesses often only consider the costs of building the software and its running costs such as hosting. However, the total costs of ownership (TCO) takes into consideration the lifetime of the software, which includes security patches, software upgrades (for e.g new versions iOS, Android OS, etc), new features and amendments, and a great many things.
In such cases, having a well-maintained code base and solid test suite reduces the risk of each change and upgrade. Without this, the cost can sometimes be so prohibitive that companies then work around the software, rather than fix it.
More true today than ever, the true cost of cheap software is business agility.
This is the last article in the mini series "Tinkerseries: The essentials for introducing technology into your business". To check for the latest updates regarding the series, please visit https://www.tinkerbox.com.sg/blog/2016/tinkerseries-the-essentials-for-introducing-technology-into-your-business.