Stop future-proofing software • Hacker News Board

Re: Stop future-proofing software

#11

Post by sandworm101 » Sun, Sep 02, 2018, 7:20 PM UTC

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.

Imho, limit your perspective and planning to double your current customer base (good day senario) and half (bad day senario). Any day beyond those bounds will require a rethink. A rethink THEN, not today.

Re: Stop future-proofing software

#12

Post by fsloth » Sun, Sep 02, 2018, 7:26 PM UTC

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…

"As soon as you know what your business is going to be, make sure your technology stack is flexible."

As a form of devil's advocacy - Why? Just improving the codebase under the hood won't bring any new users in the initial market segment where your product-market fit is proven. Focusing on marketing, will...

Re: Stop future-proofing software

#13

Post by ChuckMcM » Sun, Sep 02, 2018, 7:27 PM UTC

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 engineering you can teach yourself to recognize the things you did in the past that made what you are doing today easy or even possible.

That is not to say that all future proofing is good, especially if it ties up the group in knots trying to predict all possible futures. That is where the mantra of keeping it simple really helps. Simplicity is the greatest protection against the future precisely because it has the smallest disruption surface. The simpler a process or product is, the more difficult it is to find a change that would invalidate its effectiveness.

Re: Stop future-proofing software

#14

Post by suzzer99 » Sun, Sep 02, 2018, 7:28 PM UTC

My mantra is - never assume features, but always assume change.

As others have mentioned - it's orders of magnitude easier to add a layer of abstraction to a simple system as requirements evolve, than it is to remove an unneeded one down the line. The latter is often impossible.

Re: Stop future-proofing software

#15

Post by astura » Sun, Sep 02, 2018, 7:29 PM UTC

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, despite wordpress and shopify being a much easier alternative, because when our customer base grows to 100 times what it is now, it will make our lives easier.

I think this comes from "not invented here syndrome" rather than the assumption you'll need to support hundreds of orders a minute in the future. Also job security.

Re: Stop future-proofing software

#16

Post by dominotw » Sun, Sep 02, 2018, 7:34 PM UTC

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?

Re: Stop future-proofing software

#17

Post by javajosh » Sun, Sep 02, 2018, 7:38 PM UTC

"A company that can eat one marshmallow now should never wait to get two marshmallows." This is simply false.

Re: Stop future-proofing software

#18

Post by sz4kerto » Sun, Sep 02, 2018, 7:44 PM UTC

fsloth wrote: post #12

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…

"As soon as you know what your business is going to be, make sure your technology stack is flexible." As a form of devil's advocacy - Why? Just improving the codebase under the hood won't bring any new users in the initial market segment where your product-market fit is proven. Focusing on marketing, will...

Growth comes with technical issues. As a rule of thumb, 2 orders of magnitude increase in traffic requires significant refactoring or change in architecture. 1 orders of magnitude in team size requires new forms of management. Etc.

Re: Stop future-proofing software

#19

Post by arnon » Sun, Sep 02, 2018, 8:10 PM UTC

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.

Re: Stop future-proofing software

#20

Post by jarfil » Sun, Sep 02, 2018, 8:15 PM UTC

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…

Depending on your target audience, if your product becomes viral you may need to be able to scale to 100x in a very short time. That's too late to rethink stuff.

Of course this depends on whether your product CAN become viral in the first place, but I think many people are just hoping it will, even if it never does and it looks like just a waste of time.