Shoveling away debt
A few weekends ago, it snowed like it does once in ten years. It was everywhere, and there was a lot of it. It was fun at first – we made a snowman, went sledding, made snow angels, the usual things one does with snow.
And then I had to walk the dog. We have a small dog, and poor guy was nearly up to his chin in the snow. Which is a little annoying if you want to pee or take a dump. So we had to move the snow around – but not the snow that we'd made a snowman with, or the snow where we'd be sledding again soon, and definitely not the snow where we'd be making snow angels again.
And then we had to go weekend shopping. Which meant moving snow out of the driveway. We couldn't, of course, move it to where our dog would do his business. Maybe some of it could go next to the snowman so we could make some more of them. We could possibly shift a bunch of it to the foot of the slope where we'd be sledding again – but the kid was against that idea. And he definitely didn't want more snow next to the snow angels he'd made. We didn't want snow piling up closer to our outside walls, either.
Our problem wasn't that there was snow everywhere. It was that we had only recently bought this house, and didn't have any prior experience of managing the complexity of backyard snow. One way to deal with this would be to estimate how much snow I need to get out of the small area I need to use right now (and maybe another area I need to use in a couple hours), and do just that – and to keep doing that every time I needed for some area to be snow-free. Doing this is easy, because it gets the job done quickly with less effort everytime.
Another way to deal with this could be to allocate different areas of the backyard to different snow-related activities, estimate the relative likelihoods of each of those activities, prioritize them accordingly, make a plan for where, when, and how much snow to move around (and where to) based on that. This is hard, because it involves thinking ahead and spending a lot more effort up front than what I'm naturally comfortable with (and it doesn't let me just get stuff done). It also requires me to understand the problem at a different level than I'd need to if I just wanted some snow out of the way on one little place. And unless everyone else at home is 100% on board with doing this, it involves getting everyone on board the idea, convincing them that this is worth putting up with.
Attacking product complexity, I think, is a not-too-dissimilar activity. We introduce complexity every time we build something new – and no matter what happens afterwards, this complexity has to live somewhere. The easy thing to do is to address the complexity that lies immediately ahead and get it out the way. Over time, we get better at “simplifying” complexity, but if we aren't careful to see where we're moving that complexity to, we're going to end up at a point where we will need to dedicate a significant portion of our effort to simply address the piles of complexity we've left in our wake (a.k.a, prioritizing technical debt over feature development).
The harder thing to do is to stop doing whatever we want to do right now, accepting that this means near-term efforts will take longer than we'd like them to, but that doing this will be less likely to create bigger problems down the road. It also means having a product strategy that considers the long-term impacts not only of the decisions we make that can influence product complexity, but also the kinds of problems we want to address – or not address – in the future.