The unfortunate side effect of this (very good) advice is that all code that's easy to delete will eventually be replaced with code that's hard to delete (and thus will eventually be impossible to delete in order to be replaced with something better).
Write code that is easy to delete, not easy to extend (2016)
11–20 of 113 posts
Re: Write code that is easy to delete, not easy to extend (2016)
#12I wholeheartedly agree with "don't immediately jump on the modularize and abstract everything right away". I think that "modularization and abstraction is always and uniformly good" is one of the big lies of our profession. It’s easy to see how it’s attractive : programming is intellectual work, and displaying capacity of abstraction is rewarding. I was extremely enthusiastic about that stuff when I was young, too. T…
I would question your assumption that "clean code" that you describe is really modularization and abstraction. (In particular, separating everything into small scattered pieces, which is IMHO a horrible Java habit that I have to endure now.)
I mean, both modules and abstractions should have purpose.
The purpose of modules is to "do one task well" so to speak. So if for a typical change you need to modify several of them, you're not modularizing it right.
The purpose of abstraction is to provide another "language" which lets you forget certain technical details, while clarifying the bigger picture. Again, unless this language has been designed wrong, you shouldn't have to touch the abstraction.
Addendum: Of course, there is also the classic https://gbracha.blogspot.com/2011/06/types-are-anti-modular.... (and we can consider types to be a form of abstraction), so to some extend these things go against one another.
Re: Write code that is easy to delete, not easy to extend (2016)
#13I wholeheartedly agree with "don't immediately jump on the modularize and abstract everything right away". I think that "modularization and abstraction is always and uniformly good" is one of the big lies of our profession. It’s easy to see how it’s attractive : programming is intellectual work, and displaying capacity of abstraction is rewarding. I was extremely enthusiastic about that stuff when I was young, too. T…
> Also, changing the slightest things required to go through 5-6 files.
That is a sign it was incorrectly modularised. Good modularisation means high cohesion and low coupling. Having to make changes in multiple files means the opposite.
Don't rack on modularisation (great concept!) when your only experiences are of bad implementations of it. (Which is not surprising, because most people do get it wrong.)
Maybe the takeaway is "better not do it at all than do it incorrectly."
More concretely, the code you describe seems to have suffered from the awful common implementation of the model-view-controller pattern, where module boundaries are based on technical implementation details (routes are their own module, pages their own, controllers their own, etc.) This looks "clean" when you are inexperienced, but it is contrary to all good modularisation.
Module boundaries should be based on business domain concepts, not implementation details.
Re: Write code that is easy to delete, not easy to extend (2016)
#14I have to confess, I was a solid halfway through before I realized it was satire.
You missed the Sarte quote about programming in C at the top then. It's at least good satire, it's so close to the real kind of article it apes.
It's not satire; the technique of peppering a work like this with slightly-modified-famous-out-of-domain-quotes is not a tool of satire but of implicit metaphor.
Re: Write code that is easy to delete, not easy to extend (2016)
#15The unfortunate side effect of this (very good) advice is that all code that's easy to delete will eventually be replaced with code that's hard to delete (and thus will eventually be impossible to delete in order to be replaced with something better).
It is like the Murphy's law of deletable code "Anything that can be made hard to delete will be made hard to delete".
Re: Write code that is easy to delete, not easy to extend (2016)
#16I wholeheartedly agree with "don't immediately jump on the modularize and abstract everything right away". I think that "modularization and abstraction is always and uniformly good" is one of the big lies of our profession. It’s easy to see how it’s attractive : programming is intellectual work, and displaying capacity of abstraction is rewarding. I was extremely enthusiastic about that stuff when I was young, too. T…
> Very clean. Also, changing the slightest things required to go through 5-6 files.
No, it was not clean at all!
Re: Write code that is easy to delete, not easy to extend (2016)
#17This was part of the initial idea of extension. David Parnas' 1970's paper that popularised the term was called Designing for the Ease of Extension and Contraction where "ease of contraction" refers to subsettability, i.e. removing parts of the code without having to change other parts.
These original papers are well worth a read!
Re: Write code that is easy to delete, not easy to extend (2016)
#18I wholeheartedly agree with "don't immediately jump on the modularize and abstract everything right away". I think that "modularization and abstraction is always and uniformly good" is one of the big lies of our profession. It’s easy to see how it’s attractive : programming is intellectual work, and displaying capacity of abstraction is rewarding. I was extremely enthusiastic about that stuff when I was young, too. T…
> Loccount on my "ugly, not modular" backend[...]
>
> all SLOC=2284 (100.00%) LLOC=0 in 13 files
>
> Loccount on the "very clean" backend of the previous contractor:
>
> all SLOC=12507 (100.00%) LLOC=0 in 262 files
This begs the question: so what?
Comparison will only make sense when another pour soul will try and change something on the likely mess you look proud to have created. What you found was not well maintainable, but will work be?
Re: Write code that is easy to delete, not easy to extend (2016)
#19I have to confess, I was a solid halfway through before I realized it was satire.
That sounds dismissive, did you intend that? It's my favorite type of writing. It tickles your brain. Does he mean it like he says? Do I agree? It makes you think, even when it sounds like he's telling you what to do.
Re: Write code that is easy to delete, not easy to extend (2016)
#20I wholeheartedly agree with "don't immediately jump on the modularize and abstract everything right away". I think that "modularization and abstraction is always and uniformly good" is one of the big lies of our profession. It’s easy to see how it’s attractive : programming is intellectual work, and displaying capacity of abstraction is rewarding. I was extremely enthusiastic about that stuff when I was young, too. T…
> Very clean. Also, changing the slightest things required to go through 5-6 files.
Martin Fowler's "Refactoring" is a great book (I only know the 2nd edition from 2019). From a naive understanding of the "clean code" school of thought one might assume that splitting up everything into small functions, classes, modules is always the way to go. But Fowler's advice is much more nuanced than that. His list of bad code smells includes the aptly named "Shotgun Surgery", which describes just your quoted situation. The suggested way to go is then to first inline all the scattered stuff, next to extract parts such that the logic is more contained.
Your rewrite sounds very similar. And of course you are right: School and books probably don't do a good job of transferring this knowledge. That "Shotgun Surgery" paragraph is easy to discard by a reader who hasn't experienced the pain themselves.