- top-down approach: you state your problem, think it through, consider all related work in this problem space, think very hard, come up with multiple possible solutions, evaluate their trade-offs and implement the best one (a-la Hammock-Driven Design: https://www.youtube.com/watch?v=f84n5oFoZBc&t=1816s)
- rapid prototyping: you state your problem, come up with the easiest possible solution, test it, repeat (a-la Lean Development: https://en.wikipedia.org/wiki/Lean_software_development)
I know some great examples of the first approach (Clojure, Datomic, maybe Git?), but I don't know that many successes of the second approach. Furthermore, my personal work experience leads me to believe that the second approach, at least in practice, leads to a lot of wasted effort, so I'm interested to know whether it is so or not.
Rewriting code is good in my experience. It's always better the second time around (or third, or fourth). It's not that my first attempt was rubbish, it's that I didn't understand the problem as well as I did the second time (and so on).
Lean is also about avoiding premature optimisation. Which is hard because it cuts against the grain of our engineer sensibilities. Doing something "good enough for now" is tough, when you know that with just a few more days' effort you could make it bulletproof. But I've had to delete "bulletproof" code so many times, because it turns out the product didn't need that feature, or it needed to work differently.
In the long term, Lean avoids more wasted effort, in my experience.
Rapid prototyping is more optimal for any end-user product or any new domain, because it’s a faster way to discover the unknown unknowns, both in terms of user features as well as well as technical challenges you may not have anticipated.
Linus built the working prototype/self-hosted in 3 days mixing a lot of his learnings from bit-keeper and his knowledge of disk management [1].
To me, that's rapid prototyping. It's enough domain knowledge to make it work for himself well. He didn't spend a bunch of time thinking nor coming up with solution since he was actively building Linux at the time. The key is he employed the help of others to build Git and eventually take it over since he wanted to focus on Linux.
This all comes with a huge caveat in that Linus's 3 days == 1000 of mine. His 'just enough' knowledge is near expert level.
As others have asked, what are you trying to build? A technical solution or an end-user solution.
Technical solutions do require a lot more domain knowledge than a twitter/airbnb (at the early stages).
In the end, I believe in rapid prototyping and failing fast[2]. Learn just enough, whether technical or end-consumer to launch fast.
The thing I agree 100% is though, don't break user-space [3]. I believe this applies to end users of products, whether developers or customers. Once people start consuming something, don't break it. Doesn't matter whether you believe it to be 'correct' or a 'bug'. Expectation management of slow and easy depreciation.
[1] https://en.wikipedia.org/wiki/Git#History [2] http://paulgraham.com/startupmistakes.html [3] https://lkml.org/lkml/2012/12/23/75
One is using a top-down approach versus an iterative approach. The other is about the nature of your problem: do you have product risk or market risk?
The lean approach is about eliminating waste, which, in the context of startups, often means building something small and talking to users. But that's only because most startups have market risk. If you have product risk, you should still iterate on your solution instead of building it in one go.
I feel like you are asking for examples where the market-risk was addressed. The most interesting companies would be those where the first test was a total miss and they solved a totally different problem in the end.
Git definitely doesn't fit the first approach. Not sure why you would state that.
Maybe the core of Clojure, with the persistent data structures, fits the first approach, but I doubt the rest of it does (speaking as an outsider to th eproject).
"Implement the best one" belies a lot of sweat and places where it could have gone wrong. In other words, the initial thinking is not even addressing half of the problem or doing half the work.
The philosophy of Clojure itself is very much based on iteration and interactive programming. You need a lot of action, feedback, and iteratino in addition to the "think very hard" part.
* Twitch, started as one guy streaming his life then they realised lots of gamers were watching, and that they'd like to be able to stream https://www.youtube.com/watch?v=FBOLk9s9Ci4
* Segment, started as a thumbs up/down tool for professors in lectures to work out when students are getting confused. They realised everyone just went to Facebook instead, then they wondered why they couldn't tell this when they were remote! https://www.youtube.com/watch?v=l-vfn97QTr0
If you don't know your problem there is nothing to prototype, no minimal viable product. Nothing.
If you spend years analysing and planning you get nowhere.
You need to have an idea, a problem which has to be solved, but should not be lost in the forest.
At a tactical level, feature level, you mix both. You state your problem (or get it stated to you), you think it through, hopefully considering at least some related work and doing some hard thinking, come up with multiple possible solutions and evaluate their trade-offs... by implementing their prototypes as fast as possible, because that's the only real way to discover the trade-offs. Depending on how much in a hurry you are, you might pick the first prototype that isn't a total disaster and build your feature from it, then test it, and repeat.
See how "top-down" and "rapid prototyping" is interwoven here. This approach can be expressed as: think before you do, but remember that you only learn the true scope of a problem by attempting to solve it.
I think it's on it's third rewrite or something right now, and runs circles around the only other service in this space regarding bang for the bucks (guess my budget, its smaller than that).
A lot of times it’s useful building products by rapidly iterating because you see flaws, holes in your thinking, and get feedback immediately from people who are going to use it.
Immediate (or shorter term) feedback can be very helpful.
But to answer your question, YC talks a lot about Twitch being an example of the second approach.