Why not both?
Write code that is easy to delete, not easy to extend (2016)
11–20 of 102 posts
Re: Write code that is easy to delete, not easy to extend (2016)
#12My favorite saying: “simple is robust”
Similar in spirit to Lehman’s Law of Continuing Change[0], the idea is that the less complexity a system has, the easier it is to change.
Rather than plan for the future with extensible code, plan for the future with straightforward code.
E.g. only abstract when the situation requires it, encourage simple duplication, use monoliths up front, scale vertically before horizontally, etc.
I’ve built many 0-1 systems, and this is the common thread among all of them.
[0] https://en.m.wikipedia.org/wiki/Lehman%27s_laws_of_software_...
Re: Write code that is easy to delete, not easy to extend (2016)
#13Implementing 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.
Can you explain what you mean with "implementing choice"?
Re: Write code that is easy to delete, not easy to extend (2016)
#14Yep, 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…
I would say the biggest issue are the frameworks themselves: they practically force you to fit your code to their architecture, and before you know it, your logic is split across innumerable classes. Laravel (with which I have the most experience) has models, controllers, views, service providers, data transfer objects etc. etc. - that makes it (arguably) easier to write and extend code, but very hard to refactor/delete.
Re: Write code that is easy to delete, not easy to extend (2016)
#15Yep, 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,…
> So instead, put effort into making it easy to remove.
You might, but there's also going to be other people that will happily go ahead and create abstractions and logic that will form the very core of a project and entrench themselves to such a degree that they're impossible to get rid of.
For example, you might stumble upon CommonExcelFileParser, CommonExcelFileParserUtilities, HasExcelParseStatus, ProductImportExcelParser, ProductImportExcelParserView, ProductImportExcelParserResultHandler and who knows what else, the kind of stuff that ends up being foundational for the code around it, much like how if you start a front end project in React or Angular, migrating to anything else would be a Sisyphean task.
In practice, that means that people end up building a whole platform and you basically have to stick with it, even though some of the choices made might cause bunches of problems in the future and, due to all of the coupling, refactoring is way harder than it would be in an under-abstracted codebase.
I'm not sure what to do then. People seem to like doing that more than applying KISS and YAGNI and making code easy to delete.
Re: Write code that is easy to delete, not easy to extend (2016)
#16Implementing 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.
Can you explain what you mean with "implementing choice"?
This was written in the context of a discussion about showing resistance or not to feature requests by users sorry for the confusion.
Re: Write code that is easy to delete, not easy to extend (2016)
#17Related:
Write code that is easy to delete, not easy to extend (2016) - https://news.ycombinator.com/item?id=24989351 - Nov 2020 (30 comments)
Write code that is easy to delete, not easy to extend (2016) - https://news.ycombinator.com/item?id=23914486 - July 2020 (109 comments)
Write code that is easy to delete, not easy to extend - https://news.ycombinator.com/item?id=18761739 - Dec 2018 (2 comments)
Write code that is easy to delete, not easy to extend - https://news.ycombinator.com/item?id=11093733 - Feb 2016 (133 comments)
Re: Write code that is easy to delete, not easy to extend (2016)
#18My favorite saying: “simple is robust” Similar in spirit to Lehman’s Law of Continuing Change[0], the idea is that the less complexity a system has, the easier it is to change. Rather than plan for the future with extensible code, plan for the future with straightforward code. E.g. only abstract when the situation requires it, encourage simple duplication, use monoliths up front, scale vertically before horizontally,…
Sure, but when applying "simple is robust" principle it is extremely important to understand also intrinsic complexity. Not handling edge-cases etc does not make for robust code, no matter how much simpler it is.
Re: Write code that is easy to delete, not easy to extend (2016)
#19My favorite saying: “simple is robust” Similar in spirit to Lehman’s Law of Continuing Change[0], the idea is that the less complexity a system has, the easier it is to change. Rather than plan for the future with extensible code, plan for the future with straightforward code. E.g. only abstract when the situation requires it, encourage simple duplication, use monoliths up front, scale vertically before horizontally,…
> encourage simple duplication
A rule I like to follow:
- first time: write it
- second time: copy it
- third time: maybe refactor it
Re: Write code that is easy to delete, not easy to extend (2016)
#20Yep, 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,…
> So instead, put effort into making it easy to remove. You might, but there's also going to be other people that will happily go ahead and create abstractions and logic that will form the very core of a project and entrench themselves to such a degree that they're impossible to get rid of. For example, you might stumble upon CommonExcelFileParser, CommonExcelFileParserUtilities, HasExcelParseStatus, ProductImportExc…
Not my originals, and I cannot recall who said this... But it's completely on point
* Software has a tendency to become maximally complex. You either have an actually complex domain, or the developers will find a way to increase the complexity (..because otherwise, they're bored)
* Good software is modular and easy to remove. Consequently, good software will keep getting replaced until it's bad and cannot be removed anymore