This sign reminds me of a presentation from Seth Godin at the 2006 Gel conference. This was one of his examples of stuff that is broken. “They’re building a device that can crush small children to death,” he says. “They oughta walk down the hall to the engineers and say, ‘The sign is not the solution to the problem‘.”
The sign, it turns out, is a workaround. It’s a hack. The real solution involves fixing the gate so it won’t mangle your hand or crush you to a pulp – but it takes someone to stand up and say “hey, guys, is this really the best we can do?” Even if it’s not her job to do so…
Another example: an internal team is delivering you an API that’s changing constantly. You find yourself rewriting large sections of code constantly to work around the changing API. What do you do? Do you happily (or unhappily) go on re-writing code every week when the API changes? Do you build an extra integration layer between your code and the API to manage the scope of the modifications you have to do? Or do you start a discussion with the team providing the API about why it is changing so often, and maybe implement an API contract between you and them?
Often, (every day), we see stuff that is complex, that is broken or that us just plain silly. When you encounter complexity or brokenness, I think you have three choices:
- You can accept the complexity or brokenness, and do nothing.
- You can accept the complexity or brokenness, and try to hack a workaround around it.
- You can ask, why is it complex? Why is it broken? And how can we fix it (properly)?
Doing #2 might help you navigate the problem, but it creates debt for you and your organisation that someone needssigh to repay some day.
Doing #1 is, I propose, at best depraved indifference; at worst malevolent and destructive.