Hacker News Reader

Comment by em3rgent0rdr | Hacker News Reader

> 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.

Smart idea...do a bunch of random input as if you were a confused user and see what happens.

View on HN

I don’t think it’s either of those. Steve cared first and foremost about the user experience and the only way to understand that is to use the device.

As for perfectionism I think that’s overblown. I’ve read or listened to many people who worked with him and yes he was demanding but almost all oft gem had huge respect for him personally and professionally.

The thing is Jobs hired the absolute best engineers he could get, and worked with the best for his whole career. That was just the standard he was used to and expected.

That is indeed a fine test to perform and I’d hope that random clicking was already part of the testing. But I think the issue is that he was testing functionality that wasn’t yet (fully?) implemented and when it inevitably crashed he berated the team. Don’t personally wanna relitigate the “was Jobs a bad boss” thing as I feel like that’s been done to death, but feel free to pull that thread and consider why Jobs might have behaved this way.

I dunno, I feel like unfinished functionality should probably be feature flagged in your demo releases, or you're just asking for problems like this.

If it was literally a nightly or something though then that's different and definitely an asshole move.

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.

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.

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...

I'm sure you're right, but my way has been working for me. I think I'll just keep doing it.

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.

Sounds a lot like Chaos Monkey

https://en.wikipedia.org/wiki/Chaos_engineering

Reply on news.ycombinator.com