In the last few chapters we’ve talked about three concepts. Throttling, where some actions we take spins The Wheel of Change and causes the Change-Feedback-Change cycle; Inertia, when the spin takes control over us; And fruition, the time it takes for the actual value to surface v.s. the perceived value.
In this chapter, we’re going to see how thinking of the three together helps us avoid executions of valueless tasks.
Get of The Wheel
At Wiser (2016) I was a team leader in charge of the company’s third web scraping infrastructure. It has finally come to full and complete fruition after a year’s work. All of our external customers were satisfied, the ones we scrape for.
Unfortunately, we also ended up with one hellish core. It was bleeding about 6,000$ a month due to performance issues. Now that it is the bottleneck for the business to scale efficiently, it was the right time to get it fixed. It was already running a few hounders of scrapers, and we anticipated thousands of them in the following year.
Because we wished for a clear set of eyes on this, I called in a meeting. It was with my superior, the VP R&D, the team and three of the most experienced engineers the company had. I’ve presented a three to six months plan on how to entirely invert the core and turn it into micro services oriented (whatever that meant that day). The plan was contained to the core. Zero changes to the scraping/business logic itself. No migration needed as well, as moving a scraper to the new core would only be copy-pasting it’s JSON file between servers. Both ensure no harm would be done to our customers, no negative values would be accumulated. I did not anticipate what followed.
“The code is shit. You should dump the entire infrastructure and product and start new. We can make it in three months.”. I was surprised they knew it was shit without actually having a look at the code. Although they were right, they were wrong. As it no longer matters. It’s been weeks since we had any issues, and no more of those were open. The existing business logic is not expected to Change any time soon. Only maybe extended someday when new requirements arise. There would be no future value in refactoring the code. Only harm.
“This needs to stop”, I ranted to my manager afterwards. “This is exactly why the company already has three infrastructures which do exactly the same thing. That’s exactly what these guys say every 18 months. And here we are again actually thinking of working on a fourth one?!”.
Coincidently, the company ran into financial troubles and I got fired along with 75% of the company. A few months later they got back on their feet, and started working on the fourth infrastructure. As far as I know, it took 15 months to come to full fruition again. It was re-coded (not 100% as-is), it was stable, performing well and meeting customer satisfaction. Just like the third one did. Only running faster. Which is only an internal value. I’m not aware of any deprecations to the old ones or migrations out of them.
Some Wheels not only better stay inert, but better not be hoped on at all. In the next chapter, the first of The Wheel’s Feedback series, we’ll see what leads down these wrong rabbit holes.
Hold the Spin
Sometimes, even though a fruition comes to an end with some external value, you already know it is only temporary and short lived. Such was the case of the Data team’s main product, the Analytics Dashboard (RapidAPI, 2021).
We were handed a design for a new feature. As we were migrating on-demand to the new micro front-end infra, it seemed like the right time for another product migration. “This is going to take much longer than we previously thought”, said Hezi, one of the finest engineers I had the pleasure to work with. “We thought it would be about two weeks, but after deep diving into the code and estimating it with PERT it would be up to two months”. Proportionally speaking, it would take us more time to migrate to the new infra than the time to code the new feature.
We also already knew the product would be deprecated 6-9 months from now. Further down the roadmap exists an entirely new one. Meaning this feature is going to be this product’s last. No more Changes afterwards, no more value in delivering faster than in the old infra.
If we were to migrate as-is, we’d be accumulating negative values, as every Change has the potential for an Instability that would harm the customer. And the migration only enables the feature. And as we’ve seen, a long fruition duration in months is likely to make the migration itself valueless. But that’s not 100% true, as the migration is not a technical prerequisite for the feature. It does not enable it, it only enables it to be delivered faster. We’ve done the math, and the delivery and fruition would be shorter on the old infra. And it would end with more value and less harm.
We avoided throttling the wheel for the wrong reason. Continuing migrating on demand, would just be inertia again, the wheel spinning us. We kept the wheel inert for a little while longer.
That feature’s fruition process was long. On the new infra because of the migration needed and on the old infra because of delivery delays. Due to it, we were afraid that the actual value would differ from the expected value. Either ending up delivering a valueless feature, or it taking so long that the team would not have a reason to celebrate a win.
Not only the technical feasibility was yet clear enough, but the expected value itself. The design, the UI/UX experience, had a lot of edge cases uncovered. We kept finding more and more, technical and product-wise. We iterated for a few days and it was still unclear. I had to make a decision.
The product itself was in an inert state, its Wheel of Change was not spinning which is why it was stable. “I’m sorry guys, but we only came up with a half-baked solution. For this, we won’t start changing again and cause harm to a fully functional product. This is off the next Sprint”. I was looking for a good reason to throttle it and could not find one. The wheel should stay inert. A few weeks later, priorities changed and the feature was discarded completely. Guess it was not that important to begin with.
In the next series, The Wheel’s Feedback, we’d be going deep into understanding why validating the expected value is incredibly important; what Feedback has to do with it; and how Feedback throttles The Wheel of Change.
Thank you for reading this series.