Re: An Ada Advice Inquiry

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

Jeffrey Creem <jeff@thecreems.com> writes:

> Markus E Leypold wrote:
>
>> Last time I checked they were to expensive to develop an embedded
>> appliance with them (in small quantities) and then keep the compiler
>> around for 10 years for maintainance (which every sane customer will
>> reuqire). AFAIR they still have that minimum 5 seat clause (a bit much
>> for the 9 years of maintainance).
>> Regards -- Markus
>>
>
> While I agree it is nice to keep maintenance around for that time,
> this is probably another example of the different bar people set when
> they use Ada.

No. not really. If you develop bespoke software, you'll gave to give
some amount of maintenance afterwards regardless of the language. For
one thing, the customer will demand some commitment how long you'll
fix bugs and how long you'll support him when migrating to new
versions of his platform (i.e. from Win 2000 to Vista). In most
jurisdictions you also cannot avoid to give some kind of warranty
(i.e. if the software stops working after some time because there is a
bug in the database index handling, you're for it: Fix it, or pay
somebody else fixing it for your customers. You can get sued for
this). 10 years is an intervall you better plan for and often demanded
by customers, because they themselves base products (or production of
products) on the software and expect you software to work for the time
they are building that product line.

Usually the level of (badly paid) maintenance activity will drop some
time after deploying the software in question. With many languages
just keeping the development infrastructure available is not very
expensive. It is with Ada.

<...>

> In this case, we will tell people they should/must pay for 9 years of
> maintenance, which will be too expensive. So, the person will go off,
> select (as a contrived example) visual studio 6, not consider
> maintenance and end up with a product which will not be supported 2
> years out.

Well -- that's why I never would select vs6. I'd select a command line
compiler and a traditional make based system for maintenance, because
that is much more probable to stay around for some time and because it
suffices for re-building the program. Furthermore migrating from one
C-compiler to another is not trivial, but it can be done. One should
always keep a fallback option (and that also applies to libraries
which opens a whole other can of worms).

> The whole maintenance thing is largely a sham. I've dealt with a lot
> of compiler (multi language) and OS vendors over the years. Sure in

I don't care wether it's a sham. What counts, is, how much will it
cost to me to have a compiler of that kind on a then-current platform
5 years in the future (like Vista 2012 :-). As an example:

  - Gcc => will it run on Vista 2012? Certainly. There has been much
    commitment of that kind in the past and I'll expect it to continue
    in the future. As an emergency fallback I can always buy a C
    compiler from MS, Borland or Comeau.

  - Similar arguments could be made for Java: I've always had the
    choice of at least 2-3 distributions on every platform.

  - Gnat => Well -- there is the sad history of the public releases
    from ACT and then there is FSF Gnat (integrated in Gcc). FSF Gnat
    has not really taken off in the last 2 years, so there is a risk
    it will not be around in 2012. The GPL releases from AdaCore are
    not identical to what they serve to paying customers and seem to
    be rather more beta. So the only certain choice will be to shell
    out 1x000 a year. Aonix will not be a fallback, since libraries
    written for Gnat won't compile with Aonix (GtkAda AFAIR, perhaps
    that changed).

What does look more reliable to you and which choice would incur the
most financial risk WRT the costs of maintenance?

> plenty of cases I've had bugs that they have solved...But in just
> about as many cases, I've either needed to find a workaround or use
> either the full source code or source code snippets to fix their
> problems for them and then send it back to them so it can appear in a
> future version.

It always struck me as strange that you have to PAY a product vendor
just for being allowed to report them their bugs.

> Just about the worst thing you can do if you really care about long
> term support is pick any tool that requires some automated method for
> license enforcement (dongle, flexlm, etc). 10 years out, you can
> pretty much bet that even if the vendor wanted to support you, they
> would no longer know how and you can end up with a dead tool.

Yes, I know. I (that is, my customer) have already had this kind of
experience (and it sucks the more, the cheaper the tool was at the
beginning).

> If I were spending money and micromanaging a development contractor,
> I'd be a lot more interested in making sure they pick a tool suite
> that will not fail 100% when the license server dies. 

> Compiler bugs that pop up after 5 years of service almost certainly
> can be worked around...Node locked license servers..maybe not.

I completely agree. Still, the development (maintenance) environment
also is a moving target, so if the customer comes in 5 years from now
and wants a binary that runs on Windows Vista 2012 and the Gnat
tasking runtime has this little bug which makes it fail utterly on the
massively parallel multicore processors of the next decade (or
whatever), what do you do then? Generally speaking, one doesn't need a
tool that not only runs in 5 years from now, but a tool which runs on
the then-current platforms.

Regards -- Markus