3 ms·
Aka “Ready, fire, aim” from the Pragmatic Programmer. This approach is fine but make sure your iterative prototyping is refining some sort of e2e / acceptance
by theptip 2y ago
Aka “Ready, fire, aim” from the Pragmatic Programmer.
This approach is fine but make sure your iterative prototyping is refining some sort of e2e / acceptance test, with good comments / README describing the intent.
It’s really easy for the prototype to end up being shipped and painful refactoring happening once you’re successful.
For me, a lot of the time this ends up being a question of what is known vs unknown. If you have a clear customer requirement but technical uncertainty then iterating on prototypes is usually better. If you have unclear customer requirement then shipping MVPs iteratively is usually better. If you have organizational uncertainty (eg you need to compose components from multiple teams and align roadmaps, as is common in big companies) then the design doc is often the place to start.
- softwaredoug 2y agoI totally agree. The prototype being shipped is the #1 risk. And why even though I prefer this approach, it may be impractical if organizations can’t be disciplined.
- kmoser 2y agoIf you have time to rewrite the prototype twice, you also have time to write and maintain the documentation which would have made it unnecessary to rewrite the prototype twice. Not saying iterating the code is always bad, but it shouldn't be a substitute for sufficient up-front planning that would have saved programmer time. And yes, the prototype usually ships. There is often not enough time to completely rewrite it, let alone fix all the bugs and add all the necessary features.