Software is eating the world!
You use software all the time. You’re using software to read this article online right now.
Bad software development practices impact you, whether you realise it or not. As a private individual, or a business owner, no one is immune.
With my background in software development, I often find myself frustrated by software solutions offered to different sectors which, despite their apparent success, are developed with little attention to fundamental software engineering best practices.
But, does this matter? If the software (mostly) does what it needs to, who cares if the developers write janky code and don’t have automated tests and need to take the software offline for 4 hours every month to “roll out updates”? 🤦🏻♂️
Let me explain why we should all care about bad software development practices, regardless of whether we have a technical background or not.
Reason 1: Reliability
Let me be completely honest, I’ve written some pretty awful code in my time, I’ve failed to test stuff, and yes I’ve even “broken prod” (broken the production or live version of a system). But I’ve learned from my mistakes (mostly) and try to avoid repeating them (mostly)!
Indeed, I think this is what some might call being “battle hardened”!
Fortunately, most of my technical failures have been fairly isolated on small projects with little at stake. But, how might this translate to software being used by 1000s of users as a critical system for their business? This changes the narrative.
Are you ok with your mission critical web-based software going offline for a day? How about losing 24-hours worth of data?
There are many techniques that software development teams can employ to help avoid releasing bad code which might “break prod” or cause other data loss or availability issues.
“But surely they’re the experts, they should know what they’re doing, they wouldn’t be in business if they messed up so often, I have to just trust them right? … right?”
You’d be surprised.
If a software provider has enough cash to throw at selling their software to executive teams and they position themselves as the dominant player in the market, technical excellence can often become an after thought. (See also: monopolies)
Reason 2: Security
You don’t want your data to be leaked or deleted accidentally, right?
Seems simple. And again, we might feel like we should just “trust the experts”.
So how do you know where your data is being stored? Who has access to it? Is it encrypted “at rest” or just “in transit”? Is your data being replicated or backed up regularly? If so, how often? What data recovery processes are in place?
Some of these questions might not even make sense to you, and that’s ok! That’s where people like me come in. We can help you ask the right questions and interpret the answers.
But if you’re looking to invest in new software for your organisation, you should be asking these questions.
One of my rules to live by: never assume anything!
Reason 3: Flexibility
You spot a bug in the software you’re using, or you notice a feature which forces you to click 4 times to complete a task when a single click would have been just as easy to implement. (Incidentally, I fondly refer to this kind of usability blindness as a business philosophy called “hating the user”.)
Now, what happens when you report that bug or the really badly designed feature that clearly demonstrates the development team are wholly disconnected from the user experience?
Do they resolve it the next day, or even the same day (yes this is possible and don’t let anyone tell you it’s not!) or does it take a couple of months? And when they report back that it is “resolved” (if they even bother to report back), is it actually resolved or have they hacked together a half-baked solution?
Depending on how it goes, you may not bother reporting any issues again because you know how painfully futile it will be to get even a small thing changed. So you stop reporting issues. And you put up with the shoddy user experience. And you employ more people to carry out the junk work that has been created by the software because it makes every task take 3 times as long as it should. And the software provider thinks their software is great because nobody is complaining anymore. 🙃
So what can we do about all this anyway?
What’s next?
In a follow up article, I provide a list of technical questions you can ask software providers when you are considering purchasing software from them.
The way they respond is just as informative as the actual answers themselves.
Remember, a lot of the above issues aren’t necessarily caused by incompetence or malice. It comes down to culture. What is the software engineering culture of the provider you’re looking to work with? Culture is everything. You can’t fake it, and you can’t change it from the outside. So make sure you get to know the culture of the provider you’re looking to partner with.
Most importantly, don’t panic!
If the thought of software procurement stresses you out, get in touch. Having an impartial technical expert on your side of the table can be invaluable when it comes to reducing stress in the short term and long term.
