6 ms·

I think they were right to tell you to leave them alone, but a better answer would be: "we'll add them to our backlog (or whatever way you manage issues or work

I think they were right to tell you to leave them alone, but a better answer would be: "we'll add them to our backlog (or whatever way you manage issues or work), and get to them by X iteration". As long as you were really working on an MVP and not a version 1.x .

jacquesm 11y ago
The problem is those things end up being forgotten or interfaced to in so many places that in the end they become un-fixable or won't be fixed to keep other stuff running. You need to do it right from day #1.
- GFischer 11y ago
  I was thinking more of a throwaway prototype, but the answers on other threads convinced me it wasn't good advice, and I don't know what stage the OP's startup is.
Jtsummers 11y ago
That's technical debt, and it's hard to fix. A prototype, sure, it can have flaws, it's a proof of concept of feature X, not feature X SECURED. But then the release has to be a rewrite. If it's not, those flaws are more likely to become permanent. And when they do begin work on repairing their codebase, they'll spend several times the money and time to fix than if they'd spent some time early on. They'll also likely introduce numerous other issues in the process.
- GFischer 11y ago
  Ok, I'll clarify: I think they were right as long as it was a throwaway prototype. And the GET delete operations are probably a bad idea even for a prototype. I was thinking of a rewrite for release 1.x. I don't have enough knowledge of the stage the OP's startup was to have answered, so I stand corrected.
  - vonmoltke 11y ago
    In my experience, "throwaway" prototypes almost never are.
  - Kristine1975 11y ago
    I'm scared that when the prototype is done someone says "looks good, ship it!"
    - wpietri 11y ago
      That's a totally legitimate fear. These days, this is the kind of thing I negotiate up front. When they ask me how long something will take, I explain that they can have a prototype quickly, but only if they promise to throw it away as soon as the experiment is done. I explain that they can have me build a movie set or a real house, but that there's nothing in between. [1] And then I leave the choice up to them, explaining that it's really about their business judgement. Generally people keep their promises on this, although sometimes it takes a little reminding. When they do, the business benefits are substantial. A good product person really benefits from doing quick, cheap experiments. And they also benefit from having a solid platform of high-reliability code for production use. But they can only get the benefits of both if they're careful not to mix the two. [1] There is actually something between, but they don't want it: http://agilefocus.com/2009/06/22/the-3-kinds-of-code/ http://agilefocus.com/2009/06/22/the-3-kinds-of-code/
    - mikestew 11y ago
      I'm old and have been in this industry a long time, and I'm genuinely surprised on those oh-so-rare occasions when what you describe doesn't happen. Prototypes-become-products is a trope much like _The Mythical Man Month_. We all nod knowingly when it is mentioned, we all know how it will turn out, and then we (well, management dictates that we...) turn right around and do the opposite.

jacquesm 11y ago

The problem is those things end up being forgotten or interfaced to in so many places that in the end they become un-fixable or won't be fixed to keep other stuff running. You need to do it right from day #1.

GFischer 11y ago
I was thinking more of a throwaway prototype, but the answers on other threads convinced me it wasn't good advice, and I don't know what stage the OP's startup is.

Jtsummers 11y ago

That's technical debt, and it's hard to fix. A prototype, sure, it can have flaws, it's a proof of concept of feature X, not feature X SECURED. But then the release has to be a rewrite. If it's not, those flaws are more likely to become permanent. And when they do begin work on repairing their codebase, they'll spend several times the money and time to fix than if they'd spent some time early on. They'll also likely introduce numerous other issues in the process.

GFischer 11y ago
Ok, I'll clarify: I think they were right as long as it was a throwaway prototype. And the GET delete operations are probably a bad idea even for a prototype. I was thinking of a rewrite for release 1.x. I don't have enough knowledge of the stage the OP's startup was to have answered, so I stand corrected.
- vonmoltke 11y ago
  In my experience, "throwaway" prototypes almost never are.
- Kristine1975 11y ago
  I'm scared that when the prototype is done someone says "looks good, ship it!"
  - wpietri 11y ago
    That's a totally legitimate fear. These days, this is the kind of thing I negotiate up front. When they ask me how long something will take, I explain that they can have a prototype quickly, but only if they promise to throw it away as soon as the experiment is done. I explain that they can have me build a movie set or a real house, but that there's nothing in between. [1] And then I leave the choice up to them, explaining that it's really about their business judgement. Generally people keep their promises on this, although sometimes it takes a little reminding. When they do, the business benefits are substantial. A good product person really benefits from doing quick, cheap experiments. And they also benefit from having a solid platform of high-reliability code for production use. But they can only get the benefits of both if they're careful not to mix the two. [1] There is actually something between, but they don't want it: http://agilefocus.com/2009/06/22/the-3-kinds-of-code/ http://agilefocus.com/2009/06/22/the-3-kinds-of-code/
  - mikestew 11y ago
    I'm old and have been in this industry a long time, and I'm genuinely surprised on those oh-so-rare occasions when what you describe doesn't happen. Prototypes-become-products is a trope much like _The Mythical Man Month_. We all nod knowingly when it is mentioned, we all know how it will turn out, and then we (well, management dictates that we...) turn right around and do the opposite.