Technological Deconstructionism

[Jim Gasek]

I wouldn't over-think this one.  It is simply an error 
in management, based upon the lack of understanding of 
quality, and an all-too-familiar willingness to embrace 
vaporware as a mature product. 

This isn't a "technology" problem, it is a "decision
making", a "process" problem.

The answer: Deming style quality.

Gather requirements, do it right the first time, and 
continuously improve.

It sounds amazingly simple and boring. But there is an
entire science behind it; the science of good decision 
making, the science of productivity.

It isn't sexy.   It isn't always quick. 

If management listens to an 18 or 20 year old kid, and  
bets the future of the company on some slick new tool, 
or language, and they bet wrong, the market will punish 
them for their incorrect decision.   The natural 
evolution of bad process is bankrupcy.

Our job is to find the managers who understand this, or 
coach the ones that are coach-able.    Or be the ones that
can do it.

In my experience, managers think they understand quality, 
but most are faking it.

The concepts seem so trivial, they they can't believe
there's much to it.  They think it is "common sense".

Once in a while, someone guesses, and guesses correctly.

It does not logically follow that "guessing" is a proper
methodology.

Thanks,
Jim Gasek

--- ccb-HInyCGIudOg at public.gmane.org wrote:

From: Charlie Bennett <ccb-HInyCGIudOg at public.gmane.org>
To: discuss <discuss-mNDKBlG2WHs at public.gmane.org>
Subject: Re: Technological Deconstructionism
Date: Wed, 08 Dec 2010 07:45:06 -0500

On Tue, 2010-12-07 at 12:16 -0500, Mark Woodward wrote:
> On 12/07/2010 11:43 AM, Matt Shields wrote:
> >
> > Nor do I. I'm not against NoSQL, but I've seen a lot of people who 
> > are in charge of projects I have direct say in jump on the latest 
> > technologies (not just databases) without understanding what happens 
> > underneath just because they want to work with something new and cool. 
> > I'm not a dba, I'm a sysadmin, but understanding databases has helped 
> > me immensely when it comes to dealing with people who want to try out 
> > every cool toy that comes along. And that goes for all the latest 
> > technologies, not just new database types.
> >
> > I've also noticed part of this trend is contributed by developers now 
> > trying to become their own sysadmin because they can now 
> > auto-provision their own wants with services like Amazon Cloud. They 
> > then show this cool new toy they have to upper management, who likes 
> > it. Then when they deploy it, it crashes and burns because they 
> > haven't thought through the whole environment and how it will be 
> > impacted by actual load. It used to be that they would work with 
> > operations departments to help draw up requirements, now they're going 
> > around us.
> >
> 
> A couple years back (I was 45) I was talking to a techie who was in his 
> early 60s and maybe we coined a term, or maybe other people use it, I 
> don't know. Anyway, we battle "Technological Deconstructionism" on a 
> constant basis. This trend disregards the successes and structures 
> generated by previous waves of technologists. Thus we never get to 
> build, for very long, on the foundations built before us. We are forever 
> re-inventing the wheel merely because the previous incarnation of the 
> wheel was "old" or built with a system which is no longer fashionable.
> 
> I sometimes think of an analogy between programming languages and spoken 
> languages. Imagine what would have happened to literature if every 10 
> years or so guys would say things like, "English isn't expressive 
> enough, I'm going to create my own new language!" Thus every 
> sub-generation of people speaks and reads a different language. We'd be 
> speaking some millionth variation of "ug."
> 

I see this all the time. I call it "Standing on the shoulders of
midgets"

Fortunately each new version of 'ug' (or 'blub' if you're familiar with
the blub paradox) can't wait to implement closures.


The problem with growing old is that you become increasingly aware that
everybody will be programming in Lisp eventually.

ccb