The Software Engineer’s Struggle
Imagine building a tower by stacking blocks. You could do it real fast, grabbing the next block before the last is even settled. Alternatively, you could do it slowly and carefully, aligning each block with the rest of the tower before moving on with the next. This is the choice software departments and developers individually make every day, whether we realize it or not. The choice isn’t always an easy one, and the factors involved aren’t always obvious to all parties. So let’s try and clear things up.
The Block Tower Analogy
In this analogy, the tower represents one product of a software company, and every block represents a feature for its users. Whether the block tower is well-aligned and stable represents the internal quality of the software, including infrastructure, design, and code.
The time it takes to add a block to the top of the tower depends on how well-aligned the tower is up to that point. Adding a new block neatly takes more time than just plopping it on the top and moving on.
For this analogy, I’m going to strip down a software company to only two departments: Software Development and Business.
The Business Department
The Business Department doesn’t generally care about how nice the internals of the block tower looks. After all, the customer doesn’t know if the backend is an outdated, spaghetti-ridden monstrosity, or a beautiful network of fancy microservices. Instead, they care about the height of the tower, i.e. how many features it has. The more features they can offer the user, the better the position of the company in the market. As such, the Business Department will often urge developers to place their blocks as quickly as possible.
The problem is, placing blocks quickly makes it more difficult to place additional blocks in the future. Add the fact that having one more skewed block in the tower isn’t that bad, but the problem accumulates over time. The Business Department may not care about the internals of the software, but they do care about the time it takes to get new features live.
The Software Development Department
On the other hand, there’s the Software Development Department with all their block placers and tower designers. In my personal experience, we can be real perfectionists. If it were up to us, no block would ever be placed until everything underneath was absolutely spotless. This is for good reason: doing so would ensure placing the next block is practically effortless.
The problem with this approach is that things are never quite perfect. You can always have better tests. There’s always another chunk that has gotten a bit too big and could be split up. Just keeping up with all the new frameworks and software development ideas could be considered a full-time task. Even if you could eventually have the perfect system, your competitors will likely have pushed you out of the market by the time you finish. So demanding perfection is not a solution either.
Clearly, we will have to find a balance. However, that’s not exactly easy…
A Balanced Approach
Finding a balance between effort spent on improving what’s already there and adding new things is crucial for any software company. It’s about finding the best way to satisfy both short-term and long-term interests. The initiative for this balance must come from the developers. Why? Because the Business people don’t know about the internal quality of the software. They shouldn’t have to understand it because it’s not their responsibility, and it’s not what they’re supposed to be good at.
It is up to the developers to convince the Business side that taking the time to straighten out some older blocks is worth it. This should be an investment of time and effort that will pay off when placing additional blocks on top of the tower, because that is something the Business Department does care about. We developers aren’t building software for ourselves. Making things nice because we like it better that way is fine for a hobby project, but not for an enterprise.
Showing that such an investment will pay off can be tough since it’s hard to quantify. I’d love to say things like “Increasing Test Coverage by 60% will decrease future development time by 8%”. Or maybe “Splitting up this microservice will take 7 hours and let us integrate with third parties 23% faster from then on”. Sadly, obtaining numbers like this with any accuracy is no walk in the park, making this approach problematic. Besides, planning software development is a topic in and of itself.
Conclusion
Although there might not be an easy solution to this problem, an understanding between the Software and Business Departments goes a long way. An understanding not based on technical knowledge, but knowing that there are two ways to build a block tower, and we have to find a balance together.
Make sure to check out our careers page to discover tech jobs at Takeaway.com!
