Chapter 53. In Search of the Lost Time
Ingrid Epure
Who hasn’t faced a significant outage caused by a problem you thought could wait six more months—whoops! How we wish we could have avoided this fire, and how nice it would have been to have had that time to prevent it. But we never do; time is the scarcest of resources in engineering.
We keep ending up in this place, and we know why. Infrastructure teams wear many hats: supporting product teams and running the existing systems, on call, developer workflows, and provisioning; the list can go on. With so few hours in a day and a finite number of resources, paying down tech debt and building automation and tooling get deprioritized in favor of feature work. After all, product is what sells; the company is trying to grow and stay alive, so most of the effort goes into acquiring new customers by building awesome solutions to their problems.
The deprioritization of this work robs us of the opportunity to be open to changes or figure out how greenfield work might fit in with the current work. In this world, wouldn’t it seem more sensible to wait for a Holy Grail–type of project to solve a problem—to the detriment of small, continuous improvements?
The lack of space or time is why it takes some organizations so long to figure out things like CI/CD (continuous integration/continuous delivery). Instead of rolling it out bit by ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access