3 ms·

It's a bit easier to be blasé about testing when your worst-case-scenario is that somebody misses a ride, vs when you kill ~150 people. The rapid cycle of innov

It's a bit easier to be blasé about testing when your worst-case-scenario is that somebody misses a ride, vs when you kill ~150 people. The rapid cycle of innovation is a tradeoff that SV is able to make (and finds amazingly beneficial) because we're working with soft tools and have backups of our data. I'm certain that were human life so cheap, Pratt and Whitney would have a much shorter dev cycle, too.

kelvin0 11y ago
Curiously, I read that comment as saying: Silicon Valley is too preoccupied with short term profits to be able to concentrate for a long time and come up with such 'tangible' and actual benefits in the domain of transportation. This is not the next 'snapchat/tumblr/facebook' ... That's how I interpreted his comment at least.
onion2k 11y ago
Shorter project sprints came about to try to fix the problem of project failure. Failure to create a loop that feeds discoveries in to a project's knowledge, and to communicate knowledge between teams is exactly what makes projects come to catastrophic ends, and that's what the shorter cycle time attempts to correct. The fact the product benefits from faster innovation is a function of more efficiently sharing knowledge and data, not spending less time on individual components. Designing and testing an engine can be done in an agile style. There's nothing intrinsically "software only" about the methodology. NB: I ran a startup that made software to manage requirements in big projects. I've spent lots of time thinking about different ways to manage things. Including how not to, but that was after we failed.
- ams6110 11y ago
  Yes it is intrinsically software-only. When a software test fails you fix the bug and run it again. When a jet engine test fails you just blew up a $10M prototype.
  - onion2k 11y ago
    A software test is equivalent to a testing small part in an engine design. The cost of failure is low. The cost of a full production test in an engine design is clear, but it's the equivalent of a product handover and acceptance testing in software. The cost of failing that test could well run to millions of dollars. The only difference for a SaaS startup is that they're their own customer for product development (in the sense that they build and test in-house rather than someone else paying them to build a product). The cost of failure is still there, it's not measured.
HeyLaughingBoy 11y ago
It's also a very different mindset. I moved from a long career designing software for Medical Devices to desktop S/W and the hardest part for me is getting used to a much more relaxed approach to development process, documentation and testing. It's weird when I realize I can just push something out the door and not have to wait for the reams of paperwork to be complete.
pbowyer 11y ago
> I'm certain that were human life so cheap, Pratt and Whitney would have a much shorter dev cycle, too. I read a book recently about the history of Supermarine, and what jumped out was the attrition rate of their test pilots. Ditto for the post-war British jet industry. There is a trade-off point between safety and fast development, but I'm glad we've moved to the side of safety.

kelvin0 11y ago

Curiously, I read that comment as saying: Silicon Valley is too preoccupied with short term profits to be able to concentrate for a long time and come up with such 'tangible' and actual benefits in the domain of transportation. This is not the next 'snapchat/tumblr/facebook' ... That's how I interpreted his comment at least.

onion2k 11y ago

Shorter project sprints came about to try to fix the problem of project failure. Failure to create a loop that feeds discoveries in to a project's knowledge, and to communicate knowledge between teams is exactly what makes projects come to catastrophic ends, and that's what the shorter cycle time attempts to correct. The fact the product benefits from faster innovation is a function of more efficiently sharing knowledge and data, not spending less time on individual components. Designing and testing an engine can be done in an agile style. There's nothing intrinsically "software only" about the methodology. NB: I ran a startup that made software to manage requirements in big projects. I've spent lots of time thinking about different ways to manage things. Including how not to, but that was after we failed.

ams6110 11y ago
Yes it is intrinsically software-only. When a software test fails you fix the bug and run it again. When a jet engine test fails you just blew up a $10M prototype.
- onion2k 11y ago
  A software test is equivalent to a testing small part in an engine design. The cost of failure is low. The cost of a full production test in an engine design is clear, but it's the equivalent of a product handover and acceptance testing in software. The cost of failing that test could well run to millions of dollars. The only difference for a SaaS startup is that they're their own customer for product development (in the sense that they build and test in-house rather than someone else paying them to build a product). The cost of failure is still there, it's not measured.

HeyLaughingBoy 11y ago

It's also a very different mindset. I moved from a long career designing software for Medical Devices to desktop S/W and the hardest part for me is getting used to a much more relaxed approach to development process, documentation and testing. It's weird when I realize I can just push something out the door and not have to wait for the reams of paperwork to be complete.

pbowyer 11y ago

> I'm certain that were human life so cheap, Pratt and Whitney would have a much shorter dev cycle, too. I read a book recently about the history of Supermarine, and what jumped out was the attrition rate of their test pilots. Ditto for the post-war British jet industry. There is a trade-off point between safety and fast development, but I'm glad we've moved to the side of safety.