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

71–80 of 102 posts

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

#71

Post by friendzis »

Skeime wrote: post #67
zokier wrote: post #18

Earlier quoted context omitted.

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.

Yes, but I definitely also see the opposite quite a bit: Somebody several layers down thought that something was an edge case, resolved it in a strange way, and now you have a chain of stuff above it dealing with the edge case because the bottom layer took a wrong turn. The most common examples are empty collections: either disallowing them even though it would be possible to handle them, or making a strange choice l…

Your example perfectly illustrates oversimplification: attempt to stuff categorical variable into another of lower order. If a language has absence of value available as an expressible concept (nullability), then a list is at least 3-way categorical variable: absence of value, empty list, non-empty list. Any attempts to stuff that into a binary truthy value will eventually leak one way or another.

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

#72

Post by kraftman »

VeejayRampay wrote: post #60

it's crazy how we keep going through all those injunctions (religions) about software, they all look amazing on paper, feel like common sense and yet 50 years in, software is garbage 90% of the time yet, we keep bringing this stuff up like it's some sort of genius insight / silver bullet

I think it's because 90% of the garbage is being written by people that don't read or write articles like this one.

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

#73

Post by Powdering7082 »

Pretty wild that none of this talks about testing or observability. Tests are also something that you need to pay to maintain, but they give the ability of reducing the risk that you broke something when you removed it. Additionally when you've exposed your service to potential external callers you need to both have a robust way of marking some calls as deprecated, to be deleted as well as observing whether they are still being called and by what.

I recently did our first semi-automated removal of exposed graphql resolvers, metrics about how often a given resolver was already available so parsing that yielded the set of resolvers I *couldn't* delete. Graphql already has a deprecated annotation, but our service didn't handle that annotation in any special way. I added observability to flag if any deprecated functions have been called & then let that run for sufficiently long in prod, then you can safely delete externally exposed code.

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

#74

Post by directevolve »

antonhag wrote: post #25
jumploops wrote: post #12

My 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,…

+1, but I'm not sure if the "simple is robust" saying is straightforward enough? It opens up to discussion about what "simple" means and how it applies to the system (which apparently is a complex enough question to warrant the attention of the brilliant Rich Hickey). Maybe "dumb is robust" or "straightforward is robust" capture the sentiment better?

Copy/paste is robust?

As a biomedical engineer who primarily writes software, it’s fun to consider analogies with evolution.

Copy/pasting and tweaking boilerplate is like protein-coding DNA that was copied and mutated in our evolutionary history.

Dealing with messy edge cases at a higher level is like alternative splicing of mRNA.

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

#75

Post by VeejayRampay »

kraftman wrote: post #72
VeejayRampay wrote: post #60

it's crazy how we keep going through all those injunctions (religions) about software, they all look amazing on paper, feel like common sense and yet 50 years in, software is garbage 90% of the time yet, we keep bringing this stuff up like it's some sort of genius insight / silver bullet

I think it's because 90% of the garbage is being written by people that don't read or write articles like this one.

I don't think it's the case, because all those schools of thought (your DRY, your SOLID, your DDD, etc) all have opposite schools of thought rife with other similarly popular mantras

the problems in engineering rarely stem from the lack of principles and have way more to do with mismanaged projects, arbitrary deadlines, shifting priorities, unreliable sources of data, misunderstood business logic and all those fancy acronyms, all the SCRUM and agile in the world will never make up for all that

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

#76

Post by jolt42 »

arkh wrote: post #19
jumploops wrote: post #12

My 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

Everything in balance. While I agree with this philosophy, I've also seen lots of duplicate bugs because it wasn't realized there was two copies of the same bug.

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

#77

Post by kraftman »

ainiriand wrote: post #58
chikere232 wrote: post #55

Earlier quoted context omitted.

Because building for extensibility adds real complexity for a hypotetical need If you want the code to do something different later, change, replace or extend it then... when you actually know what it needs to do

I am not sure that is something that applies 100%, but I understand the concern. It is my understanding that we should try to build solutions to current problems, and be open to future use cases that could involve small additions in functionality. It would be stupid to design an unmodifiable system just because some parts can be deleted and we are not sure what future needs are. Code should always be easy to extend,…

Conversations like this are always difficult to discuss at a high level because the way we implement the words we use can be very different. Code can be written in a way that a lot of complexity is added in order to make it extensible, or it can be written in a way where simplification is used to make it extensible. Both authors would agree that extensible is good.

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

#78

Post by kraftman »

VeejayRampay wrote: post #75
kraftman wrote: post #72

Earlier quoted context omitted.

I think it's because 90% of the garbage is being written by people that don't read or write articles like this one.

I don't think it's the case, because all those schools of thought (your DRY, your SOLID, your DDD, etc) all have opposite schools of thought rife with other similarly popular mantras the problems in engineering rarely stem from the lack of principles and have way more to do with mismanaged projects, arbitrary deadlines, shifting priorities, unreliable sources of data, misunderstood business logic and all those fancy…

That's really not been my experience when reviewing code. Bad code I've seen has been due to misusing language features, not knowing the principles in these articles, or misunderstanding the principles or blanket applying them to everything.

For example, abstracting every piece of similar code to make it "DRY" because they don't understand that it's about concepts not code.

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

#79

Post by CharlieDigital »

Reading this:

    > To write code that’s easy to delete: repeat yourself to avoid creating dependencies, but don’t repeat yourself to manage them. Layer your code too: build simple-to-use APIs out of simpler-to-implement but clumsy-to-use parts. Split your code: isolate the hard-to-write and the likely-to-change parts from the rest of the code, and each other. Don’t hard code every choice, and maybe allow changing a few at runtime.
My experience is that the title doesn't hold. Code that is easy to delete is -- more often than not -- also easy to extend because it is layered, modular, and isolates different pieces through abstractions like interfaces or other type contracts.

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

#80

Post by andocars »

arkh wrote: post #19
jumploops wrote: post #12

My 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

change it, fix it, upgrade it.
Post reply on HN