From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,cbb5b0d14f503195 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: Working with incompetent adaists / unsafe typing war story References: From: Brian May Date: Mon, 20 Feb 2006 18:42:58 +1100 Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) Cancel-Lock: sha1:nMavwUgXVYUXHM+OC7MYClgXxvs= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: snoopy.microcomaustralia.com.au X-Trace: news.melbourne.pipenetworks.com 1140421379 202.173.153.89 (20 Feb 2006 17:42:59 +1000) X-Complaints-To: abuse@pipenetworks.com X-Abuse-Info: Please forward all headers to enable your complaint to be properly processed. Path: g2news1.google.com!news1.google.com!news4.google.com!news.glorb.com!newsfeeds.ihug.co.nz!ihug.co.nz!news.xtra.co.nz!news-south.connect.com.au!duster.adelaide.on.net!news.melbourne.pipenetworks.com!not-for-mail Xref: g2news1.google.com comp.lang.ada:3008 Date: 2006-02-20T18:42:58+11:00 List-Id: >>>>> "Anonymous" == Anonymous Coward 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