Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write code that is easy to delete, not easy to extend (2016)

programmingisterrible.com

Post reply on HN
Print view View original

21–30 of 113 posts

Re: Write code that is easy to delete, not easy to extend (2016)

#21

Post by rimliu »

slooonz wrote: post #10

I 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…

Sandy Metz' book "99 bottles" (there was a second edition recently, now you can choose between beer and milk and between Ruby and Javascript) tries to hammer those points in. I'd say it basically dedicated to the topic. You have one problem and explore differnt ways to approach it with pros and cons revealed and discussed along the way. And "do not rush with an abstraction" is something that Sandy tries to get accross. The wrong abstraction will cost you more in a long run than some code duplication. Highly recommended.

Re: Write code that is easy to delete, not easy to extend (2016)

#22

Post by earthscienceman »

kmorgh wrote: post #7

This guy has a talk too with the same kind of tone about the whole industry. Had a good laugh when I was starting out. https://youtu.be/AUYPnxv0yss

Here's his github too, if anyone's interested. Fairly prolific to say the least:

https://github.com/tef

Re: Write code that is easy to delete, not easy to extend (2016)

#23

Post by gcpwnd »

kqr wrote: post #13
slooonz wrote: post #10

I 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 t…

That sounds like myriads of programmers have done it wrong for decades. Can you elaborate on this and maybe add a few sources?

Re: Write code that is easy to delete, not easy to extend (2016)

#25

Post by edelans »

earthscienceman wrote: post #22
kmorgh wrote: post #7

This guy has a talk too with the same kind of tone about the whole industry. Had a good laugh when I was starting out. https://youtu.be/AUYPnxv0yss

Here's his github too, if anyone's interested. Fairly prolific to say the least: https://github.com/tef

most of the commits are empty

https://github.com/tef/0.0/commit/59575ac7d888c60eb043fe3b3c...

Re: Write code that is easy to delete, not easy to extend (2016)

#26

Post by mariusmg »

edelans wrote: post #25
earthscienceman wrote: post #22

Earlier quoted context omitted.

Here's his github too, if anyone's interested. Fairly prolific to say the least: https://github.com/tef

most of the commits are empty https://github.com/tef/0.0/commit/59575ac7d888c60eb043fe3b3c...

Yeah, that's the joke....

Re: Write code that is easy to delete, not easy to extend (2016)

#27

Post by BurningFrog »

gcpwnd wrote: post #23
kqr wrote: post #13

Earlier quoted context omitted.

> 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 t…

That sounds like myriads of programmers have done it wrong for decades. Can you elaborate on this and maybe add a few sources?

If you have to change in 5 places to change one "thing", the code is probably not DRY.

Re: Write code that is easy to delete, not easy to extend (2016)

#28

Post by tobr »

nxpnsv wrote: post #15
flohofwoe wrote: post #11

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).

It is like the Murphy's law of deletable code "Anything that can be made hard to delete will be made hard to delete".

More like a variant of the Peter principle: all code tends to be refactored to its level of unrefactorability.

Re: Write code that is easy to delete, not easy to extend (2016)

#29

Post by jingw222 »

flohofwoe wrote: post #11

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).

I don't see your point. Code that's more modular, pluggable is by definition easier to delete. That should not be a reason to prevent us writing easy to delete code.

Re: Write code that is easy to delete, not easy to extend (2016)

#30

Post by kqr »

jingw222 wrote: post #29
flohofwoe wrote: post #11

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).

I don't see your point. Code that's more modular, pluggable is by definition easier to delete. That should not be a reason to prevent us writing easy to delete code.

It took me a while to get it too: someone else downthread summarised it neatly as a version of the Peter principle:

> all code tends to be refactored to its level of unrefactorability.

This was a neat way to look at it!

Post reply on HN