From: Eleanor McHugh <eleanor@...>
Date: 2008-04-17T01:23:09+09:00
Subject: Re: Ada vs Ruby

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ödel's Incompleteness  
Theorems or Turing's proof of the Halting Problem. In practice there  
are program states which can occur which cannot be identified in  
advance because they are dependent on interactions with the  
environment, or are artefacts of the underlying problem space.

That's why run-time error handling and fail-safe behaviour are so  
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  
> 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  
> requirements.
>
> I suspect that aeronautical problems are well understood, and
> requirements (while not easily) determined well before the first  
> line of
> code is written.

Never rely upon suspicions when talking with people who actually know  
for sure. As I pointed out earlier in this thread I've written and  
certified cockpit systems (for both civilian and paramilitary use) and  
requirements have tended to be just as amorphous as in any other  
industry I've subsequently worked in. The main difference has been one  
of management realising in the former case that good systems rely on  
good code and that this is something a small percentage of developers  
can produce, whereas in the latter there's a belief that any two  
coders are interchangeable so long as the process and tools are right.

Personally I'll always bet on a small team of motivated hackers  
determined to understand their problem domain over a larger team of  
professional developers with the latest tools and methodologies but a  
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  
needs maintaining I'm more interested in finding developers who  
understand the problem domain than who understand the language it's  
developed in. Any half-competent developer will pick up a new language  
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