Write code that is easy to delete, not easy to extend (2016)
programmingisterrible.com
Write code that is easy to delete, not easy to extend (2016)
1–10 of 102 posts
Re: Write code that is easy to delete, not easy to extend (2016)
#2Yep, to recycle a brief analysis of my own youthful mistakes:
____
I've come to believe the opposite, promoting it as "Design for Deletion."
I used to think I could make a wonderful work of art which everyone will appreciate for the ages, crafted so that every contingency is planned for, every need met... But nobody predicts future needs that well. Someday whatever I make is going to be That Stupid Thing to somebody, and they're going to be justified demolishing the whole mess, no matter how proud I may feel about it now.
So instead, put effort into making it easy to remove. This often ends up reducing coupling, but--crucially--it's not the same as some enthusiastic young developer trying to decouple all the things through a meta-configurable framework. Sometimes a tight coupling is better when it's easier to reason about. [...]
Re: Write code that is easy to delete, not easy to extend (2016)
#3C# is pretty good about these, with extension methods and event handlers. With event handlers instead of virtual methods, it's much easier to separate the pieces.
Re: Write code that is easy to delete, not easy to extend (2016)
#4Yep, to recycle a brief analysis of my own youthful mistakes: ____ I've come to believe the opposite, promoting it as "Design for Deletion." I used to think I could make a wonderful work of art which everyone will appreciate for the ages, crafted so that every contingency is planned for, every need met... But nobody predicts future needs that well. Someday whatever I make is going to be That Stupid Thing to somebody,…
Sometimes things change, sometimes we chose the wrong abstraction.
Unless you’re writing the Linux kernel you shouldn’t write it like the Linux kernel.
Re: Write code that is easy to delete, not easy to extend (2016)
#5Implementing choice is superior. Not only can your program be capable of more actions, but the process of thinking about how to include these features leads to focusing on your codebase which leads to refactoring, better code. With time the code becomes so flexible that adding features is easy, because your foundation is superior. And in the process other core functionality gets fixed and becomes better.
Re: Write code that is easy to delete, not easy to extend (2016)
#6Yep, to recycle a brief analysis of my own youthful mistakes: ____ I've come to believe the opposite, promoting it as "Design for Deletion." I used to think I could make a wonderful work of art which everyone will appreciate for the ages, crafted so that every contingency is planned for, every need met... But nobody predicts future needs that well. Someday whatever I make is going to be That Stupid Thing to somebody,…
It still depends. Business line application yes and 10x yes. It will change it will move, don’t try to foresee business requirements. Just write something that will be easy to replace or throw away.
Frameworks and libraries not really, for those you still have to adjust to whatever happens in the world but at much saner pace.
Biggest issue is when devs want to write “framework” when they work on business line application where they have frameworks that they are already using like Rails/Asp.Net etc.
Re: Write code that is easy to delete, not easy to extend (2016)
#7C# is pretty good about these, with extension methods and event handlers. With event handlers instead of virtual methods, it's much easier to separate the pieces.
And yet the worst ever code I saw was in C#.
I hope I won't offend anyone pointing at it [1]. This is a somewhat popular tool to evaluate macroeconomic policies in the EU.
A combination of language choice (C# as a natural language Microsoft Excel bosses tend to request from their interns to use), the usual churn of academic undergrads and loads of other cultural failures are the reasons this monster exsts.
Someone should write a book how to make the worst ever codebase, and start with EUROMOD.
[1] https://github.com/ec-jrc/JRC-EUROMOD-software-source-code
Re: Write code that is easy to delete, not easy to extend (2016)
#8Once you can load up a full codebase into an LLM I'm hoping the cost to update client code is significantly reduced. Then you could focus on evolving the design without all the grunt work.
Re: Write code that is easy to delete, not easy to extend (2016)
#9Yep, to recycle a brief analysis of my own youthful mistakes: ____ I've come to believe the opposite, promoting it as "Design for Deletion." I used to think I could make a wonderful work of art which everyone will appreciate for the ages, crafted so that every contingency is planned for, every need met... But nobody predicts future needs that well. Someday whatever I make is going to be That Stupid Thing to somebody,…
It still depends. Business line application yes and 10x yes. It will change it will move, don’t try to foresee business requirements. Just write something that will be easy to replace or throw away. Frameworks and libraries not really, for those you still have to adjust to whatever happens in the world but at much saner pace. Biggest issue is when devs want to write “framework” when they work on business line applica…
> Business line application yes and 10x yes. It will change it will move, don’t try to foresee business requirements. Just write something that will be easy to replace or throw away.
This is correct, but from my experience of working in the same company for over a decade: You'll learn to foresee requirements. Especially the "we'll never need that" ones that become business critical after a few months/years...
Re: Write code that is easy to delete, not easy to extend (2016)
#10Once you can load up a full codebase into an LLM I'm hoping the cost to update client code is significantly reduced. Then you could focus on evolving the design without all the grunt work.
I'm also betting on this, that one day I'll be able to dump a codebase into an LLM and it will clean up the code. Not rewrite it, not restructure it, just clean it up. Remove unused code and comment it sensibly. Maybe also suggest some tests for it and implement them separately.