I can justify the inefficiencies I mentioned but not the problems you've
described.
Chuck Norcutt
On 4/5/2013 10:52 AM, David Thatcher wrote:
> On Fri, Apr 05, 2013 at 10:00:49AM -0400, Chuck Norcutt wrote:
>> Paul has it right. Machine capacity is dirt cheap these days and
>> possibly much cheaper than trying to find/fix at least some of the
>> inefficiencies in massive software systems.
>
> *Warning, long post from sour old network tech*
>
> Chuck,
>
> You are *very* correct, of course, but it is a vicious circle. More
> capacity means less care in keeping it tight. Less care in keeping it
> tight means that it needs more capacity. That said, the assassin hiding
> in the wings is that even the compilers/interpreters are now so complex
> that they are also bug-ridden and exploit vulnerable nightmares - a
> slang word for coffee springs to mind :)
>
> I know these things are complex and BIG, but a little care in
> engineering and testing at a module level wouldn't go astray - and would
> save big $ for everybody. Unfortunately the corporate care factor is no
> longer there.
>
> I was part of a situation just over 10 years ago where a tiny little
> company in Adelaide was pointing out the careless errors in some basic
> arithmetic in the router code of a large IT company... parked in front
> of the heater at 5:30am in mid-winter on a conference call, talking with
> software engineers in Sydney and Raleigh (NY) discussing IPSec, packet
> fragmentation (or not - if the DF bit is set), and the need to count
> those few extra bytes in the MTU calculation. :) In the end we had a
> winner!
>
> Even now, big companies foist half-baked vapourware on their channel
> partners, and what should be 4-hour install turns into a week(or
> more)-long nightmare for some ulcer-afflicted (and by now
> self-doubting) field tech, just because a software FIFO queue manager
> can't count. We got them to admit it and build us an engineering release
> - too late, we'd lost the client's confidence (2011). :( NO compensation
> from the manufacturer, either.
>
> The most recent event (2012) was one whre every time we made a change to
> a configuration of a device (a network router), another bit of the
> config (3 lines) would replicate itself over and over. Over time these
> made the config so large that it cannot be saved on the device's nvram.
> The fix for this glaring bug is considered to be an 'enhancement' and is
> not on the vendor's roadmap (personally, if I'd written this barf I'd be
> embarrassed and be falling all over myself to fix it - and probably in
> my own time).
>
> davidt
>
>
>
>
>
>
--
_________________________________________________________________
Options: http://lists.thomasclausen.net/mailman/listinfo/olympus
Archives: http://lists.thomasclausen.net/mailman/private/olympus/
Themed Olympus Photo Exhibition: http://www.tope.nl/
|