3 ms·
The challenge is the mindset in most software shops of "We're not building a space ship". Because of the ability to rapidly iterate, there's a sense of invincib
by lemonwaterlime 2y ago
The challenge is the mindset in most software shops of "We're not building a space ship". Because of the ability to rapidly iterate, there's a sense of invincibility. As we've seen, however, some aspects of the product should in fact be treated like building a space ship. For instance, with something like properly managing data (so you don't get breached), a detailed risk assessment and robust strategy should be more highly prioritized. For displaying a UI to end users, perhaps not so much, but even then there are accessibility concerns that a good product would address.
- ethbr1 2y agoSafety/security risk is important too, but I was suggesting development keep an eye on delivery risk. I.e. the risk that a project won't be delivered with the expected features and by the expected end date Fundamentally, time estimates are useless without a coupled risk/certainty metric. If you ask me how long something is going to take, and I believe it'll take somewhere between 3 months (worst case) and 2 weeks (best case), what number do I reply to you with? And how do you interpret that number? And how does my reporting change as we get closer to delivery? Reducing the size of work being estimated band-aids the problem, by shrinking the absolute magnitude of the bounds, but doesn't fundamentally solve it. Common heuristics like "double how long you think it's going to take" are other ways this appears.
- lemonwaterlime 2y agoI think we’re in agreement. In my mind, you can even get delivery risk from a safety/security standpoint. As in, the product should be developed on time while accounting for the security/safety stuff. And you get there by placing risk front and center for the entire system from the beginning.