3 ms·

There's a way out of this, but it requires discipline and besides, most companies don't want to do it. Prototype. Deliberately build "one to throw away." Iter

There's a way out of this, but it requires discipline and besides, most companies don't want to do it. Prototype. Deliberately build "one to throw away." Iterate fast and figure out what you need. When you've learned the important lessons about architecture, structure and collaborations, make a note of those lessons in a design document and then build the "real" product with proper engineering, but with a lot less risk. I worked for an organization that did this and it results in good quality software, but you need buy-in at all levels of management or you run into "why did your team just waste 6 months on throw-away work?" questions.

anthonypasq 4y ago
arent you just describing the business from #1 that does this method and fails because they have no money and no customers?
- n42 4y ago
  It’s important to time this well and start doing it as soon as you have your feet on the ground, and the hard part is to hit the ground running. Too early and you crash, too late and you grind to a halt edit: missed “6 months”, I live in another world — a week to prototype and throw it out. spending 6 months to prototype anything and you’re biting too big
  - HeyLaughingBoy 4y ago
    > spending 6 months to prototype anything I come from the world of medical devices. Nothing happens in a week ;-)
    - deleted 4y ago
      [deleted]
    - ska 4y ago
      Most of the medical device industry could move a lot faster than they do. There are an interesting collection of reasons why they don't, but it's not inherent.
- ska 4y ago
  It really doesn't have to be. If you come from a hardware background, you get used to the idea of quickly prototyping with techniques (e.g. breadboard electronics) and materials (e.g. 3D prints in plastic instead of CNC milled parts) because it is vastly faster and cheaper. See also scale models etc. The problem with software is it nearly infinitely malleable, so the tempation is always there to think that you will be faster if you ship-of-Theseus your current prototype into production code. It works sometimes, but often it's faster to actually prototype, then do it "right" from what you've learned. It's a skill though, to know what to concentrate on and what to skip/fake/ignore.

anthonypasq 4y ago

arent you just describing the business from #1 that does this method and fails because they have no money and no customers?

n42 4y ago
It’s important to time this well and start doing it as soon as you have your feet on the ground, and the hard part is to hit the ground running. Too early and you crash, too late and you grind to a halt edit: missed “6 months”, I live in another world — a week to prototype and throw it out. spending 6 months to prototype anything and you’re biting too big
- HeyLaughingBoy 4y ago
  > spending 6 months to prototype anything I come from the world of medical devices. Nothing happens in a week ;-)
  - deleted 4y ago
    [deleted]
  - ska 4y ago
    Most of the medical device industry could move a lot faster than they do. There are an interesting collection of reasons why they don't, but it's not inherent.
ska 4y ago
It really doesn't have to be. If you come from a hardware background, you get used to the idea of quickly prototyping with techniques (e.g. breadboard electronics) and materials (e.g. 3D prints in plastic instead of CNC milled parts) because it is vastly faster and cheaper. See also scale models etc. The problem with software is it nearly infinitely malleable, so the tempation is always there to think that you will be faster if you ship-of-Theseus your current prototype into production code. It works sometimes, but often it's faster to actually prototype, then do it "right" from what you've learned. It's a skill though, to know what to concentrate on and what to skip/fake/ignore.