For greenfield projects you should absolutely do what is most current and makes the most sense.
But I’ve also seen the opposite mentality, which is that just because something is old means it’s bad, and the current team could do SO much better if we just rewrote it in X language (go, rust, kotlin, etc).
Such rewrites (and often smaller refactors too) fail to take into account the countless bugfixes (and untested, undocumented behaviors) that are the result of an issue discovered and fixed 5 years ago by an engineer who no longer works at the company. And the frontend depends on the old behavior so by refactoring the backend to what seems “right” you’re actually breaking things, for no real gain.
Of course old things need to be fixed because they accumulate a lot of cruft when not actively pruned and cleaned up. But when doing so, you have to exercise caution and test it well!
I totally agree, Jan. Old doesn't equal bad, and maintaining such code requires indeed caution and automated tests.
I'm also not a big fan of complete rewrites, either. However, I suggest not going with the flow without understanding how the currents work.
And your point fits with the general idea. As a tech lead or principal developer, make your thinking visible when you start a greenfield project and document architecture and design decisions.
This way, when the development team is gradually replaced and nobody knows what happened with the codebase, there is a series of decisions and the context in which those decisions were made. Developers shared their knowledge in the process, and at the same time, new decisions were made to improve the codebase. It's a continuous process of improvement.
For greenfield projects you should absolutely do what is most current and makes the most sense.
But I’ve also seen the opposite mentality, which is that just because something is old means it’s bad, and the current team could do SO much better if we just rewrote it in X language (go, rust, kotlin, etc).
Such rewrites (and often smaller refactors too) fail to take into account the countless bugfixes (and untested, undocumented behaviors) that are the result of an issue discovered and fixed 5 years ago by an engineer who no longer works at the company. And the frontend depends on the old behavior so by refactoring the backend to what seems “right” you’re actually breaking things, for no real gain.
Of course old things need to be fixed because they accumulate a lot of cruft when not actively pruned and cleaned up. But when doing so, you have to exercise caution and test it well!
I totally agree, Jan. Old doesn't equal bad, and maintaining such code requires indeed caution and automated tests.
I'm also not a big fan of complete rewrites, either. However, I suggest not going with the flow without understanding how the currents work.
And your point fits with the general idea. As a tech lead or principal developer, make your thinking visible when you start a greenfield project and document architecture and design decisions.
This way, when the development team is gradually replaced and nobody knows what happened with the codebase, there is a series of decisions and the context in which those decisions were made. Developers shared their knowledge in the process, and at the same time, new decisions were made to improve the codebase. It's a continuous process of improvement.
Great article, Alex! I love the analogy !! 👏
Thanks, Stefania.
Do you have a favorite example of a turkey tale from your projects? 🦃
Such a great piece!
Also love the turkey analogy 🤣🤣
Thanks, Jurica. 😊
What crazy turkey tails have you encountered in your team or company? 😅
We always have 48 partitions in a topic.
One person initially made a decision and everyone else based their yaml based on that 🤣😫