4 ms·
My measuring stick is how much the team can understand what is happening. When the team at large cannot move through the codebase and effectively make changes t
by leetrout 3y ago
My measuring stick is how much the team can understand what is happening. When the team at large cannot move through the codebase and effectively make changes then it is time to make changes.
If the code is on the back burner and only receiving maintenance then no need to mess with it.
But active feature development? Teams need to have a grasp on it and have a way to get a mental model of what is happening.
- lazyasciiart 3y agoA team that can’t understand what the code does now is not going to write a functional replacement any time soon.
- whstl 3y agoIn a dysfunctional company where "the code is the documentation"? Yeah. If there are knowledgeable people to lead the process, and the transition is done appropriately: it is 100% possible and I have done multiple times in my career. The burden on rewriting shouldn't lie in developers alone. And before someone quotes Spolsky: not every software is Netscape Navigator.
- gertlex 3y agoCorollary: If the change is going to make it harder to effectively make changes (and figure out changes that need to be made, i.e. manual troubleshooting), it's probably a bad change. (this corollary might be most applicable in robotics?; dealing with the fallout of kubernetes being forced onto robots by cloud-oriented folks)
- leetrout 3y agoWow, I am sorry for your pain and suffering. I am not anti-k8s, I get it, I get why people like it. But it's just so much complexity for so little payoff in many cases where you don't need the overhead.