The Software Garden
Software is like a garden. Both software and gardens require a lot of work, craftsmanship, and artistry to envision and create, especially when starting from scratch. They both evolve, and they both need constant maintenance, even if you don’t make any significant improvement.
If you are a reader of my blog, you know that I use a character called Bolbo as my mental framework for the quintessentialsoftware developer. You might remember that he has a square jaw, messy black hair, round glasses, a cynical sense of humor and a snarky attitude. I wrote about him in “A day in the life of a software engineer.” In this post, I will talk to you about Bolbo’s brother Polbo, who is a gardener. I will tell you about his journey in the creation of a formal garden.
I am going to come back to software in a minute. For now, I ask you to trust me when I say that the story of Polbo is useful to understand what’s coming next. Stay with me.
Dreams, Plans, and Pure Beginnings
One day, Polbo bought one acre of land with the goal of transforming it into a beautiful formal garden. He drew a plan, including different themed areas, paths, flower beds, fountains, a pond with frogs and fish, bushes, trees, perennials, and annuals. He was a visionary, and he could see the plan clearly in his head. In fact, he could almost smell the flowers.
He drafted a roadmap for the work ahead and got to work. He started working alone, and the initial progress was fast and satisfying. Working alone required no coordination with anyone, no discussions, and no disagreements.
Sometimes Polbo followed his original design, other times he made adjustments on the fly. Eventually, the work was too much for one person, and he realized that it was time to get help. He asked for help to Bolbo (his brother), but he was too busy starting a software business. So, Polbo had no choice but to hire some help.
Growth
Hiring took a while, but finally, he found the right person and thought him all about the vision for the garden and his plans for what needed to be done to get there. The recruit was good and worked hard, but it was still not enough; there was just too much stuff to do. So, after a while, Polbo hired another gardener, and things started to move quicker.
The garden took shape, and after several weeks it looked beautiful and complete enough to give the team a little time to take it easy for a few days. So, that’s what they did. They walked around, pulled some weeds and made small adjustments. They moved a rock here, put some bark there. Otherwise, things looked new, clean and pretty.
The growing seasons came, and things started moving faster. The team needed to prune bushes and pull weeds daily. In the middle of all the frantic activity, Polbo began to develop new ideas as feedback from visitors poured in. As a result, he kept adjusting the design, adding new plants and moving existing ones around. At some point, he decided to add a new flower bed and a large greenhouse. He hired a third gardener who could help with the construction, while the other two kept maintaining what was already there.
Saturation of Resources
A year later, Polbo and his three workers were busy full-time keeping the garden manicured. Plants kept growing, and the team needed to prune them regularly; the weather did damage, weeds grew, dears ate the flowers, some of the plants got sick and died, and mysterious sprouts popped out from seeds brought by the wind.
The garden kept trying to revert to a wild state of chaos. Everybody’s time was spent trying to keep it formal and manicured. It felt like playing a whack-a-mole game; literally, since a family of moles decided to start digging a mess in one of the grassy areas.
Expansion
One day, another acre of land went up for sale next door. It was a unique opportunity to grow, so Polbo bought it. After the purchase, he directed his attention to the design of a new garden area and assigned two of his gardeners to work on the plan.
For a while, the old garden didn’t get enough attention and started looking overgrown and messy while the new one came together slowly. Everybody worked all day, but nothing seemed great anymore. Everywhere Polbo looked, he saw issues: weeds, moles, weather damage, dead plants, and leafs.
New Blood
It was time to hire new people. Hiring took time, and things got even worse for a while. Once employed, the new person needed training, and one of the experienced staff members had to spend a lot of time doing that. There was no time for further improvements, and the staff could barely keep up.
Sexy Projects Were Out Of Reach
Polbo always wanted to add a fountain with a sculpture of a turtle in the middle of the garden. The right area was ready for it, and he talked to his employees about it and got them all excited. Everyone wanted to be part of that project, but there was never enough time; there was just too much maintenance to do.
Visitors thought that the garden looked beautiful, but Polbo could only see problems. Everyone was busy, running around frantically 110% of their time. The team knew that working on new features would be fun and would increase the value of the place, but there was no time.
Meanwhile, Bolbo was facing a similar issue with his software startup. His team was scrambling to maintain the product they built and could not design and add new features.
Software is Like a Garden
I wrote this garden story because, as mentioned before, making and maintaining a garden is similar to building and maintaining software.
When a software company starts building a product, things move very fast with few people. There are no complaining customers, technology to update or production systems having issues; one hundred percent of the time goes to innovation and new functionality. Similarly, when you first start working on a garden, you can make lots of progress quickly since there is no garden to maintain yet.
When you have a product that customers use, things change; you must maintain it. Maintenance comes in many forms: bug fixing, resolving customer issues, improving scalability, improving availability, security, etc. The more technology you build, the more maintenance is required. That is similar to a garden where the more plants you have, the more keeping you have to do.
Software Growth Zero (SGZ)
Similarly to the Polbo garden’s story, without growth, a software team eventually becomes busy maintaining what it created. Ultimately, time for significant improvements or new features work becomes rare.
Moreover, software tends to grow in complexity and number of features. Functionality is rarely taken away, and the surface area that needs to be maintained expands to absorb all the engineering resources available.
I call this phenomena “Software Growth Zero,” or SGZ, which represents the state of an engineering organization where 100% of the resources are busy maintaining the existing solutions.
Activities that absorb people’s time in a Software Growth Zero situation include:
- Making improvements only to keep up with basic market expectations (that is, no significant market innovation);
- Keeping up with new versions of the technology stack used;
- Maintaining security levels stable as new threats are discovered;
- Fixing bugs;
- Refactoring code;
- Writing documentation;
- Improving the infrastructure;
- Improving processes;
- Supporting customers;
- Making aesthetical changes to the UI.
Seven Strategy To Delay Software Growth Zero
What can you do to mitigate this problem? How do you push Software Growth Zero as far in the future as possible?
Here are seven strategies:
1. Ruthlessly Remove Dead Code
In your garden, when a plant is dead, you want to take it out and either replace it with a new one or free up some space. If you let dead plants linger around, things will eventually start looking bad.
The same thing should happen with code. You want to eliminate code that is unused so that you no longer have to maintain it. Don’t worry about code that, “might be useful again sometimes in the future.” Source control systems like Git were invented to deal with that.
2. Ruthlessly Remove Unneeded Functionality
In your garden, when you have a plant that you don’t like or want, why spending time watering or pruning it? You should simply remove it, just make sure that it is truly dead.
In your software product, when a feature is no longer needed, no longer used or just doesn’t work, why spending time maintaining it? You should eliminate it to cut long-term maintenance costs.
Now, removing features is more difficult than eliminating dead code, so you need to be careful. You do not want to impact your customers by killing a feature that your customers use, even if they do so rarely.
3. Maintain as You Go (AKA, Keep a Low Technical Debt Balance)
If stop maintaining your garden for a while, it will quickly become a jungle. If that happens, the amount of work required to bring it back to its original splendor might become overwhelming. Weeds become entangled with good plants, and good plants start growing into each other. It might get so bad that it would be easier to rip it all out and start from scratch.
In software development, if you let technical debt accumulate, it will eventually become overwhelming and costly to maintain. Technical issues can quickly become tangled, and resolving them might become impractical. If you let it go long enough, it might be easier to just start from scratch.
4. Automate Everything That Can Be Automated
In your garden, if you water the plants by hand, you might spend several hours per week doing just that. Automatic watering systems will cost you money, but eventually, they will save you a lot of time, and time is money.
In software, if you invest in automating every repetitive task necessary to maintain, test, build or deploy your product, you will eventually save a lot of time and money. The sooner you start automating, the more money you can save in the long-term.
5. Grow the Team
In your garden, as you expand and plant new plants, your workers are going to have more and more stuff to do just to maintain what you have in good conditions. At that point, you must hire more workers, or you won’t be able to add or expand anymore.
Similarly, as you add new features and grow your customer base, your software engineers will have more and more maintenance tasks to do. To continue raising the value of your software, you must continue to grow the team.
6. If Possible, Avoid Special Features For Special Customers
In your garden, you want to avoid to add special plants visible only to a specific visitor. It is best to add plants that everyone can enjoy. Any plant that you add to help only one customer requires the same amount of maintenance of plants visible to all.
In software, unique features for individual customers are expensive to maintain and should be avoided as much as possible. If it’s possible, you should abstract custom requests by designing solutions that resolve the problem of the requester, but that can be used by everybody else.
7. Avoid Creating Short-Lived Features
In your garden, you would not want to plant a mature tree that is only going to be alive for a short period. Planting a large tree is expensive; the longer its expected life, the better.
Similarly, creating a temporary software feature is expensive and should be done only when the cost vs. value equation is in your favor. Try to avoid it whenever possible.
Conclusions
You cannot avoid Software Growth Zero, but you can mitigate it and delay it with discipline, strategy, and practices. The seven strategies above are a good starting point.
As always, don’t be shy and let me know what you think about this topic.
Leave a Reply