[cromwellian]

I think that is application specific. The same points are often made about programming, and there are certainly circumstances where you need to know how your code is compiled to assembly, or how the kernel works, for many, this isn't an issue. Sure, if you need to hit a target 30fps or 60fps in a game, then that implies what much be understood in the whole stack.

Since 99+% of all startup ideas will fail, it makes no sense to invest and optimize upfront. If your startup runs into scalability problems, you can always fix those later. You should consider the first version a throwaway. More than likely, your investments will be wasted. Even if your startup succeeds, it will often be a pivot away from the original mission.

The only case where I would say this doesn't hold is your security/privacy architecture. You don't want to fix this later after you've let your customer's data be stolen, you want this done right up front. You can rewrite everything else about your product, except for the things, which if they go wrong, will result in people being hurt materially or physically.

[dlhdesign]

> You should consider the first version a throwaway.

If you start out knowing that you are writing something that will be trashed, why would you invest yourself in it? It's hard to tell someone to build something that will be thrown away; to trade the time they can never get back for something that will most likely fail. That will almost certainly _not_ get their best work - which means your odds of success go down; perhaps drastically. And if the first version DOES happen to work, you still have to throw it away at some point and start over (or else live in pain for the life of the product). Either way; you loose.

Now think about the approach where you take the time to think through your ideas. Where you expect the best from your people right from the start because you're all building to last. When you earnestly expect the best of people, they generally give you that (or close to it, at least). You get a better result. So then the first version doesn't work. But you've learned a lot, because the thought process you went through taught you things; things you took the time to learn. Things you can leverage in your next venture; things that will speed it up, make it stronger, get it quicker. But what if it worked? Now you're not fettered with the task of rebuilding what you've just built because what you have is solid. It can be built on. So that momentum you have as the first version works can be leveraged into the second, third and fourth versions. And momentum means something; it means happier employees and - ultimately - better returns.

The former (get it quick) is (for the most part) the world of today. The latter (get it right) was the world the author remembers - and pines for.

[norseboar]

I think there are two different problems here: building a good solution, and building a solution for a problem that people have to begin with.

If you /don't know/ if there will be any customers for your product (no matter how well-built it might be), spending time and money on building a very solid v1 is a waste. Sure you will have experience that you can leverage in your next venture, but that's an extremely expensive way to get it. And if you're bootstrapping, or have hired other people, you're potentially spending the financial stability of you or your employees to get this experience.

If you /do know/ you will have customers (either because you're sure it's a problem people have, or you've got people giving you money for basic R&D without any guarantee of returns), then I completely agree with you and the author -- build the product right and it will pay dividends later on.

In the prototype-then-throw-away model, you might not get the engineers' best development work, but you will get the best brainstorming and design work, because everybody's comfortable adjusting the product until they're confident they have something that people want. If you marry yourself to it beforehand, if you commit people's livelihoods to it, people will naturally try to rationalize what they're doing because they're committing so much to it, even if it's wrong. And if you've got the smartest people working with you, they'll be incredibly good at it. This creates a much bigger problem years down the line if it fails.

[wpietri]

> If you start out knowing that you are writing something that will be trashed, why would you invest yourself in it?

This basically boils down to: why would you make a high-risk bet? The answer: Because they sometimes pay off big.

I like building things to last. But building something to last when odds of success are 50 to 1 against is foolish. If you are trying to test a startup idea, the only sensible approach is to bet the absolute smallest amount necessary to find out if the idea is worthwhile.

I've built great systems for ideas that didn't work, and it sucks. For example, in 2004 I put together a team and spent 9 months building an awesome implementation of an excellent idea that was just 5 years too early. We were all really proud of our technical work, but since we ended up with a trivial number of users, it was all, in the end, wasted effort.

Later I realized, thanks to people like Eric Ries, that the thing to do early on was to invest just enough to see if there was something to the idea. Most things won't, which means you save enough time to rebuild the few that do properly.

The "think through your ideas" thing is a false hope. You can only think so much about limited data. People can be just as happy working on something they're planning to throw away. Artists often do plenty of sketches before they do the real one, and software developers can do the same.

[jobposter1234]

It's a different perspective that believes most (tech) businesses these days are not failing because of their codebase. It's the school of thought that believes the effort invested in exceeding the Pareto principle in writing code will only have a marginal effect on likelihood of success.

Cutting corners during development may build technical debt, but for the first N iterations, it also saves time. The argument goes that it's more important to get more versions in front of your customers than to build the perfect codebase off the bat.

Also, in any startup, you're going to need to significantly adjust the codebase as your business changes products (pivots). All the effort invested up front on a feature that isn't relevant is essentially wasted.

Speed of iteration is the primary objective (to people who think this way).

[Noelkd]

The Mythical Man Month has an entire chapter why it is a good idea to "Plan to Throw One Away"[1]. But I think you know what's going on.

[1] https://archive.org/stream/mythicalmanmonth00fred#page/114/

[pavel_lishin]

You should be investing yourself into the problem being solved, not the particular snapshot of what a solution looks like right now.

[pavel_lishin]

You should be investing yourself into the problem being solved, not the particular snapshot of what a solution looks like right now.

[pavel_lishin]

You should be investing yourself into the problem being solved, not the particular snapshot of what a solution looks like right now.

[pavel_lishin]

You should be investing yourself into the problem being solved, not the particular snapshot of what a solution looks like right now.