As it’s usually the case, I saw a post on Twitter, and the inspiration for a post came up in my mind.
I actually thought of linking to an xkcd post, but in this case, I actually agree with the Twitter post 😄.
This topic has been written about before, sure. But, for whatever reason, it keeps popping up every now and then. And it looks like time and time again, software developers have to explain themselves. Or defend themselves and their practices
It’s not a conspiracy theory
We (software developers and engineers) don’t meet up annually and decide we are going to do these lavish things like writing automated tests (nefarious, right?) so that we can increase our rates.
I mean, we didn’t meet up in person at all for the past two years 😬.
To the outsider it can look like all we do is sit at our computers, rant about things on Twitter, and get nice paychecks. But that’s far from the truth.
And I’m not even bringing up that the big majority of us (underrepresented folks, or people from non-US&EU countries) are struggling to find a job at all. That’s a topic on its own.
Developers are problem solvers.
The process of development usually looks something like this. A client has a problem. They think that computer can solve their problem. They hire a developer. Talk about their problem to the developer, and the developer finds a solution.
Simple, no?
In a nutshell, that’s precisely it. We get a problem and find the optimal solution for it.
Behind the looking glass
But there’s more to it. Some nuances that the outside world is missing. When you buy stuff, you usually want to spend the least amount of money on it. It’s a cost optimization principle. Get the most out of it for the least amount of money.
When it comes to a business that needs a software solution they are looking at the return of investment (ROI). How much money are they going to spend, to get the biggest returns (biggest ROI)?
And what client wants often doesn’t align with what developers want.
Developers, being problem solvers, have designed various methodologies that will help them do their job efficiently.
We have our design patterns, various architectural design approaches, different programming languages for different needs, etc.
And we are efficient. We want to make sure that the project we built is a quality one (at least I like to think that the majority of us do). That it follows coding standards and clean architecture. That we can look at the code in two months and pick up where we left off.
The client doesn’t really care about all that. They have a problem, and they want it solved. How the problem gets solved is not their problem. It’s what we’d call an implementation detail.
Client types
We can divide our clients into two rough categories. Those that are mindful of the future, need a stable product. Those that know that they are going to have to spend money, in the long run, to get what they want. So they think about all the ways they can save money and they will listen to the experts.
Then there are those that need to get the job done. The future is uncertain. Who knows what’s going to happen, right? One day you can give a presentation at a conference, another day you can go into a lockdown because of a global pandemic. Crazy, right? 😅
As long as it works, it’s fine.
And there lies the problem. The software has a tendency to ‘rot’ with time. It’s like entropy and the laws of physics that govern all aspects of our lives.
New plugin updates come out, or a new major version of your framework. Some security patch needs to be applied (we’re all humans and make mistakes).
Things evolve over time, and you cannot assume that the software you build will work perfectly as is in a year or two. Your business may also evolve and need new features.
This is where writing quality software comes into play. A lot smarter people have written about it in the past decades. We all experienced the same issues. Fast code means more bugs. Fast code means fewer tests, less documentation. It gets the job done, but for how long?
The first client type listens to a developer when they say: we are including writing tests and documentation into our estimates. Because they know, their ROI will actually be bigger in the long run.
Why?
A maintained software is easier to develop and update.
Reducing cost
When you have good architecture, it’s easier to add a new feature. If you’ve written your code isolated enough of third-party plugins, when you update them, there is a minimal chance that something will break (coding against interfaces).
If you have automated tests (well written of course), it’s less likely that you will introduce an unwanted side effect (also known as regression) to your code.
Yes, these things take extra time – and therefore cost more. But looking at the project overall, they actually help keep the maintenance cost at a minimum.
There are sources online that will give different estimation models for maintenance, and some articles say that maintenance can range anywhere from 40% – 90% of the total software cost [1] [2].
These are not small numbers. Maintenance matters, so thinking about it upfront will actually help you reduce your costs.
Writing bad code will cost you more.
Conclusion
To wrap my thoughts up: quality software costs more for a reason.
There’s a reason top agencies are expensive. It’s years of experience in reducing costs for your software that matters.
Thinking about all the pitfalls and how to mitigate them is what good software engineers do.
So when you hear a developer wanting to spend some extra time making your product as good as it can get, don’t be harsh. They’re doing you a favor. All those tests and all that documentation matters a lot in the long run.
Leave a Reply