4 ms·

The problem with the Planned Design vs Extreme Evolutionary Design is that BOTH are appropriate for different circumstances. I've found a balance that works we

by toss1 3y ago

The problem with the Planned Design vs Extreme Evolutionary Design is that BOTH are appropriate for different circumstances. I've found a balance that works well, almost by accident or necessity of the situation. At the outset with a new product, even if the team thinks they know what they are doing and what they intend, they really do not. This is (had better be) a new product/service, and no one really knows how it will really interact with the customers/users, and how the components will interact. You are about to build a MVP, then core product. THIS is the time for an extreme programming type approach. Get things working ASAP, get feedback from real users and real running systems. Most importantly, the ONLY PLAN is to THROW AWAY THIS VERSION. Then, once you have basic experience with your users, know what they prioritize, and experience with your system's behavior, NOW is the time to plan and design a system that will be scalable and maintainable. Depending on the project, situation, and how the throw-away version went, this may be after v0.9 or after v2.1, or maybe just after base or breakeven revenue or a funding round. The cool thing is that in the early times when speed is most critical to survival, all worries about technical debt are eliminated — it'll just be thrown away soon, and the scalability and maintainability issues are punted until you really have enough information to answer them well. So, extreme to start, then plan and design later.

mark_undoio 3y ago
It takes some strong organisational discipline to really maintain that throw away mindset - I suppose that's where it helps to make an explicit goal to throw the initial version away. Another aspect is that (in my experience / opinion) if you're doing an MVP then it really needs to be as minimal as possible - big enough to give you evidence for your future plans but not comparable to what you eventually hope to build. Otherwise it's hard to adapt or to throw away. The biggest thing I've found to help in any design work is making sure the engineers really understand the problem they're solving, so they can judge independently if plans they're making are complimentary to it.
- perrygeo 3y ago
  > making sure the engineers really understand the problem they're solving Yes, absolutely. And how would software engineers gain that understanding? Experience is the key here. Avoiding an initial implementation because you're afraid of "wasting work" is counterproductive - it cuts off the primary mechanism by which developers gain understanding! That's like saying athletes shouldn't practice because it wastes their energy for the big game. One small note on terminology that might help: Using "MVP" implies that what you're developing is a product. It's more accurate to call this "POC" or proof-of-concept since that's exactly what it does - with that data in place, the product and engineering plans can proceed faster and more effectively knowing they have a firm tether to reality.
germinalphrase 3y ago
I have never had the experience of developing a product from MVP to mass market. Is ‘Throw Away then Strategize/Plan’ utilized with any regularity? Would it follow that the initial team who scraps together the MVP would be different than the Strategize/Plan team that might be hired specifically because they have the experience/background for building large scale systems (assuming expanded funding comes from market validation via the MVP)?
- perrygeo 3y ago
  > Is ‘Throw Away then Strategize/Plan’ utilized with any regularity Yes. But I'd frame it a different way. The initial implementation is the source of empirical data that you need to formulate a viable plan. You're not building something to "throw it away". You're building something so that all subsequent decisions can be made on a solid foundation. To be concrete, I've seen teams faced with a technical decision who a) argue about it in meetings for weeks, bringing only opinions and personal experiences to the table vs. b) set up a proof of concept for all options and run benchmarks which can be used to make informed decisions. (a) takes longer and produces an inferior product - I've never seen an exception.
  - toss1 3y ago
    >> argue about it in meetings for weeks, bringing only opinions YUP: One test is worth a thousand opinions. (and yes, the entire point of the throw-away version is to test every aspect of the MVP++. And sure, you may keep some chunks of it, but that is sort of based on luck. A big part of the attitude on the initial version is that no one needs to think about technical debt here - it's all a big experiment, done to generate information and data to build a solid foundation.)
lessaligned 3y ago
I arrived at the same wisdom eg. the "Throw Away then Strategize/Plan" process, but... how the heck to you manage to sell/explain this to people at the same or higher levels? Imo lots of people are very disgusted by this, mainly because the (a) concervatives/waterfall-heads are horrified by the idea of launching something no thoroughly engineered, while the (b) evolutionary-design folks never want a clean-rewrite from scratch, they'll cling to that "throw-away version" and try to "evolutionarily" refactor it gradually into what they now know it will be needed (and this always fails).
- toss1 3y ago
  Good point - to some degree I got lucky in the organizational area; the situation where it really proved itself was where I was one of four co-founders & I was in the CTO chair. I can see how it could degrade in the ways you mentioned (and more!) in more mature orgs. Which, to me makes it an even better idea there, but harder to politically navigate.

by toss1 3y ago

mark_undoio 3y ago

It takes some strong organisational discipline to really maintain that throw away mindset - I suppose that's where it helps to make an explicit goal to throw the initial version away. Another aspect is that (in my experience / opinion) if you're doing an MVP then it really needs to be as minimal as possible - big enough to give you evidence for your future plans but not comparable to what you eventually hope to build. Otherwise it's hard to adapt or to throw away. The biggest thing I've found to help in any design work is making sure the engineers really understand the problem they're solving, so they can judge independently if plans they're making are complimentary to it.

perrygeo 3y ago
> making sure the engineers really understand the problem they're solving Yes, absolutely. And how would software engineers gain that understanding? Experience is the key here. Avoiding an initial implementation because you're afraid of "wasting work" is counterproductive - it cuts off the primary mechanism by which developers gain understanding! That's like saying athletes shouldn't practice because it wastes their energy for the big game. One small note on terminology that might help: Using "MVP" implies that what you're developing is a product. It's more accurate to call this "POC" or proof-of-concept since that's exactly what it does - with that data in place, the product and engineering plans can proceed faster and more effectively knowing they have a firm tether to reality.

germinalphrase 3y ago

I have never had the experience of developing a product from MVP to mass market. Is ‘Throw Away then Strategize/Plan’ utilized with any regularity? Would it follow that the initial team who scraps together the MVP would be different than the Strategize/Plan team that might be hired specifically because they have the experience/background for building large scale systems (assuming expanded funding comes from market validation via the MVP)?

perrygeo 3y ago
> Is ‘Throw Away then Strategize/Plan’ utilized with any regularity Yes. But I'd frame it a different way. The initial implementation is the source of empirical data that you need to formulate a viable plan. You're not building something to "throw it away". You're building something so that all subsequent decisions can be made on a solid foundation. To be concrete, I've seen teams faced with a technical decision who a) argue about it in meetings for weeks, bringing only opinions and personal experiences to the table vs. b) set up a proof of concept for all options and run benchmarks which can be used to make informed decisions. (a) takes longer and produces an inferior product - I've never seen an exception.
- toss1 3y ago
  >> argue about it in meetings for weeks, bringing only opinions YUP: One test is worth a thousand opinions. (and yes, the entire point of the throw-away version is to test every aspect of the MVP++. And sure, you may keep some chunks of it, but that is sort of based on luck. A big part of the attitude on the initial version is that no one needs to think about technical debt here - it's all a big experiment, done to generate information and data to build a solid foundation.)

lessaligned 3y ago

I arrived at the same wisdom eg. the "Throw Away then Strategize/Plan" process, but... how the heck to you manage to sell/explain this to people at the same or higher levels? Imo lots of people are very disgusted by this, mainly because the (a) concervatives/waterfall-heads are horrified by the idea of launching something no thoroughly engineered, while the (b) evolutionary-design folks never want a clean-rewrite from scratch, they'll cling to that "throw-away version" and try to "evolutionarily" refactor it gradually into what they now know it will be needed (and this always fails).

toss1 3y ago
Good point - to some degree I got lucky in the organizational area; the situation where it really proved itself was where I was one of four co-founders & I was in the CTO chair. I can see how it could degrade in the ways you mentioned (and more!) in more mature orgs. Which, to me makes it an even better idea there, but harder to politically navigate.