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

41–50 of 102 posts

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

#41

Post by soco »

jumploops wrote: post #29
antonhag wrote: post #25

Earlier quoted context omitted.

+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?

The usual metric is complexity, but that can be hard to measure in every instance. Used within a team setting, what is simple is entirely subjective to that set of experiences. Example: Redis is dead simple, but it's also an additional service. Depending on the team, the problem, and the scale, it might be best to use your existing RDBMS. A different set of circumstances may make Redis the best choice. Note: I love "…

Dull?

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

#42

Post by kraftman »

worstspotgain wrote: post #24

At the risk of turning a unison into a chord, here's my two cents. If: 1. You know where the 'creases' of orthogonality are. You've carved the turkey 1000 times and you never get it wrong anymore. 2. As a result, there is hardly any difference in complexity between code that is and isn't easy to extend. Then write code that is easy to extend, not delete. The question is whether your impression of the above is true. I…

Could you give an example of your point? Isn't writing orthogonal code the same as writing code that's easy to delete?

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

#43

Post by seb1204 »

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?

Indeed, simple is not a good word to qualify something technical. I have a colleague and if he comes up with something new and simple it usually takes me down a rabbit hole of mind bending and head shaking. A matter of personal perspective?

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

#46

Post by ropejumper »

qwertox wrote: post #10
ollysb wrote: post #8

Once you can load up a full codebase into an LLM I'm hoping the cost to update client code is significantly reduced. Then you could focus on evolving the design without all the grunt work.

I'm also betting on this, that one day I'll be able to dump a codebase into an LLM and it will clean up the code. Not rewrite it, not restructure it, just clean it up. Remove unused code and comment it sensibly. Maybe also suggest some tests for it and implement them separately.

Comments should be based on intention. If I, as the programmer, am writing a piece of code and feel like there's something that I need to communicate about my intention in writing this, then I should. But if it's just surface level analysis, comments are just noise most of the time.

I don't see why this would be useful.

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

#47

Post by noisy_boy »

KronisLV wrote: post #15
Terr_ wrote: post #2

Yep, to recycle a brief analysis of my own youthful mistakes: ____ I've come to believe the opposite, promoting it as "Design for Deletion." I used to think I could make a wonderful work of art which everyone will appreciate for the ages, crafted so that every contingency is planned for, every need met... But nobody predicts future needs that well. Someday whatever I make is going to be That Stupid Thing to somebody,…

> So instead, put effort into making it easy to remove. You might, but there's also going to be other people that will happily go ahead and create abstractions and logic that will form the very core of a project and entrench themselves to such a degree that they're impossible to get rid of. For example, you might stumble upon CommonExcelFileParser, CommonExcelFileParserUtilities, HasExcelParseStatus, ProductImportExc…

Dealing with precisely this right now. Written by a consultant who I, maybe uncharitably, suspect is trying to ensure his job security. At this point, it is harder to even understand what's going on behind layers of handlers, factories and handler factories, forget about removing things. It works though and so no one wants to stick their neck out and call it out for the fear of being labelled "not smart".

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

#48

Post by mherrmann »

Glaring mistake in the first paragraph:

> The problem with code re-use is that it gets in the way of changing your mind later on.

This is simply incorrect, especially in the generality in which it is stated. If you change your mind and the code was copy-pasted to ten places, then you have to change ten places. On the other hand, if the code is in a function, then you only need to change it once. And if you do find that one of the ten invocations should not be changed, then you can still copy-paste - or make the function more general.

Like crossing a street without looking, copy-pasting is almost always a bad idea.

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

#49

Post by braden-lk »

mherrmann wrote: post #48

Glaring mistake in the first paragraph: > The problem with code re-use is that it gets in the way of changing your mind later on. This is simply incorrect, especially in the generality in which it is stated. If you change your mind and the code was copy-pasted to ten places, then you have to change ten places. On the other hand, if the code is in a function, then you only need to change it once. And if you do find th…

In my experience, bad copy pasted code results in an annoying afternoon of tech debt repayment and fixes. Badly abstracted code results in months of tech debt repayment.

Of course, the answer is “don’t make bad abstractions”, but we all know how that one goes with a team and changing product reqs.

Post reply on HN