Software Maintenance
Hey!
Welcome back to another week of musings.
It's another week, and it's the last of April. We made it! If you have time, I hope you spend your weekend relaxing and reflecting on what you want for next month.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- OpenAI said they would be interested in buying Google's Chrome, which made me think about how many users they could sign up to ChatGPT on day one. How long would it take to add ads to ChatGPT and Chrome?
- How Discord Indexes Trillions of Messages. It is always interesting to see how companies scale popular technologies like Elasticsearch and Redis.
I don't know if this has happened to you, but your team or organization might have made a decision that involved adopting some solution or offering a feature to customers. We don't think about the support of said decision in "perpetuity" (for varying degrees of perpetuity).
Over time, the decision context is lost as people move out of teams. This means that if the new teammates are not experienced in the tool or solution, they might find it a hassle to support and decide to phase it out or stop supporting it altogether.
It's hard for customers of your product to phase out a successful feature. It's also tough to maintain if the original implementation was not built for the current scale, like enough traffic to require a switch from sync to async or eventual consistency. The base requirement for these features is basically, "don't break it."
Keep the lights on
Your team might have this set of tasks called "Running the Business" (RTB) or "Keep the Lights On" (KTLO).
These labels are usually used for running the software, upgrading libraries, runtime, and vulnerabilities. By existing, software will need to get updates constantly. This is without considering other teams like Security, which might be running scanners in production to determine if we're open to particular vulnerabilities.
Your team might be trying to reduce this burden via Renovate, Dependabot, etc. Your company might also have purchased tools like Sourcegraph to perform batch changes.
Sadly, the costs of these operations cannot be zero without strong automation, as validation is required. You never know of a library that used SemVer to push a patch version with a breaking change. Do you trust your tests?
Every change is load-bearing
In the case of internal features, while we might think we can be more lenient and change things, people and teams get used to having their workflows be a particular way. So, impacting productivity will always be a concern for leadership when phasing out a technology, like moving from on-prem Jenkins to a SaaS solution.
Everything works until it doesn't
When we design software for a specific set of features in time, even after constantly adding more code, eventually, the architecture decisions won't work.
This means that you're forced to change approaches. Introducing changes to the architecture has its trade-offs, like increasing complexity and support burden.
Will we ever stop changing?
Probably not. Customers and their tools are in a co-evolutionary relationship. You have probably noticed that as you use a tool or piece of technology, you develop new workflows or new ways of using it. At the same time, a product or tool is changing as it adapts to new use cases.
Your company's product managers will analyze the analytics of the flows and funnels and change the product to increase conversion, engagement, etc.
Conclusion
In conclusion, software maintenance is a forever endeavor and a balancing act of not breaking anything while keeping the software open to new requirements.
We should be designing our software for flexibility, agility, and many other "-ilities" as we call them.
Your turn!
Thank you for reading! Let me know if you're burdened by software maintenance or how you deal with that on your team. You can tell me by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others