3 ms·

If so, I think he knew the features weren’t finished, but he demanded the product not to crash nevertheless. It’s an interesting thing to expect as a product ow

If so, I think he knew the features weren’t finished, but he demanded the product not to crash nevertheless. It’s an interesting thing to expect as a product owner: A stability-first approach to development. I personally hate the “it’s temporary” excuse we developers often have.

ChrisMarshallNY 6y ago
The way I work, is that the entire project is in "Ship" quality, the entire time of development; just not yet complete. Incomplete functionality means a blank screen or a button that doesn't do anything. It never means that something crashes. My goal is zero crashes, ever; at any time during development. The same with memory leaks or severely anomalous behavior. It's an old-fashioned way of working that results in basically zero tech debt. I'm allergic to debt, of any kind. The nice thing about working this way, is you get incredibly well-formed UX, and you don't have that awful "QA surprise," at the end of the project. It also goes a lot faster than you might think, as bugs get fixed close to the time of their creation.
- capableweb 6y ago
  Sounds like you have bunch of stuff conflated here. Zero crashes don't mean you get a well-formed UX and that there are no QA surprises. No crashes ever during any time doesn't neither mean that there is zero technical debt, unless we have vastly different understanding of what technical debt even means...
  - ChrisMarshallNY 6y ago
    I'm sure you're right, but my way has been working for me. I think I'll just keep doing it.
- anchpop 6y ago
  You could write in Elm, which has no runtime exceptions and thus no crashes (barring stack overflows and similar). I have and it didn't seem to result in zero tech debt, incredibly well-formed UX, or a shortage of QA surprises.