I want to share a revelation from a recent panel discussion I attended: you are the person responsible for the health of the system you work on.
I discuss my thoughts on why you should take time from every feature you write to improve the system you’re working on.
If you’re an engineer in a system that’s just getting progressively harder to work with, I hope this article empowers you to start making it better, without permission.
This article will take you about four minutes to read.
NYC.rb meetup had panel discussion for Sandi Metz’s Practical Object Oriented Design in Ruby with Sandi Metz as a panelist.
Sandi shared great lessons from them. I am still dissecting them and figuring out how to integrate them. Some I’m happy to get confirmation I have integrated already.
On the topic of technical debt, especially on long developing systems, who should handle the maintenance? How to keep the system easy to work with?
Keeping Systems Running Well?
In the company or business, if you are part of the software team or doing work, no matter how hard or soon the business needs the software done.
There’s a role, where the business specifies what they need the software to do. As the engineer, you make the software that does what the business needs.
The business’ needs will change, or the systems’ needs will change over time. The better the system, the better the business, and vice versa.
Conversation with Business
The business always wants more things done faster and it is easy to keep delivering for the business.
Whenever that happens, the software becomes so hard to work with that the business will start asking “why the same request took less time to complete last time?”
Usually, the response is:
We did things fast because you asked us to!
And the follow up is:
We need to stop software progress for (duration of weeks/months) so we can update and get back to being as fast as the beginning of the project.
That conversation never ends well for either party. The business feels the developers aren’t good enough. The developers feel abused because they did what the business wants the whole time and the one time they ask to fix things, the conversation is frustrating for all parties.
Sandi brought up a great point in the panel discussion saying the responsibility of keeping the system running well and features easy to implement is:
Yes, you. Not your teammate, coworker, pair, colleague, manager, product manager, engineering manager, director, or vice president. You, as the person implementing the code, need to add 10% extra time to every feature to keep the system in a healthy state.
The best person who knows how (un)healthy the system is you, and ultimately, you are the person working on the system. Keeping the system in shape is you.
The alternative never works. The business will stop, in more ways than one.
There is a situation where you do not have to do this, it is if the company hires another team to just manage the system for you.
As the developer, you can just create new features and a whole other team does the work of keeping the system healthy.
If you work at such a place, contact me - I would love to hear about it.
Expectations of a healthy system? That’s a loaded question, things that come to mind:
- security patches
- low technical debt
- new features are easily added
- tests are functioning
- code coverage is high
- code formatting is acceptable to the team
- frameworks are up to date
- libraries are current
- remove outdated/depricated functions
- spelling mistakes
- easy to code
There’s a wide variety of metrics for a “healthy system” and honestly, these become the minimum over time.
The best system allows the business to move fast. The faster you can deliver features, the faster the business will think of newer and/or bigger features. I have never met a business person out of ideas.
Don’t assume others, like your manager, will know the system health either. They won’t know, even if they worked on the system. Even if they are technical.
I have first hand experience of this, where I did know how healthy the system was. After sprints where I was not contributing directly or reviewing every pull request, my knowledge of the system became less detailed, even on code that I worked on!
What should you goto your manager for then? It depends.
Pick something you want to improve and ask how they would approach solving it. Don’t ask for permission, just do it. When asked where you will get the time, always say: you will make it.
Ultimately, you will have to do this work to keep the system healthy, either now or in the future. Choose a time that’s calm and you have flexibility in getting more time to work. Work with your manager and coworkers on improving the system together as it benefits everyone.
In my experience, I encountered systems where it’s a pain to work on and pulled the: “we have to stop and clean this up” card. Those conversations have never gone well and from Sandi’s point, I now understand how to approach them.
By being the person who works on the system, you are the person most intimate with the system’s health and ultimately, best person to maintain it.
Add 10% extra time to every story to focus on improving the system you work on. Your future self and coworkers will love you for it.