Re: Working with incompetent adaists / unsafe typing war story

[Brian May <bam@snoopy.apana.org.au>]

>>>>> "Anonymous" == Anonymous Coward <anonymous@coward.org> writes:

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

It is backwards. Unfortunately, when code is poorly documented, other
programmers have a habit of "fixing" problems by changing the API,
when in actual fact the API was never broken. In many cases, the API
was working exactly as initially designed.

    Anonymous> Seeing into the future is not required with private

True. But designing the public API correctly requires some ability to
make it flexible enough to ensure compatibility with future
requirements.

Also I have seen code that calculates/retrieves a number of values and
calls another module via public API function. This function in turn
calculates/retrieves the exact same set of values (as passing them
isn't part of the public API as it was originally written) and calls
another function. Repeat.  This is in code that needs to execute fast,
but ends up being very inefficient. The Management solution? Get a
faster computer.

The other side of the coin though is people who over-design.  Also
there are the people who use standards, because they are "cool",
instead of "appropriate solution". For example, ever considered
storing configuration settings and (large amounts of) low level data
in XML in a SQL database text field? This is in web based application
where speed is desirable. I got this code after the previous staff
member responsible left - I decided that fixing the code meant
understanding it first, and it would be much quicker and simpler to
rewrite from scratch. True, my code isn't anywhere near as flexible as
before, but most of that extra flexibility isn't required and may
never be required (despite client initially saying otherwise). My code
is easier to easier to understand as it doesn't have numerous layers
of undocumented APIs to try to shuffle through. It also stores the low
level data straight into the SQL database without converting to XML
first.

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

Yuck.

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

With compiled code, at least you don't have a run-time performance
impact for importing other packages (unlike ... lets say a PHP
program, with lets say a hundred or more packages that need to be
loaded for every web request).

    Anonymous> Sometimes the "correct" way IS the "quickest" way.

I agree. Unfortunately, people these days are out for "short-term
gain" and rarely realize that this leads to "long-term problems".

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

My concern is that the software design and development industry gets a
bad reputation of being "late", "buggy", "over-budget". I think many
of these problems are caused by shortcuts taken through the process.

...and lets face it, the vendor who quotes the lowest price on
software to be written is most likely to get the contract. This in
turn is likely to be the vendor that is willing to make the most
shortcuts in order to get the price down. Not just in software
engineering. I have heard this in other engineering projects, from
people involved.
-- 
Brian May <bam@snoopy.apana.org.au>