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

31–40 of 102 posts

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

#31

Post by tetha »

jumploops wrote: post #27
arkh wrote: post #19

Earlier quoted context omitted.

> encourage simple duplication A rule I like to follow: - first time: write it - second time: copy it - third time: maybe refactor it

Agreed! I'll usually go one step further for early projects and lean towards 3rd time copy, 4th time refactor. Example: So much early code is boilerplate CRUD, that it's tempting to abstract it. 9 times out of 10, you'll create a quasi-ORM that starts inheriting business logic and quickly grows omni-functions. Eventually you may actually need this layer, assuming you're system miraculously scales to needing multiple…

Hence why I am rather looking if two pieces of code change together, opposed to just looking the same.

If I need to introduce the same feature in multiple places in roughly the same way, that's a decent indication code wants to be the same and wants to change together. That's something to consider extracting.

Fixing the same bug in several places is a similar, but weaker indication. It's weaker, because a bug might also occur from using a framework or a library wrong and you do that in several places. Fixing the same business logic error in several places could mean to centralize some things.

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

#32

Post by sam_lowry_ »

willtemperley wrote: post #26
sam_lowry_ wrote: post #7

Earlier quoted context omitted.

And yet the worst ever code I saw was in C#. I hope I won't offend anyone pointing at it [1]. This is a somewhat popular tool to evaluate macroeconomic policies in the EU. A combination of language choice (C# as a natural language Microsoft Excel bosses tend to request from their interns to use), the usual churn of academic undergrads and loads of other cultural failures are the reasons this monster exsts. Someone sh…

I could write about creating the worst possible environment to be a software developer, having worked at the JRC for five years. I'm not sure how constructive that would be. I'm still hurting because the IT department decided the only way to deploy my Java app was through rsyncing to a running Tomcat installation, allowing class files from several deployments previous to resurface in memory causing some beautiful bug…

> rsyncing to a running Tomcat installation

You can delete while resync'ing but I guess the issue is not in resyncing itself, but rather in the disempowerment of individual contributors.

You could have argued to add --delete for your case, as well as requesting a shutdown before and a start after, but I guess explaining this to countless morons is too much to ask from a humble developer.

OTOH, this resyncing story probably means that you were allowed to choose the wrong development framework to start with. Because resyncing PHP is much more reasonable.

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

#33

Post by ttyprintk »

revskill wrote: post #22

Write test, not code.

Specifically, write tests that identify disposable code. More specifically, you hopefully wrote some disposable code that is a modular extension of something close to the core. Write tests that demonstrate which of those deserves to be core, and which is necessary for a requirement but disposable. Since the article brings up shared apis, hopefully when you arrive on a new project, those are well understood as requirements paired with test cases. Repeat in the opposite direction in dependent projects.

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

#34

Post by willtemperley »

sam_lowry_ wrote: post #32
willtemperley wrote: post #26

Earlier quoted context omitted.

I could write about creating the worst possible environment to be a software developer, having worked at the JRC for five years. I'm not sure how constructive that would be. I'm still hurting because the IT department decided the only way to deploy my Java app was through rsyncing to a running Tomcat installation, allowing class files from several deployments previous to resurface in memory causing some beautiful bug…

> rsyncing to a running Tomcat installation You can delete while resync'ing but I guess the issue is not in resyncing itself, but rather in the disempowerment of individual contributors. You could have argued to add --delete for your case, as well as requesting a shutdown before and a start after, but I guess explaining this to countless morons is too much to ask from a humble developer. OTOH, this resyncing story pr…

No the issue was files cached in memory. No amount of deleting from the file system is going to delete files cached by the servlet, which is why the servlet itself needs to be restarted.

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

#35

Post by blitzar »

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…

> The question is whether your impression of the above is true

If you think you are good enough to qualify you almost certainly don't qualify. If you do qualify then chances are you probably don't think you do.

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

#36

Post by the_gipsy »

ffsm8 wrote: post #20
KronisLV wrote: post #15

Earlier quoted context omitted.

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

Not my originals, and I cannot recall who said this... But it's completely on point * Software has a tendency to become maximally complex. You either have an actually complex domain, or the developers will find a way to increase the complexity (..because otherwise, they're bored) * Good software is modular and easy to remove. Consequently, good software will keep getting replaced until it's bad and cannot be removed…

Hard to remove doesn't mean impossible to remove.

Refactoring or fixing bad codebases is a thing.

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

#37

Post by immibis »

zokier wrote: post #18
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,…

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.

Failing to account for this gives you Wayland (which at this time is more complex than X11)

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

#38

Post by alserio »

nextcaller wrote: post #16
alserio wrote: post #13

Earlier quoted context omitted.

Can you explain what you mean with "implementing choice"?

This was written in the context of a discussion about showing resistance or not to feature requests by users sorry for the confusion.

thank you

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

#39

Post by ffsm8 »

the_gipsy wrote: post #36
ffsm8 wrote: post #20

Earlier quoted context omitted.

Not my originals, and I cannot recall who said this... But it's completely on point * Software has a tendency to become maximally complex. You either have an actually complex domain, or the developers will find a way to increase the complexity (..because otherwise, they're bored) * Good software is modular and easy to remove. Consequently, good software will keep getting replaced until it's bad and cannot be removed…

Hard to remove doesn't mean impossible to remove. Refactoring or fixing bad codebases is a thing.

Yeah, it was probably "won't be removed anymore" or similar. As I said, I don't remember who said it and was kinda paraphrasing
Post reply on HN