Samantha Atkins wrote:
> James Rogers wrote:
> >
>
> >
> > Note that these two scenarios don't happen that often, but that they
happen
> > at all indicates a sad state of affairs.
>
I must inhabit a baser world than you, because your two scenarios happen to
me all the time. For the record, I did do a bunch of computability classes,
and wouldn't want to forget them now that I know them. I only recommended
against them if one was choosing a minimal first-cut to learn compsci (or
programming, at least, which I think is closer to what was asked).
Also, I'd protest that it takes knowledge of P vs NP, etc etc, to end up in
the scenario you propose above. More often than not, I find coders can't go
far past a linked list or array before knees begin to wobble. You don't have
to suggest anything too elegant before people accuse it of being obscure and
unmaintainable, and "generally unworkable" - try saying "general tree" to a
VB coder. The same people will try to build multiuser systems with Access as
the backend (after all, it's cheap). Show of hands... how many people out
there have ended up on the "maintenance" end of a system like that?
> One of my favorites is "Please show the business case for implementing X
> correctly (as it should be implemented) rather than using what [the
> kludge generating tons of maintenance and scalability headaches] we got
> approved by management last year." Where X is something simple like a
> shared Fifo queue and correctly is actually having it work for multiple
> producers and consumers which one would assume is given by the words
> "shared" and "queue". Ah well. This one comes up a bit more often
> along with "Give me a concrete example" when what is being discussed is
> a useful and time saving [and usually very basic] abstraction.
>
Well, it never matters to those people. It's the (railroaded) technical
architects who carry the can when the fundamentally flawed system falls in a
heap.
This is the same kind of thinking that produces the "behavourist" system
implementation method. You know, where you whack a bunch of forms together,
then just hack out stuff to get the behaviour right (where "right" is, more
often than not, redefined on a daily basis). I haven't been working in IT
quite long enough to have lost my sense of surprise when people suggest this
for complex distributed systems. Those are the projects where, just after
the "design" phase is done, you should get your resume together in
preparation for jumping contracts just before the implementation phase is
supposed to be finished.
What I personally really hate is having to explain to people why such a
system will not scale, will never be robust or even stable, why it is barely
even maintainable, let alone extensible... gaaah. You know... when people
want to get that 3 user system and roll it out to 100+ users enterprise wide
over the corporate WAN, and interface is with a handful of corporate
information systems... blech.
Sometimes I find it difficult to muster up that "can-do" attitude :-)
Emlyn
This archive was generated by hypermail 2b30 : Mon May 28 2001 - 10:00:01 MDT