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

31–40 of 63 posts

Re: Stop future-proofing software

#31

Post by sitkack »

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…

Simple systems are easy in nearly every dimension (extension, debugging, performance), and they are at natural odds with the state of affairs. There are hoards of programmers waiting to do a tech debt driveby to "look good" for having bolted a feature on in minutes to days.

Simple systems require extreme vigilance to remain simple.

Re: Stop future-proofing software

#32

Post by jlu »

arnon wrote: post #19

We built an SQL compiler in Haskell, and this has been our model from day 0 (back in 2010)... It's really easy to follow these rules with Haskell. We develop our syntax to be easily extensible. Being strongly and statically typed allows us to extend our parser/compiler with relative ease, and not think too much about how the future will look.

Any chance to open source and have a look? Thanks!

Re: Stop future-proofing software

#33

Post by BurningFrog »

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?

In this context it means that it's easy to make changes. As in add new functionality.

Re: Stop future-proofing software

#34

Post by mlthoughts2018 »

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?

Exactly. The same “end user” problems recursively repeats. You just think of other (or future) developers as the end users, and those actual user requirements you can’t predict, that ends up meaning you also cannot predict what the developers flexibility requirements will be either.

You end up “making your codebase flexible” in all the wrong ways by introducing abstractions, interfaces, and extensibility designs that end up being the wrong tool for the job once the future requirements are known.

There may still be a simplistic, high level where you can have certainty about how to factor code. E.g. separating front-end and back-end, using tests as scaffolding for helping verify deployments and facilitate changing code, using a few simple tricks here and there to reduce boilerplate or make sections of code reusable.

It’s totally fine to pursue these optimizations, especially if they are part of a healthy backlog process to prioritize them.

But the problem creeps in when principal developers or “philosophizing architects” take it as a goal unto itself and begin trying to mandate it all the time, especially with the anti-pattern where huge architecture discussions become synonymous with routine “just get something done that works and refactor later” code reviews.

Re: Stop future-proofing software

#35

Post by mlthoughts2018 »

BurningFrog wrote: post #33
dominotw wrote: post #16

Earlier quoted context omitted.

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

In this context it means that it's easy to make changes. As in add new functionality.

But you can’t make it equally easy to add in every type of functionality. For any type of extensibility design you bake in, some other types of extensibility now become harder.

So “making it flexible” hinges entirely on whether or not you can correctly forecast exactly which types of flexibility you’ll need. But this is no easier, and often harder, than predicting how end user requirements might change in the first place!

Re: Stop future-proofing software

#36

Post by markmark »

astura wrote: post #15

FWIW, maybe I'm living in a bubble but I don't seem to run across unnecessary "future proofing" very often. In fact, I see the opposite as a problem much, much more frequently. I work in a boring corporate job though, not a hip startup, so nobody at any of my jobs are trying to be the next Google or Facebook - that's probably the main difference. >We need to hire a team of developers and build in-house software, desp…

I used to see future proofing all the time in boring corporate jobs. One example I saw multiple times was complicated "generic form builders" where the dream was users would be able to add their own forms quickly and easily. Then 5 years later the whole app would be say 10 screens, but maintenance was a nightmare because under the covers everything was poorly abstracted and generic.

I also saw lots of "split it into microservices so we can scale out for load" on systems that years later still only saw minimal use.

Re: Stop future-proofing software

#37

Post by josephg »

suzzer99 wrote: post #29
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…

Yep. Some of my favourite programming advice is that the easiest code to change is code you haven’t written yet. In other words short, straightforward code is always the easiest code to adapt to new requirements.

Re: Stop future-proofing software

#38

Post by barbecue_sauce »

sandworm101 wrote: post #11

Better idea: dont pretend you are about to be the next google. Worry about that when it happens. I see too many startups burning time/money on scalability they dont need. If you have 1000 customers, and your rack can handle 20000, dont talk to me about future-proofing against the day you are building your own datacenter. Keep your code working for today's customers. Worry about scale when it happens ... IF it happens…

If you're optimizing for investment, I wonder how much of potential funding is tied to your ability to communicate that you have thought the scaling problem out. If your investors are more technical, service oriented architecture and orchestration tools (like k8s) may serve as signifiers that you have some sense of what you're doing.

Re: Stop future-proofing software

#39

Post by xae342 »

userbinator wrote: post #4

The simpler your codebase is, the easier it is to adjust to fulfill a different purpose. I think this is the most important sentence in the article. I've worked on a few extremely abstracted and horribly-indirect codebases that happened to be so very flexible and extensible in exactly all the wrong directions, so much that it made it much harder to change in the way that was actually required.

Agreed 100%, this is all that matters I’d go as far to say. It’s also is a key lesson in the disposable code shift that serverless is enabling as well.
Post reply on HN