Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop future-proofing software

medium.com

Post reply on HN
Print view View original

21–30 of 63 posts

Re: Stop future-proofing software

#21

Post by squirrelicus »

al2o3cr wrote: post #7

> We need to use an inheritance based design for our types, > despite composition being a much easier alternative, because > after 5 years of codebase growth, it will make our lives > easier. And a equally future-proofy statement: "We need to contort our code to avoid our implementation language's inheritance features to instead use composition because after 5 years of codebase growth it will make our lives easier" T…

I admit being confused about this one. Composition or inheritance isn't harder or more work, and neither provides velocity or maintainability benefits. The argument is about how to model complex behavior -- they have tradeoffs in duplication and statefulness. And you can mix both in the same code base with ease.

Here's another one though. We need to use Promises despite callbacks being trivially understandable and supported everywhere in arbitrary JavaScript versions because in 5 years everyone will probably always use Promises for everything.

Re: Stop future-proofing software

#22

Post by jarfil »

drdaeman wrote: post #9

> We need to use a kubernetes & docker based solution for our infrastructure, despite a single large server being a much easier alternative It's a half-truth that one doesn't have to do it from the very beginning. You don't have to set up a whole cluster where a single host suffices for a long while. You do have to plan that your project may eventually become big enough to require a cluster - and consider doing yours…

I find using Docker (or any container) actually simpler than maintaining a pet server, even if you never need a cluster or Kubernetes. Just the ability to develop & test in an environment identical to production is a huge benefit on its own.

Re: Stop future-proofing software

#23

Post by richardwhiuk »

squirrelicus wrote: post #21
al2o3cr wrote: post #7

> We need to use an inheritance based design for our types, > despite composition being a much easier alternative, because > after 5 years of codebase growth, it will make our lives > easier. And a equally future-proofy statement: "We need to contort our code to avoid our implementation language's inheritance features to instead use composition because after 5 years of codebase growth it will make our lives easier" T…

I admit being confused about this one. Composition or inheritance isn't harder or more work, and neither provides velocity or maintainability benefits. The argument is about how to model complex behavior -- they have tradeoffs in duplication and statefulness. And you can mix both in the same code base with ease. Here's another one though. We need to use Promises despite callbacks being trivially understandable and su…

I think the real takeaway is that composition is much more likely to model the semantics you have, even though inheritance feels like it gives you better code re-use.

Re: Stop future-proofing software

#24

Post by pvg »

al2o3cr wrote: post #7

> We need to use an inheritance based design for our types, > despite composition being a much easier alternative, because > after 5 years of codebase growth, it will make our lives > easier. And a equally future-proofy statement: "We need to contort our code to avoid our implementation language's inheritance features to instead use composition because after 5 years of codebase growth it will make our lives easier" T…

then spends half the book covering inheritance

Does it really? The bulk of the patterns are about composition and delegation which is why wags using languages less restrictive than C++ have been able to do things like show 47819.73 patterns are variants of one or two things.

Re: Stop future-proofing software

#25

Post by imhoguy »

I saw startups struggle with ops and run out of runway implementing trendy micro-services from first day. But then I saw successful startups flourished from faux pas CLI-generated monoliths and no-brainer deployment templates. MVP FTW!

Re: Stop future-proofing software

#27

Post by rhizome »

dominotw wrote: post #16
sz4kerto wrote: post #8

As Martin Fowler correctly explains, YAGNI is primarily about end-user features, not the flexibility of the code and the toolchain. If you don't keep your tech stack (code, infrastructure, people) flexible, then iterative development becomes impossible. The assumption behind YAGNI is that 'you can't predict requirements accurately'. Which is true, so don't build them ahead of time. However, the same assumption requir…

> If you don't keep your tech stack (code, infrastructure, people) flexible, then iterative development becomes impossible. Thats the crux of the problem. Different people have different definitions of flexible. How are you defining it?

Well obviously it's going to be in their code style document(s) given to every programmer during onboarding.

Re: Stop future-proofing software

#29

Post by suzzer99 »

ChuckMcM wrote: post #13

This article reminds me of the adage about ops people which goes, "You know you're doing a great job in operations when nobody thinks you do anything." The problem with taking the experience that "future proofing" is never worth it, is that it suffers from survival bias, which is to say that when you did it and it made the future event a non-event, it didn't even register on your brain. If you practice more mindful e…

https://www.quora.com/What-are-the-growth-stages-of-a-progra...

Second phase of a developer:

2. The philosophizing abstracter

"This code works for now, but if I move this part into a factory, and create an interface for these methods, it'll also support all these future cases I can think of!"

They've read all the articles on how to structure code. There's a lot of patterns out there for object-oriented (or functional!) code. Their code has all sorts of useful interfaces, abstraction layers, factories, extension methods, data structures.

Things break down when the project needs to move in an unexpected direction and it turns out that implementing the change requires changing a lot of the codebase because there were a bit too many abstractions that ended up creating hidden dependencies across the code.

Re: Stop future-proofing software

#30

Post by px1999 »

This may be true while searching for product market fit, but once you hit a certain (small but stable) size, your ability to identify what your existing and future customers currently want, and will in the near to mid future want goes up.

There's a difference between future proofing to be able to deliver a roadmap or using your market research to get the next X customers and trying to guess at what some as yet unknown market might one day want.

Post reply on HN