Experiences and Biases from the past
We all have been in a situation when joining a team full of excitement and will to change the world, asking:
YOU: Why don’t we do this way instead?
Team Member: Someone in the past tried and it didn’t work…
No documents, no strong arguments, just Tech Folklore. We have our well-known folklores such as werewolves, mermaids, as well as regional folklores in a country or even within a city culture. The same happens with Tech Folklore: if you want to really scale you need to go to a NoSQL database, SQL isn’t good for many writes; or some local lore like, the team doesn’t use database Y because we used it and it’s slow.
As you can see, they usually don’t have much context and are treated as almost universal truths, like Python is Slow. But how slow is slow? How fast is fast? Why is it “slow” bad for our use case? And usually, we don’t have the past decisions and the reasons why database Y is slow written down. This will happen from time to time; while you’re shipping 100 features, you won’t have time to prioritize evaluating something that failed in the past, supposedly.
There’s also the “authority” decision to consider. For instance, a Staff engineer might have made a decision five years ago. Although they’re no longer with the company, their decision persists without a clear rationale. The team continues to maintain and propagate this decision, assuming it had a valid reason at the time.
Closing to new opportunities
So you’re back entering the team, and you see the perfect idea and solution for a long-lasting problem of the team, but no—they’ve tried it and it didn’t work… But where are the docs? How was it implemented? This approach to doing things kills the openness for new ideas, perspectives, and diverse solutions. And this early excitement and fresh eyes for problems its really valuable in a team onboarding a new engineer and should always be taken with good heart!
People have different expertise and experiences, so things can be better this time. Or at least document it so we don’t spend more time trying it another time ¯\(ツ)/¯.
Things change
Technology is constantly evolving, and what didn’t work in the past might be a viable solution today. New versions of software, improved hardware, and innovative approaches can render old assumptions obsolete. It’s crucial to periodically reassess past decisions and be open to revisiting ideas that were previously dismissed. This doesn’t mean blindly trying everything again, but rather approaching old problems with fresh perspectives and updated knowledge. The same thing is for considering things of the past, some new technology might seem very shinny and good but is it gonna solve some problem? Or are we engineering for the sake of engineering?
Documenting things
As we empower people to take on new tasks and document their processes, it’s equally important to record and make past decisions widely accessible. Repeating past mistakes due to a lack of information leads to unnecessary time waste. Documenting past approaches, help us avoid mistakes or refine learning to improve upon.
Things like ADR (Architecture Decision Records) and decision records are great tools to share this information. Because without proof, experiments and records; past experiences that wasn’t good can be just Tech Folklore. Also by having more information now, it can also be something feasible.
Conclusion
So let your monolith be, and wait before fully committing to distributed serverless event-driven CQRS federated architecture—fancy names may look good in the Brag Doc, but they don’t always solve real problems. Prioritize understanding your use case, assess the value of change, and ensure decisions are driven by actual needs, not trends. Also always revisit past decisions because they might change or we might have a different perspective about them, once we consider that the sun orbited earth. Things change as we better understand the context and have more knowledge!