Re: Working with incompetent adaists / unsafe typing war story

[Anonymous Coward <anonymous@coward.org>]

In article <sa4y80a7nml.fsf@snoopy.microcomaustralia.com.au>, Brian May wrote:
>>>>>> "Anonymous" == Anonymous Coward <anonymous@coward.org> writes:
> 
>    Anonymous> I'd like to start with a war story: <war story>
> 
> A big hurdle I find (not just in Ada software) is that the API Mr
> Safety carefully designed and implemented is insufficient for the
> requirements of the project. As a result, and due to demands from
> management to get the project finished Yesterday, Mr Safety is forced
> to expose a lot of the inner workings which he never intended.

That sounds backwards to me.  It is public (exposed) types that are
fragile to change, not private types.  Perpetually changing
requirements have minimal adverse impact when private types are used.

> The reason why the API was insufficient? Because Mr. Safety didn't
> understand all of the requirements. The reason? Because management
> considers the design phases of the very complicated software a
> complete waste of time and money. Bugs will occur anyway. What is
> the point? However, Mr. Safety wanted to try to do the right
> thing. So he tried to do the design. Unfortunately he couldn't see
> into the future for what would be required, as Management considers
> each modification as a totally isolated project.

Seeing into the future is not required with private types.
Furthermore, the mandate to use public types was not motivated by a
requirements change.  The package meets the requirements.  A developer
(Mr. Sloppy) who has principaled objections to strong types motivated
the change so he would not have to use the import routines that were
already available to him.  He simply did not want to instantiate the
object that was needed to use the API, so he drove management to force
direct support for a public version of the same type.

I should mention the pathetic /official/ reason for Mr. Sloppy's
actions.  To leverage the mandate, he only needed to convince a
systems lead.  So the reasoning he used was that he did not want to
'with' in another package (the package containing the type declaration
that the API referenced).  He was already with'ing a types package
(that is, a package containing a large messy collection of
unassociated public types), and he felt that he should only have to
'with' these types packages in order to use an API.

> Not only that, but Mr. Safety wasn't given time to document the
> API. As such other programmers tied themselves up in knots, either by
> continuing to do things in obsolete ways, or by making changes to the
> API that aren't required and break other things in horrible ways. This
> can lead to conflicts between Mr. Safety and the other programmers in
> doing things the "correct way" vs the "quickest way" with management
> supporting the later.

Sometimes the "correct" way IS the "quickest" way.  Looking at the
business case, it would have been much quicker for the API user to
make a single function call to convert his object to the protected
object, compared to what it would take to change the interface, thus
the architecture, and impact the API along with every user package
that was already using the private type.  The effort saved Mr. Sloppy
(who works direct) 15-20 minutes, at the cost of paying a contractor
copious hours to downgrade code that was already correct (and tested
as such).  After a substantial fight (which I almost didn't attempt),
I was able to introduce public versions without tossing out the
private typed interfaces, so only the API package was adversely
affected.

I said earlier that it's not my money that was pissed away - but it
just occurred to me - I'm a taxpayer :(