4 ms·
I used to like to rewrite code that I thought was "ugly" because it was not written in the modern way or it was not very generic or whatever. I thought that doi
by robalni 4y ago
I used to like to rewrite code that I thought was "ugly" because it was not written in the modern way or it was not very generic or whatever.
I thought that doing that was often pretty easy so I thought "why has no one done this already?"
Later I realized that the fact that it was easy to change was what made it good and the changes I wanted to make to it would probably just make it more complicated.
That's the danger; good code is easy to change so it will easily get rewritten until it's not easy to change anymore.
- foo42 4y agothat last paragraph is an excellent description of the problem!
- jackblemming 4y agoStrong disagree. This is something people say to sound clever. It’s not true at all. The real cause is basic entropy and complexity are always increasing. Rarely does a project manager request a feature be deleted. This is compounded by most companies having a few good programmers and mostly mediocre programmers, so the codebase will tend toward the mean over time.
- namaria 4y agoHm... Ad hominem, truism, truism, ad hominem. And not even disagreeing with the conclusion in the end...
- deleted 4y ago[deleted]
- kubanczyk 4y agoI'd say false dilemma fallacy.
- tpoacher 4y agoso ... sounds like you agree?
- Ygg2 4y agoWhat is the alternative? Bad code? It's exactly same as arguing you should not educate your workers. Cause they might leave. So you get only the least knowledgeable ones.
- lucumo 4y agoIt's really not. Software solves business problems. Code that meets its requirements needs to be left alone. Developers just changing code because they feel like it need some coaching. They're wasting everybody's time for reasons that amount to "I like it My Way". So, with normally performing developers, the only code that changes is the code that needs to change. Good or bad only has an influence on the cost of a change.
- regularfry 4y agoThat's not inconsistent with "good code will get rewritten until it's not good code." Good code that you need to change is code that can degrade as a result of that change. Nothing to do with "just changing code because they feel like it".
- lucumo 4y agoThe good code will be changed after it has ceased to be good code too. And bad code can become good code in the process of changing it. There is nothing that makes good code more or less likely to change than bad code.
- namaria 4y ago>good code is easy to change so it will easily get rewritten until it's not easy to change anymore Sounds like the 'bad currency drives good currency out of circulation' problem. Bad code drives good code out, because good code is easy to understand and change.
- iovrthoughtthis 4y agoexactly
- Derbasti 4y agoWithout concerted effort, any easy-to-change code naturally will be replaced by hard-to-change code.
- tome 4y ago> Bad code drives good code out, because good code is easy to understand and change. I call this the Peter Principle of Programming: "Code increases in complication to the first level where it is too complicated to understand. It then hovers around this level of complexity as developers fear to touch it, pecking away here and there to add needed features." http://h2.jaguarpaw.co.uk/posts/peter-principle/ http://h2.jaguarpaw.co.uk/posts/peter-principle/
- waynesonfire 4y agoVery cool point. I will highlight though that I have worked with people that choose the path of least resistance regardless of complexity of the code that would need to be changed. It's as if they refuse to read code.
- lll-o-lll 4y agoThis is why I think the most powerful abstraction for framework with extension points is c++ template meta programming. Wait! Hear me out! Template meta programming is an entirely separate, incredibly complex, programming language distinct from c++. The only people I have ever seen use it in production are exceptionally skilled programmers. Everyone else flees and cowers. If they try to change it it will not compile. So why is this good? Because it only allows the framework to be extended in the ways intended by the original designer. Anyone wanting to update this unholy beast will be a master programmer who’s investing significant effort. That implies the updates will be good. Good code is easy to change. Great code is near impossible to change, but easy to extend.
- QuadmasterXLII 4y agoThe ITK experience
- jonbronson 4y agoyou just sent shivers down my spine
- lll-o-lll 4y agoShivers of excitement surely
- bcrosby95 4y agoWhat happens when you have new requirements that weren't envisioned by the original designers, who are no longer there? How do you unravel the design to the point where you can create a new one?
- lll-o-lll 4y agoWith great effort. That’s kind of my point though. It’s when you are changing the design from the originally understood “these are the ways to extend and add”, to a new paradigm, that you should be expending great effort. In such a code base, it quickly becomes understood that if changes are required to “framework Doom” in order to achieve a new feature, the time budget will need to be large. It’s built in tech-debt prevention.
- simplotek 4y ago> (...) because it was not written in the modern way or it was not very generic or whatever. Premature generalization is a well known problem and a never-ending source of complexity. I lost count of the times I had to push back on PRs of clueless developers who felt the need to generalize one-liners that pop up twice in the whole project, and for that their proposal was to add a strategy pattern, ultimate replacing two expressions with three classes.
- edflsafoiewq 4y ago> Software has a Peter Principle. If a piece of code is comprehensible, someone will extend it, so they can apply it to their own problem. If it’s incomprehensible, they’ll write their own code instead. Code tends to be extended to its level of incomprehensibility. https://nigeltao.github.io/blog/2021/json-with-commas-comments.html https://nigeltao.github.io/blog/2021/json-with-commas-commen...