Why can't you have both? Maybe a different design would become apparent while developing the product, as opposed to being discovered in the analysis phase. (I'm assuming you are talking about a process with a large and separate analysis phase).
The worst case is millions of dollars spent to build a product only to discover that there are issues late in the testing phase. Wouldn't is be less risky to experiment and validate assumptions earlier in the cycle?
Agile as opposed to methodology X is a bit fuzzy here, as I'm sure testing is extensive and expensive and the feedback cycle is inherently longer, so change is more expensive.
However, it seems that early feedback and validation of design is even more important in these circumstances, since changes late in the product development process and orders of magnitude more expensive than changes early in the process.
Yeah, I'm not talking about process so much as languages anyway though. For all I know (I've never actually developed software for a medical device) its worthwhile to build an actual prototype in a more flexible language first. But if my code could kill someone, I want my tools to optimize correctness over flexibility in the final implementation.
Yes, because agile methodologies kill people, puppies and hate freedom.
Seriously though, in situations where lives are dependent on the solution working correctly, the process that is used to build the solution needs to take into account human error and have rigorous testing.
i.e. I also wouldn't trust a person who "though about and can 'prove'" a solution in Haskell to control that radiation machine without extensive testing.
Actually, agile methodologies are good for situations where the problem itself (and even customer base) is in flux and not fully known (ie consumer facing web startups). Agile methodologies help lay a roadmap to facilitate communication and prioritization to/from developer, project management, and the customer(s).
The solution may or may not be difficult, but finding the right problem to solve is paramount.
The quality of the solution is often a product of the quality of the people working on the problem. Oh, and don't run out of money :-)
My experience is there's a tendency to ship the first viable thing that comes out and deal with the rest on an as-needed basis. This is fine for stuff that can survive being a bit ramshackle at first if you can refactor it later, but some things are highly resistant to later refactoring.
Shipping quickly is often a strategy used to discover the problem space. Some things should be done as quickly as possible and some things should not. The developers/tech management are responsible for forseeing such cases.
Hopefully the initial developers are good ones. If not, I'm sorry and I hope they pay you well. I've been there :-|
> UPDATE: My wife the attorney acidly points out yet another way in which Sonmez’s argument is flawed and unhelpful. “If surgeons had the failure rate of software engineers,” she observes, “they’d all be in jail.”
