This post is for the non-technical founders, but if you’re a software engineer then this article should still be useful – its always good to re-visit the basics.
When working with SEs you might have heard the terms “clean”, “well-structured”, “maintainable” when they talk about building your application – and there may have been a tendency to do two things, either zone out and nod politely, acting like you know what their talking about, or wonder if this is an eloquent way of saying their going to pad your next invoice.
Hopefully after reading this article, you will have more clarity on what maintainable code means, and what it means for your bottom line.
First off, most decent software engineers have lives. And we would rather do high quality work as quickly as possible for an appropriate rate – than slowly bleed a customer dry with low-hourly rate 5h1tty code.
In fact, we take pride in our work and usually have more work than we can handle anyway, so if your getting our development time – work has been turned away or pushed back to make space for you. We want your sweet money, but our business is about helping you make even more of that money, to pay yourself, your investors and your shareholders and hopefully us over a long and happy business relationship.
The simple fact is, if your business runs on custom software, then maintainable code affects your bottom line.
Maintainable code meets these five criteria
- Built to last
- Easy to understand
- Minimal Tech Debt
- Good Test Coverage
- Modular and Reusable
Let’s expand on these.
Built to Last
As much as you want it to be, software is never just “done”. Bugs need to be fixed (There is no way an application can be bug free. Users will break your software in ways you wouldn’t believe), new features will be added, copy/layouts will need changing or you may have to integrate with a new tool or service. And even if you require none of these things (you will – I don’t allow clients to assume they dont need maintenance anymore. Too many bad things have happened), server updates will happen, various libraries and frameworks your software runs on will be updated, and a myriad of other things. Its best to see software as a living thing, thats constantly working and growing. Maintainable code costs more upfront, but makes future changes quicker, cheaper and less risky. Its like having a car thats reliable, easy and cheap to fix – except you dont have to compromoise on user experience or quality. The cars you actually want to drive are rarely cheap, reliable or easy to fix. Unless you buy a Porsche.
Easy to Understand
If your project is written in a high level language (i.e Java, PHP, Python, JS) then it should be written to be read by humans first second and third. Forget the fancy operators. Even a non technical person should be able to at least read the code and infer what it does after a brief explanantion, or some guidance. This means
- Clear Naming conventions –
- Logical folder structure – Yes, although frameworks take care of this to some extent
- Comments – Where needed, sometimes its easy to go over board.
- Consistent formatting – They should be using a linter for this.
- On boarding and Off boarding processes
All of this should be written down in some kind of handbook that provides a guide for future engineers.
Minimal Tech Debt
You may have heard this term thrown around a lot. “We need to avoid technical debt.” And in all honesty, I didn’t really even know what that term meant despite developing web applications for years. (I’m terrible – I know).
Tech Debt is essentially shortcuts taken during the early phases of a software development project in order to achieve a deadline, with the hope that at some point down the line it can be fixed later. Unfortunately business needs always take priority and that point keeps getting pushed further and further down the line, until it never happens, or the application explodes.
In a fast moving start up some tech debt is un-avoidable, but if its documented and there are clear processes in place for dealing with it then it can be managed. A good software engineer will document when such issues occur and raise the issue with you so at least you know about it, and can take remedial action when appropriate.
Maintainable code is key to making sure tech debt is kept to a minimum.
Good Test Coverage
In 2025 no software enginner should be starting a new project without some kind of automated testing. At a very minimum they should be testing all the code they write, at the front end (the bit a user sees and interacts with the application) and the backend. It may not be possible to ensure all areas of the application are covered if the application is at an MVP stage, but tests need to be part of the plan. There are three types of tests:
- Unit tests – small pieces of code that test specific areas of the application
- Integration tests – Slightly more complex tests that test areas of functionality of the application
- End to end tests – Automated tests that run through the application accomplishing various tasks like a user
I won’t lie. Adding tests to your application increases development time and upfront cost, but you save in the long run by having a stable application, with minimal support requests from users. Users have a better time using your application which should help you achieve your business aims, equalling more money for you and happy productive users.
When an application is built with testing in mind you get
- Faster deployments – The application can be made live quicker and easier
- Less surprises – Complex hard to fix bugs have less chance of occurring
- Reduced QA time – Changes to an application can be implemented quickly, and potential issues can be spotted before they cause serious problems.
Next time you speak with your software engineer, ask them how many of these testing processes they implement.
Modular and Reusable
A software project should be broken down into smaller pieces. Ideally the software engineer should be aware of design patterns, SOLID principles and DRY coding. Otherwise you end up with a big spaghetti mess, thats expensive to maintain because simple changes take ages to implement. Ask them about their thoughts on this. If they have no idea what your talking about, run away. Or prepare for an expensive and frustrating project. An engineer should be able to add, remove or update the applications functionality without having to re-write large areas of the application.
Maintanable Code – The Wrap up
Writing maintainable code takes longer, and can increase MVP development costs by 25 to 75%, but the cost savings are many multiples of this.
On going maintanance costs are reduced significantly, the incidence of bugs are reduced, your app can have features added and upgraded, responding to customers needs in an agile manner. Finally, you wont be dependent on the whims of a single developer. Too many times, a client has had to have a whole project re-written at great expense due to the dumpster fire a previous developer left behind. Spend the money now and get things done right, even if your project is at the MVP stage.
TL;DR
As a tech founder/CEO the key benefits of maintainable code are:
- Quicker and cheaper changes
- Easy to swap out developers, or onboard new developers if you grow your team
- Reduced bugs
- Your project is scalable and future-proof
If any of this went over your head or you need tailored advice, I am available for consultancy calls or shoot me over an email – adwin@andtechandstuff.com
I’m looking forward to seeing you reach your tech goals this year!
