[jacquesm]

I don't think that is his main point. I think it is far more about the fact that just the surface layers aren't enough to build good solutions to problems, that's good enough for demos and mock-ups but not good enough for production. For that you need some deeper level of insight.

[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.

[7Figures2Commas]

Look at some of Facebook's early code:

https://gist.github.com/philfreo/7257723

https://gist.github.com/nikcub/3833406

There are plenty of people in this industry who would have told you this code wasn't fit for production.

People frequently overestimate both what's needed to build commercially-viable solutions and how easy it becomes to recruit the right people to improve (or reimplement) poorly-architected solutions if they become popular.

[jacquesm]

Good enough, ship it!

[rjberry]

Premature optimisation ...

Getting a good idea is usually harder than getting the tech right. Being able to quickly make prototypes is the most important thing in a start up.

FYI I'm not a "brogrammer". I work at a large established company and one of my main jobs is making systems work at large scale. But that's not what you do when starting a company. If you make it you can sort out those issues later.

[jacquesm]

If you lay things out well that it has a much better chance of succeeding than if you lay things out poorly. And knowledge helps with that.

If you optimize more than you need to then that is premature optimization. But if it takes 5 seconds to load a page (or more) then any level of success will kill you and that's bad for business. You need to scale just ahead of the needs of your users. Too much and you're going down the premature optimization rabbit hole, too little and you'll end up with angry users and competitors will likely eat you.

[solarmist]

I think it's a bit of both (more of the first though), but the second one is only a temporary problem. Given another 10 years (I say 10, but I wouldn't be surprised if it's less than 5) of development the surface layers will be enough to build all except the amazon's or apple's of the world.