The two work types that I see are odds more often than not are the business projects and the internal projects. Why can’t we easily integrate these two types of projects into a single roadmap? What I think is the problem is product and engineering see two very different views of the code. Most people think code is a stable, structured thing, like steel in a skyscraper. But that’s where everyone is wrong. Technology moves at a ridiculous pace; knowledge used to be good for ten years, now its closer to ten months. So while product thinks that the building has iron in its frame, it doesn’t. It’s meat. Engineering is essential a meat processing plant. We’re not building with iron and wood, we’re building with blood and bone. We’re not Doc Brown from Back to the Future, we’re Dr. Moreau or Dr. Frankenstein. Product is concerned with making money and satisfying customers. Engineers concern themselves with keeping their flesh golems in check and patched up. We see our creations rot with every security patch, with every “new” way of doing things, with every license change (think Redis or Terraform). We know we have to keep these things shambling forward, and that is what we try to prioritize.
I’m going to deviate and explore the idea of engineers being more like Dr. Frankenstein a bit more. It’s an interesting analogy. Some of us so get caught up in the madness in what we’re doing that we lose sight of if we should be doing it. Some of us are afraid of our creations. Some of us fear our creations. Some of us want to destroy them and vow to never create these types of monsters again.
So back on topic, how do we get others to see that these aren’t buildings, but things that have to be taken care of forever? Continual maintenance shouldn’t be optional, but it often is, why? Maybe explaining it like I have above can help? I don’t know, I’m still searching for the answer. I know this became some what of a rambling mess, but I think its a somewhat interesting read.