In the last chapter of this journey of Wasteful Applicative Evolution, we’ve talked about the concept of refactoring from day 0. We’ve come to realize it’s impossible and concluded that all we can do is our best to postpone refactoring as much as possible.
Alas, while writing it I’ve noticed a contradiction.
If we were to look at this graph again, we’d see that I’ve reached a controversial conclusion, that doing our best at all times causes a Velocity drop. I came to a full stop while writing this series. I had to figure this contradiction out before I’m done with it.
While pondering about it, I attended a meetup at Fiverr along with several other architects and leaders. What many said and had in common is that they are working for a “product driven” company. The product managers’ and engineers’ shared focus is to code more features. There is nothing wrong with that, but they’ve also said that there is never any time to work on the infrastructure or to reduce the technical debt which keeps on accumulating. “I can’t make my managers understand how important that is!” was repeatedly said. Then it hit me. And then it hit me again. It’s not only a matter of definition, it is a matter of perspective.
We’ve defined Velocity as “the right effort done. Time spent on preventable instability/maintenance or valueless goals is a Velocity drop”. We’ve also continuously reminded ourselves of the goal of “keep our business moving forward”. The latter is a product-like perspective, while the first is more of a technical perspective. Let’s try and bridge the gap between the two.
It is impossible to see the consequences of a prevented instability. We can not see or measure something that has not happened. Let’s try to do so anyway.
The gain of a new feature is easily quantifiable and seen within days. Doing our best results in not a loss in the very far future. It is not quantifiable as we can not measure something that we have prevented from happening in the first place. This is what we do when we do our best, we prevent future instabilities from happening. It is an effort to prevent a future Velocity drop.
To do his best, an engineer would say “I need three days to make this right”. Through a product-only perspective, that would translate into “that’s three days not working on a new feature that is money lost”. There is something to it, because when the business stands still we’d be eventually beaten by our competitors or start losing customers.
Question still remains: what is the gap here that causes so much tension between product and engineering?
We’ve seen through this entire series that continuous maintenance is unavoidable. We put some effort into preventing it as much as we can but eventually we have to deal with it. Some of it occurs because of the evolution processes. Some of it is beyond our control. It is effort that results in not a loss. Effort is needed just to keep the business from moving backward. It is an opposing force to moving it forward. In the later section about project management, we will circle back to this point, where we will show there is no such thing as maintenance when it comes to Sprint Planning.
Software doesn’t “just work”. It is a misconception and a mis-expectation shared by many, no matter which title they hold. As a colleague of mine once told a customer “it is software, it breaks”. It’s funny because it’s true. On how to accept The Inevitable, that is what Eventualism is for. Which is what the next series is all about.