> You usually get 30 seconds in before Steve would grab the iPod out of my boss’s hand and would just start clicking around to play with it. And of course that’s the worst thing ever because half of the stuff isn’t hooked up yet and Steve’s going to hit something and then it’s going to crash. And then Steve just decides that you’re all a bunch of idiots because your software crashes. So we hated it when that happened…
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.
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.