Re: Structure vs Substance?

Subject: Re: Structure vs Substance?
From: Andrew Plato <intrepid_es -at- yahoo -dot- com>
To: Techwrl-l <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 13 Jun 2000 13:52:01 -0700 (PDT)

"Dan Emory" wrote in message >

> >But can process
> >help? I think so, if the whole organization buys in to them.
> =====================================================
> Your statement reminded me of something I already knew, but failed to
> dredge up as the ultimate response to those like Plato who think
> structure, process, and standards are often counterproductive.

Standards are often counterproductive because they are not used as a tool, but
as an excuse. Also, most people don't buy into them - because they are lorded
over by one or a few and cannot accommodate the realities of daily work.

I don't think structure or process is evil - just constraining. That can be a
good thing (efficiency) or a bad thing (stifling creativity). And there are
times when structures need to be torn down and replaced.

> I doubt if any of those anti-process folks would grant that same freedom from
> restrictive processes to other departments of the company in which they work,
> particularly the engineering groups upon which they rely for the information
> they require. So, as I suggested in the post which started this thread,
> anti-process folks want to be able to blow smoke up their own ass (as well
> as everyone else's) without a reciprocal smoke-blowing entitlement granted
> to the other departments. They think they're entitled to some kind of plenary
> indulgence that liberates them from the restrictive processes imposed on
> others,

Are you kidding? Most departments already are totally devoid of process, even
the ones that think they have it. I have yet to see a programming team that
follows their own specifications.

Many departments are forced to deal with whims. Be that the whims of some
manager, the whims of fate, or the whims of users. Whatever the case rigid,
unflappable processes are not well suited to whims. Unfortunately (or
fortunately) today's economy is all about whims. The hot, wild crazy thing of
today is the forgotten nothing of tomorrow.

Process and structure must develop naturally from the individuals who work each
day with their respective "content". Programmers must develop processes, but
do so in a way that respond to the volatile and changing nature of business.

Dan, this isn't a "we're out to get you" kind of thing. People like me just
aren't willing to accept a stupid process just because it is trademarked or
because somebody says "that's the way we always do things." If a process isn't
producing results - quality, accurate, profitable results - it must be scrapped
or changed. Typically scrapping a process means some interim chaos while you
find a new process. Those chaos periods are good, because chaos is where
ingenuity and creativity originate.

Lastly, I am not "anti-structure"

I am anti-bullshit, anti-excuses, anti-lazy, and anti-obsession. I build
development teams where people, accuracy, and content is paramount. Apparently,
you and Tim (and others) prefer teams where process, hierarchy and structure
are paramount. That's cool. I just don't think that is the best way to do it.

Andrew Plato

Now with twice the blathering nonsense of the leading moron:

Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!


Previous by Author: Re: Chicken and the Egg
Next by Author: RE:Structure vs. Substance (long)
Previous by Thread: Re: Structure vs Substance?
Next by Thread: Re: Structure vs Substance?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads