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

91–100 of 113 posts

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

#91

Post by dkarl »

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 and test all the frobnicateXxxx methods!"

Manager: "Wait, I thought none of our services do any frobnification?"

The old hands discuss: "They don't. Not anymore." "Are we sure? Perhaps the Foo service we haven't touched since last year?" "No, the Foo service never did." "Let's search the repos. Maybe we can delete some of these methods." "This is weird. We have seven different frobnicate methods, and we never needed to support that many different kinds of frobnification." "Of course. It's such a pain to roll out a new major version of a library, you don't want to change anything existing." "Do you remember when the rendering service was stuck on version 3 of the auth library? It was because we removed a method from the auth library and rolled out 4.0 without it. Turns out it was being used on a feature branch in the rendering service that got merged right before the release." "I remember. I'm the one who had to roll out version 4.1 the next day with exactly the same code as version 3.7."

There's a simple way of understanding how stories like this happen, and a simple conclusion: Once functionality is added to a shared library, changing it requires much more care. Therefore, shared code is much more expensive to maintain than non-shared code. This is why it makes sense to ask a question like, "Which is cheaper in the long run, maintaining three non-shared copies of this code, or maintaining one shared copy?"

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

#92

Post by onetimertwo »

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…

Try Alpine Linux. It ticks a, b and d. I don't know about i2c userspace tools, but it is the easiest of these to add yourself.

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

#93

Post by lmohseni »

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…

Openbsd checks all these boxes!

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

#94

Post by perryizgr8 »

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…

Try Win10 for RPI.

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

#95

Post by fulafel »

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…

Raspberry Pi hardware is not really suited for "decades" reliability. If you want to use it for an application like this, you need to arrange to recover/replace the devices in the field and plan how to upgrade out of production models in a controlled way. (And you need to rehearse/test doing it too so it works when you need to do it, especially as things change between RPi hardware generations)

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

#96

Post by kilburn »

mumblemumble wrote: post #90
dkarl wrote: post #88

Earlier quoted context omitted.

> But there's this thing, and I don't quite understand how it happens, where it seems to be really easy to implement the cosmetic parts of the programming style he advocates while simultaneously achieving the diametric opposite of the fundamental goals that these techniques are supposed to achieve. All of OOP is like this. The most enthusiastic OOP adherents create the biggest OOP messes. Maybe every style of program…

I once encountered a take on this that rang quite true to me, though I can't for the life of me find where I read it. The observation was that good object-oriented design is inherently unstable. With even slight perturbations, they can quickly spiral away into a mess. And those perturbations tend to happen almost constantly in real life, because writing SOLID code requires vastly more skill, knowledge and effort than…

I play this role in my team, and as a team lead I take it as one of my responsibilities. What works for us is that when I don't approve something I explain why and work out an alternative implementation plan with them.

If we cannot come up with an alternative or cannot convince ourselves that it is indeed better, then the original implementation goes in. Otherwise we move forward with the new plan. I'd say that that (when I challenge an implementation) around 4 out of 5 times we end up with a new implementation.

The team is very happy with this approach, or so I've been told. It wastes some time in the short term (hey the thing worked, why are you overhauling it?) but our manager's perception of good team motivation and resulting quality is what buys me the leeway to keep doing it.

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

#99

Post by gruez »

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

reminds me of https://github.com/avinassh/rockstar

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

#100

Post by Skunkleton »

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…

> So, I need to find an operating system that...

Check out buildroot linux. I have had very good luck with this distro for professional embedded applications. It doesn't have the same annoyances that other common embedded linux distros have. It is easy to hack on, easy to customize, and if you must, it is easy to understand.

Post reply on HN