Re: How to get Ada to ?cross the chasm??

["Randy Brukardt" <randy@rrsoftware.com>]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:pd6h9u$tvp$1@dont-email.me...
> On 05/12/2018 11:29 AM, Niklas Holsti wrote:
>>
>> Agile versus waterfall depends on the project's goals rather than the 
>> language, I feel. In some projects -- space on-board SW is typical -- the 
>> customer knows what is wanted, based on intense earlier analysis of the 
>> mission, its scientific or technical aims, SW/HW trade-offs etc. In agile 
>> projects there is flexibility in the scope, the HW, the functionality, 
>> everything.
>
> Agile is coders' response to employers who heard that they should hire S/W 
> engs who use a method: We'll call what we do (shut up and start coding) a 
> method. We'll throw in pair programming so they hire twice as many of us. 
> (When engineering S/W, code generation should be mechanical.)

I think you're confusing "agile programming" with the related but silly 
"extreme programming" and "test-driven development".

Agile programming itself is simply a style where one uses a relatively short 
development cycle with the intent to have a usable/testable version of the 
end product as early and as continuously as possible. This allows feedback 
from the customer and from testing the product itself.

I've *always* programmed in an agile manner, long before anyone decided to 
get rich giving it a name and pushing high-priced seminars. IMHO, the 
lower-case "agile" is the only sane way to develop software.

Imagine building an Ada compiler using a waterfall model. You'd spend a year 
creating design documents. And for what: a well-designed Ada package 
specification is itself a fine design document. I spend time (usually 
outside of the office) thinking about the design of new features, packages, 
and so forth, but I rarely write any of that down until I actually outline 
the package specifications involved. (Sometimes these I'll write down an 
outline, but that's mainly because of the reality of my work these days (and 
also advancing age!), when I might very well go several weeks between 
starting/designing a project and having enough time to actually complete the 
implementation. I won't remember the design details without some notes.)

I also have a meta-rule that I try not to write more code at a time than I 
can write/compile/test in a single day. (Not always practical, but I much 
prefer that.) I try to break dow each taask into subtasks that can be 
completed in a day and preferably tested by itself. The basic idea is to 
always have a working compiler (that's critically important if a customer 
needs an immediate fix -- doesn't happen very often but you can be sure that 
it will happen when the compiler isn't usable :-). Whenever one has a 
working compiler, it's possible to find regressions (a very common problem 
in compiler work), bugs, and some omissions via the test suites (which are 
trivial to run; these days I have them run by a batch file called "X"; can't 
get more trivial than that).

Ada works great for agile programming, as Niklas said, because the compiler 
helps make sure that you've made all of the changes needed as part of a new 
feature. It might make refectoring a bit harder, but that's actually OK -- a 
lot of refactoring is just churn - it might make the code look a bit better, 
but it really doesn't help the ultimate goal (getting a working product). So 
it helps put a brake on the desire to "simplify" everything; rather, one 
only does it when there is really an important reason (usually because code 
needs to be generalized to support a new requirement).

                                      Randy.