We're living in the kiss-kiss-bang-bang era. Answers have to be quick, solutions simple, takes hot. One of the common leitmotifs that I see in my bubble is "just do trunk-based development", "drop pull requests", "just do pairing". While I understand the intention, I see the consequences of overselling almost as dangerous as going the current, not optimal way. Why? Read more in this release!
I’ve been thinking about similar topics for a while, especially the lazy and annoying advice of „just keep it simple”. In the Go community, it’s the standard advice when someone tries to implement any kind of a „pattern”. And it’s true that blindly applying patterns makes no sense. On the other hand, someone once felt some pain and came up with ideas how to solve it, so it’s worth to at least consider why.
Which is another topic I’ve been mulling over, we tend to swing from one extreme to the other, somehow struggling to find balance. 🤷♂️
I see too often "just keep it simple" and "don't do bikeshedding" as gatekeeping phrases. That's indeed a similar case as "just do X." Without giving more insights and reasoning, those are "talk to the hand" phrases—phrases that stop discussion.
I like to use simple solutions, but simplicity is not easy. Usually, to reach a simple solution, you need to do multiple iterations (both on the design and technical solutions).
So I feel your pain. It's hard to keep the balance of knowing when upfront thinking or more complex solutions are good enough. That's why I like diversity and transparency in the team (or community). That helps to reach a better solution in the end.
The other heuristic I use is: "How hard would it be to rewind this decision?", or "how hard would it be to delete this?". That helps to do a sanity check. If it's rewindable, maybe we can just try it, get the feedback and move on. If it's hard, then it can mean that either we need to rethink it or do more simulations to confirm if that's going to actually work. I wrote it more in: https://event-driven.io/en/removability_over_maintainability/
As you mentioned "pick things easy to reverse" is a good one. That's why I prefer lightweight libraries to frameworks — no need to integrate them deeply into your project.
Another one I like is "wait until it's painful". It's hardly universal, but often helps. One example is configuration. It's tempting to have every possible setting exposed in a nice UI for everyone to play with, but more often having an env variable or even hardcoding the setting is good enough. If it doesn't change often, no need to bother.
And related, if I find myself or someone else saying "you know what else would be nice?" or "we could make it fully dynamic by...", it's a good moment to reconsider. Of course, you never know if this time it leads to some great outcome. :)
The Pain-Driven Design is indeed a decent idea, although we need to be careful with that, as some people can endure a loooot 😅
Doing the full loop to your initial question after reading the last paragraph. I also think that making boring decisions and using simple choices in most cases is a safe option. Most of what we do is rather repetitive. Of course, we need to be careful, as usually, for the places we should be innovative, boring decisions may not be correct, and that's the place when betting comes into the game.
Liked this one a lot, thanks Oskar.
I’ve been thinking about similar topics for a while, especially the lazy and annoying advice of „just keep it simple”. In the Go community, it’s the standard advice when someone tries to implement any kind of a „pattern”. And it’s true that blindly applying patterns makes no sense. On the other hand, someone once felt some pain and came up with ideas how to solve it, so it’s worth to at least consider why.
Which is another topic I’ve been mulling over, we tend to swing from one extreme to the other, somehow struggling to find balance. 🤷♂️
I see too often "just keep it simple" and "don't do bikeshedding" as gatekeeping phrases. That's indeed a similar case as "just do X." Without giving more insights and reasoning, those are "talk to the hand" phrases—phrases that stop discussion.
I like to use simple solutions, but simplicity is not easy. Usually, to reach a simple solution, you need to do multiple iterations (both on the design and technical solutions).
So I feel your pain. It's hard to keep the balance of knowing when upfront thinking or more complex solutions are good enough. That's why I like diversity and transparency in the team (or community). That helps to reach a better solution in the end.
The other heuristic I use is: "How hard would it be to rewind this decision?", or "how hard would it be to delete this?". That helps to do a sanity check. If it's rewindable, maybe we can just try it, get the feedback and move on. If it's hard, then it can mean that either we need to rethink it or do more simulations to confirm if that's going to actually work. I wrote it more in: https://event-driven.io/en/removability_over_maintainability/
Miłosz, do you have your heuristics to share? :)
As you mentioned "pick things easy to reverse" is a good one. That's why I prefer lightweight libraries to frameworks — no need to integrate them deeply into your project.
Another one I like is "wait until it's painful". It's hardly universal, but often helps. One example is configuration. It's tempting to have every possible setting exposed in a nice UI for everyone to play with, but more often having an env variable or even hardcoding the setting is good enough. If it doesn't change often, no need to bother.
And related, if I find myself or someone else saying "you know what else would be nice?" or "we could make it fully dynamic by...", it's a good moment to reconsider. Of course, you never know if this time it leads to some great outcome. :)
The Pain-Driven Design is indeed a decent idea, although we need to be careful with that, as some people can endure a loooot 😅
Doing the full loop to your initial question after reading the last paragraph. I also think that making boring decisions and using simple choices in most cases is a safe option. Most of what we do is rather repetitive. Of course, we need to be careful, as usually, for the places we should be innovative, boring decisions may not be correct, and that's the place when betting comes into the game.