Most of us who work on heavily used systems at scale saw this one coming, and that they would propose a rewrite as they just have, and we also don’t think this is the answer.
This is why hubris is a very counterproductive quality in engineering.
Why do we all agree on this?
This is why hubris is a very counterproductive quality in engineering.
Why do we all agree on this?
Legacy and heavily used systems have decision accumulation over the years:
some decisions were made because of the technology available at the time, some due to a feature need, some due to dependency management, some were made to make the system more secure or to test it.
some decisions were made because of the technology available at the time, some due to a feature need, some due to dependency management, some were made to make the system more secure or to test it.
When the staff were fired/walked out the door, they took with them all of this context. The existing code can tell you what it does and how, but it can’t tell you why.
Good devs are curious: they explore context before they get to work.
None of that happened, under the assumption that “I’m so smart, I can figure everything out on my own, quickly.” You see this a lot with junior devs or folks who haven't had to maintain large systems over time
None of that happened, under the assumption that “I’m so smart, I can figure everything out on my own, quickly.” You see this a lot with junior devs or folks who haven't had to maintain large systems over time
Let’s say a massive rewrite was even feasible for them, which I have high doubts of. This doesn’t take into account the opportunity cost of the time spent doing this.
Do they have SLOs in place? How will they maintain those while rebuilding?
Do they have SLOs in place? How will they maintain those while rebuilding?
Even if all of those were easy, which they aren’t, and even if they had a perfect new system all set up, what about the cost and risk of a massive migration? Migration costs are huge, and ensuring stability in that process even more so.
How are they testing any of that new infrastructure, and given that this is probably a multi-year project, what’s the plan for shipping new features in the interim? Who is going to set up security and trust reviews for the changes they are making (critical in social media)?
If you have a lot of hubris with no curiosity, you might not understand:
- how to build upon lessons learned from the old system
- the opportunity cost of trying something new
- the complexity of a massive rewrite, or why the system became complex for the current features
- how to build upon lessons learned from the old system
- the opportunity cost of trying something new
- the complexity of a massive rewrite, or why the system became complex for the current features
A dev who can build something alone quickly may not have the skillset to evaluate these tradeoffs. Deciding that if you are smart and can’t figure it out, it must be broken is irresponsible.
This is why a curious mindset is one of the greatest strengths an engineer can possess.
This is why a curious mindset is one of the greatest strengths an engineer can possess.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
