Code Maintenance, Discipline and Money
This post talks about the hidden benefits of two code engineering best practices and how well-engineered solutions help us avoid big problems in the first place. It’s not as simple as hiring a few developers and turning on a bunch of new features.
Imagine the following situation in your SaaS project: your startup is doing so well that next quarter you foresee a need to increment the team from 1 to 5 more devs. You need to move quicker. Easy right? Not so fast, cowboy.
You schedule a meeting with your dev lead and she cues you in:
What are your expectations in terms of code maintenance prior to adding new features?
What you learn from this conversation:
I was not thinking of quality in the same way as the developers were, especially as the they grow and start worrying about shared-ownership of the code.
To your engineers, in order to make things in the correct fashion and help the business grow further without technical hiccups, they’ll need to make use of code maintenance practices like refactoring and test-driven development (TDD for short). It’s one of the main criteria developers use as quality assurance for software projects.
Yeah, TDD — it is a problem prevention mechanism. It’s the practice of making sure an application has maximum test coverage (as in as close as possible to 100%), so that each line of code has a test specifically written for it. If your app sends e-mails, the dev team should be able to test the internal logic with no need to ever send an email. TDD forces good design.
Just like our houses may get extremely messy from everyday usage (the kitchen and the bedroom more while the dining room is meh-ok), the same happens with code as it gets written. Although code is virtual, think of it as physical objects in your kitchen that when used leave a mess. If we delay cleaning up, it can be a maintenance nightmare. Refactoring is “kitchen clean up”. Ideally, refactor when you know that it will have an economical effect.
The benefits of an engineer-driven business culture
When faced with a scenario similar to what I have described, there is one question product and business people can ask their dev team:
Will refactoring this now solve a real problem at its root?
If so, stop rolling out new features for some iterations to come — yes, it’s a difficult decision — and instead bare the cost and write this off as an investment. Well engineered solutions protect us from never having to deal with particular problems in the first place— giving us engineering advantages over others.
Next time you hear someone talk about test coverage and refactoring, be open as a business owner to understanding and investing on intangible parts of your product.
This post has been inspired by an inside sales role at www.helabs.com.br, a Ruby on Rails consultancy in Rio de Janeiro.