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

101–110 of 113 posts

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

#101

Post by teddyh »

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

Analogous to Gresham’s law: “bad money drives out good” (https://en.wikipedia.org/wiki/Gresham%27s_law):

Good code is easy to replace, bad code is hard to replace. Therefore, all good code will, absent other forces, eventually be replaced by bad code.

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

#102

Post by BurningFrog »

gcpwnd wrote: post #86
BurningFrog wrote: post #27

Earlier quoted context omitted.

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

DRY is not very useful as a concept. It doesn't define any rules how to identify bad repeated code, nor how to change it and doesn't define limitations of the concept or it's application. I know this sounds wild and harsh but we have to overcome the habit of explaining non trivial or even unsolved problems with truisms.

Yeah, it really only points out where you have a problem.

The solution is still up to your expertise. Including deciding some repetition in OK.

Still, being able to see these design problems has been immensely valuable in my work!

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

#103

Post by teddyh »

hedora wrote: post #73
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).

Many people argue systemd is an example of code that’s easy to delete being replaced with code that’s hard to delete. They’ve deleted init, the dns client, dhcpd, the whole xdm family, various small open desktop protocols, kernel-level file permissions enforcement on certain device files, rsyslog, countless shell scripts for running background tasks via ssh, and I’m sure hundreds, if not thousands, of other well-modu…

> some systemd subsystem wedged during the upgrade. Now networking is broken.

All software has problems. Without specific details, blaming your problem on systemd specifically seems just as unreasonable as blaming “Linux” or even “Unix”. In fact, in past years during the old OS wars, there were many such rants, blaming “Unix”. (See for instance The Unix-Haters Handbook.) Become a curmudgeon, and idolize the past, at your own peril.

I recommend, instead, to live in the present, to use currently normal software, and to fix every problem as it appears. Ceasing to upgrade permanently (possibly by moving to an obviously dead-end fork) is never a sensible option in the long run.

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

#104

Post by butisaidsudo »

dkarl wrote: post #91

Microservices tip for this: Don't put code into a shared library without careful consideration of the consequences. Even if it is used in multiple services, consider duplicating it instead, and compare the risks and trade-offs compared to putting it in a shared library. Common scenario: New developer: "I'm done refactoring the implementation of the BingBong class in the shared library. It was a lot of work to change…

Yup, I'm a big believer in applying the rule of three ( https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra... ) for moving code into a library as well. I find if I create an API with just one or two examples in mind, it often doesn't turn out to be as general as I thought it would be. By the time I've done something three times, I have a much better idea of what the different use cases will be.

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

#105

Post by mumblemumble »

teddyh wrote: post #103
hedora wrote: post #73

Earlier quoted context omitted.

Many people argue systemd is an example of code that’s easy to delete being replaced with code that’s hard to delete. They’ve deleted init, the dns client, dhcpd, the whole xdm family, various small open desktop protocols, kernel-level file permissions enforcement on certain device files, rsyslog, countless shell scripts for running background tasks via ssh, and I’m sure hundreds, if not thousands, of other well-modu…

> some systemd subsystem wedged during the upgrade. Now networking is broken. All software has problems. Without specific details, blaming your problem on systemd specifically seems just as unreasonable as blaming “Linux” or even “Unix”. In fact, in past years during the old OS wars, there were many such rants, blaming “Unix”. (See for instance The Unix-Haters Handbook .) Become a curmudgeon, and idolize the past, at…

Don't bring the Unix-Haters Handbook into this. A fun, self-consciously curmudgeonly romp like that has about as much in common with the systemd debate as P.J. O'Rourke does with Bill O'Reilly.

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

#106

Post by ben0x539 »

staycoolboy wrote: post #84

Fun read, but does anyone actually change their coding practices based on high-level essays like this? HN seems to be filled with a highly opinionated bunch, and I question the point of these musings.

I find value in essays like that even if they don't make me write completely different code tomorrow. Having design consideration clearly laid out and discussed is really helpful, imo. (Of course that varies with how effective the essay is at conveying its points and how relevant the points are to me to begin with.)

Maybe I've been thinking about similar things myself but never got around to thinking it all the way through or formulating actionable conclusions. Then reading the essay is just like having bits and pieces fall into place in my mind and having disorganized thoughts finally make sense, like a shortcut through the whole mental bureaucracy of forming opinions.

Maybe I've been having a disagreement with coworkers about something the essay discusses. Then reading the essay may open up a new perspective on the issue, or introduce terminology that helps us discuss things more clearly, or at least validate that we're discussing something meaningful that other people have also had to think about.

Maybe I've already been doing exactly what the hypothetical essay advocates for! But I've always felt kind of bad about it because I couldn't convince myself that I'm doing it for a good reason, and now the essay is making me feel better about myself.

Maybe the essay is completely wrong, but it's wrong enough that it provokes an expert into writing an enlightening comment on the details on why and how it's wrong, and how to be less wrong.

More people should write more essays, even if they don't end up as seminal blogposts that are cited for decades to come.

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

#107

Post by grugagag »

ben0x539 wrote: post #106
staycoolboy wrote: post #84

Fun read, but does anyone actually change their coding practices based on high-level essays like this? HN seems to be filled with a highly opinionated bunch, and I question the point of these musings.

I find value in essays like that even if they don't make me write completely different code tomorrow. Having design consideration clearly laid out and discussed is really helpful, imo. (Of course that varies with how effective the essay is at conveying its points and how relevant the points are to me to begin with.) Maybe I've been thinking about similar things myself but never got around to thinking it all the way t…

Perhaps you are using your intuition. I do let it guide me without overanalizing every decision but more like feeling it. Programming is also an art and intuition can play a bigger role in it. Engineering is the organized form but built on pre-existent ideas enforcing helpful boundaries.

I think when faced with too many slices in decision-making and decision considerations as you put it, it could become overwhelming especially if one is not completely sold on a certain ideology/opinion to fight for. Thats where intuition can be a good guide. However, intuition can do only as much, it needs to feed off at times with some external input such as this type of opinionated articles.

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

#108

Post by flohofwoe »

teddyh wrote: post #103
hedora wrote: post #73

Earlier quoted context omitted.

Many people argue systemd is an example of code that’s easy to delete being replaced with code that’s hard to delete. They’ve deleted init, the dns client, dhcpd, the whole xdm family, various small open desktop protocols, kernel-level file permissions enforcement on certain device files, rsyslog, countless shell scripts for running background tasks via ssh, and I’m sure hundreds, if not thousands, of other well-modu…

> some systemd subsystem wedged during the upgrade. Now networking is broken. All software has problems. Without specific details, blaming your problem on systemd specifically seems just as unreasonable as blaming “Linux” or even “Unix”. In fact, in past years during the old OS wars, there were many such rants, blaming “Unix”. (See for instance The Unix-Haters Handbook .) Become a curmudgeon, and idolize the past, at…

I think the point of the parent was that systemd will be much harder to replace than other init mechanisms once something better comes along, because it grows into every part of a Linux setup. And if that's true, then systemd actually hinders progress and innovation, because the cost of replacement will be too high.

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

#109

Post by teddyh »

flohofwoe wrote: post #108
teddyh wrote: post #103

Earlier quoted context omitted.

> some systemd subsystem wedged during the upgrade. Now networking is broken. All software has problems. Without specific details, blaming your problem on systemd specifically seems just as unreasonable as blaming “Linux” or even “Unix”. In fact, in past years during the old OS wars, there were many such rants, blaming “Unix”. (See for instance The Unix-Haters Handbook .) Become a curmudgeon, and idolize the past, at…

I think the point of the parent was that systemd will be much harder to replace than other init mechanisms once something better comes along, because it grows into every part of a Linux setup. And if that's true, then systemd actually hinders progress and innovation, because the cost of replacement will be too high.

Possibly, but that was not the part which I chose to comment.

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

#110

Post by teddyh »

mumblemumble wrote: post #105
teddyh wrote: post #103

Earlier quoted context omitted.

> some systemd subsystem wedged during the upgrade. Now networking is broken. All software has problems. Without specific details, blaming your problem on systemd specifically seems just as unreasonable as blaming “Linux” or even “Unix”. In fact, in past years during the old OS wars, there were many such rants, blaming “Unix”. (See for instance The Unix-Haters Handbook .) Become a curmudgeon, and idolize the past, at…

Don't bring the Unix-Haters Handbook into this. A fun, self-consciously curmudgeonly romp like that has about as much in common with the systemd debate as P.J. O'Rourke does with Bill O'Reilly.

I don’t know who any of those people are.
Post reply on HN