Re: Process Dogma: Plato dissection
I know, deep in your heart and from all the things they pound into you at
business school it feels very right to spend a lot of time designing processes.
Nope. Never been to business school.
I know that for decades the corporate dogma officers have pounded into all our
skulls that (process) = (efficiency) = (quality).
Nope. Used to be in academia -- *gasp!* no wonder I like processes! Quick, tell me how horrible academia is! I was a scientist. But no professor of mine ever started spouting Covey at me.
Quality does not flow from structure. Order is not the same as completeness.
Tim's arguments may be very convincing but he (an others) are hard-wiring
concepts together that simply are not connected. Just having the right tools,
the right templates, and the right documentation methodology is not a guarantee
that you will produce anything of quality.
No one ever said it was. Obviously, if you give all of the stuff in the world to a 4-year old, he's not going to be able to make a great manual. I believe Tim, etc. are saying that processes are nice. They can help. They can help improve quality, reduce turn around time, and other wonderful benefits. Nothing *guarantees* success -- including your own 'commando' tactics.
No process, no initiative, and no internationally recognized documentation
methodology can compensate for ignorance, laziness, or irresponsibility of the
members of a team. It is foolish nonsense to think that you can impose
structure on stupidity.
And it's incredibly unrelated to the discussion. Could you please show us your evidence that ignorant, lazy, stupid, irresponsible members of your commando team are doing a good job? Because the way you're arguing, you appear to be claiming that the problem with processes is that it doesn't work for stupid, lazy people.
Frankly, the stupid lazy people had better not work with me.
One of the fundamental elements of morons is that they will defend their
irresponsibility and sloppiness into the grave. Giving them a process just
hands them new tools for hiding their incompetence.
Not really. Doesn't hide it at all. They just look stupid and incompetant following those processes too. Then you fire them.
A process simply cannot change that. It may keep a lid on open dissent. It may
allow those dumb people to float along a little while longer. It may
standardize things enough to improve quality. But it won't make a sick
organization get well. You have to throw out the morons and get good people.
Good. Glad we're agreed.
Ultimately, it isn't bad planning that ruins projects. It is usually people
who either:
(A) don't understand all the complexities of what they are doing leading,
(B) blind sheep who don't question the goals, designs, intention, etc.
Which has what to do with our processes?
How can I question goals if no one tells me what they are? That's what marketing says in their doc listing the requirements of the product. They have a review, as part of the process. Everyone shows up and tells them if those goals are good and if they'll achieve them with those requirements.
How can I question designs if no one ever tells me what they are? That's what specs are for. Part of our process is a spec review. I'm going to several spec reviews this week. They're going to list what features they're adding, and open it up to discussion. At which time anyone can discuss the ideas. And it gets it all out of the way before anyone wastes time making code.
Let me figure what your next argument will be -- that these evil, rigid documents will be our ruin. Or maybe that a spec review somehow destroys spontaneous creativity.
Well, the docs can change. Processes can allow it. Yeehaw. Big party. But it's not always a good idea to change your ideas every other day -- wastes a lot of time.
(A) Morons were in charge telling people it was no big deal,
(B) morons were listening who didn't question this.
Too bad they didn't have a process for these sorts of difficulties? :)
The few that did understand the problem were in the minority and shoved into a
corner. Once the morons take over, get out. You can't reason with them and you
can't make them see reality.
Part of any good process is getting rid of the morons. (I think I'll just call everything a process now).
Be a moron and don't question things.
So... your basic problem is that you think that processes and specs are written in stone? That's an entirely different problem altogether. Once again, you don't want to change everything every other week, but there's nothing that says things can't change, are there?
You identify a problem with the current process. You discuss it with other people in your group. You determine if it's a problem or not. you discuss solutions. Someone sends out an email that says, "there was this problem. let's fix it this way." and then everyone continues writing their docs.
Or, if there isn't time for that: You see a problem with the process. You talk with your manager/editor/lead/whatever about it. Then everyone agrees that you don't follow the process and do it a better way. Then *afterwards* you see if the process needs changing, or if it was a weird situation. All is then better.
I even have a big giant example. I have a certain selection of templates I'm supposed to use. Their made to work effortlessly through all the Big Corporate Processes and are made in several shapes and sizes to deal with the typical things our doc people have to deal with.
But... I have to write a doc not covered by any of these templates. Whatever am I to do?! I just alter one. I change it. I make it the way I need to and show my editor, my usability person, whatever -- someone else expert on the subject to get a second opinion. I make the doc, and publish it. If we realize we'll need more docs just like this, we'll make my little doc into a new template for this new brand of docs.
So, I get to go commando and use my wonderful creativity (but wait! I thought we were writers, not creative! Oh gosh, your arguments make even less sense!) to make a new template which is part of the brand new process of creating whatever document this is. Yay.
Play it safe and play by the rules. It
is unlikely you'll kill anybody so, why ever take a chance?
Yes, I hate those documentation-related fatalities just as much as the next person.
But rules can change. It's amazing. You say, "Gosh I don't like that rule anymore. Let's change it."
Why should you
stick your neck out for the next guy, right?
I'm not even sure what you're talking about here.
-Katie
Previous by Author:
Re: Whine, I got no spec
Next by Author:
Re: Documenting software in an "Extreme Programming environment?
Previous by Thread:
newsgroup to read regarding software engineering processes
Next by Thread:
Re: Process Dogma: Plato dissection
Sponsored Ads
Did this page answer your question? If not, give our search a try:
Loading
Visit TechWhirl's Other Sites
Sponsored Ads