On 16 Apr 2008, at 14:42, Phillip Gawlowski wrote:
> I doubt, however, that there is a single undefined state in the Space
> Shuttle's software. No uncaught exception, no reliance on language
> features to do the right things, but well understood and diligent
> implementation of those, together with rigorous QA.

It's a lovely idea, but ponder the impact of G=F6del's Incompleteness =20=

Theorems or Turing's proof of the Halting Problem. In practice there =20
are program states which can occur which cannot be identified in =20
advance because they are dependent on interactions with the =20
environment, or are artefacts of the underlying problem space.

That's why run-time error handling and fail-safe behaviour are so =20
important regardless of the rigour of Q&A processes.

> As I said in another reply in this thread, methodologies are but one
> skill set. What works for a billing system doesn't necessarily work =20=

> for
> a cruise missile or the A380. Different problem domains require
> different solutions.
>
> And Agile's domain is in the face of changing or evolving =20
> requirements.
>
> I suspect that aeronautical problems are well understood, and
> requirements (while not easily) determined well before the first =20
> line of
> code is written.

Never rely upon suspicions when talking with people who actually know =20=

for sure. As I pointed out earlier in this thread I've written and =20
certified cockpit systems (for both civilian and paramilitary use) and =20=

requirements have tended to be just as amorphous as in any other =20
industry I've subsequently worked in. The main difference has been one =20=

of management realising in the former case that good systems rely on =20
good code and that this is something a small percentage of developers =20=

can produce, whereas in the latter there's a belief that any two =20
coders are interchangeable so long as the process and tools are right.

Personally I'll always bet on a small team of motivated hackers =20
determined to understand their problem domain over a larger team of =20
professional developers with the latest tools and methodologies but a =20=

less consuming passion.

> No silver bullets. Picking the right tool for the job is key.
> But what use is a less verbose language, if only a handful of people
> understand it well enough? Sure, often there is time to train, but
> sometimes there is not.


If I have a large safety-critical or mission-critical codebase that =20
needs maintaining I'm more interested in finding developers who =20
understand the problem domain than who understand the language it's =20
developed in. Any half-competent developer will pick up a new language =20=

in a matter of weeks, but learning a problem domain can take years.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason