Slashdot Mirror
Do You Buy Into Management Methodologies In IT?
albert_tam asks: "I don't appprove of 'management methodologies' and I feel that things like ISO, TQC, Kepnor-Tregoe, CMM, 6 Sigma, etc., aren't worth the time it takes to learn them. There are also those self-proclaiming-MBA-bearing IT experts, who spout off about these everyday in our office and earn big paychecks. The result? It's not important. By the time everybody in the office is forced to get started with these management methodologies, those 'so-called' Quality assuring IT consultants are already gone. The thing is, do you buy those management methodologies? How do you draw a line between IT & management concepts without hindering your daily work? Let's hear what you have to say."
IT is the death of creative programming. If there is a management philosophy that doesnt reduce to "protect the project from idiot programmers", I'd like to know what it is. In fact, I thing OOP was borne of such a management philosophy and it shows in the resulting code. That wasnt a flame, simply an observation of the code quality in really large c++ projects.
Anyway, the problem with all this is that as much as management theories de jour protect us from the idiot programmer, they kill the good programmer.
If it wasnt for rogue programmers following their own star in their basement, there wouldnt be any software to speak of today and IT would be busing trays in the cafeteria.
Sorry, committee software always sucks and management has never created a truly worthwhile and original piece of software, not ever.
Now... preach all you like about how hard it'll be for the next guy, but like customizing my car or my house... I don't worry about what the next guy will think about my code. Do you care if the next owner of your car might not like it if you paint it red? Do you care if the next owner of your house disapproves of you converting the garage into a pool room? Heck no. Well, it's the same with me. I work for my own benefit, pleasure, and satisfaction. And to do that I've gotta do the best damn job I can at work. Otherwise; no money; no fun. This philosophy is reflected in my code as well. I've cranked out some godawful nasty kluges that confuse even me when I look at them a year later... but I got the job done, by the deadline, while some of the junior programmers seem to wanna rewrite everything to make it clean rather than break the nice design of the code. Feh. That's why they're junior programmers. They Just Don't Get It (tm). Their plan would send the company under. Stuff's gotta be done now and ship next week or there's no profit for the company and no salary for the programmers. Junior programmers always seem to be self-delusional with grand plans of redesigning everything. It never happens. Requirements change *ALL* *THE* *TIME*. Any static plan is doomed to fail. Once they realize this they make the transition from dreaming programmer to master hacker... or they can't keep up with the pace of real world business and disappear. You've got to be able to deal with old crusty projects written by long gone staff with more bags and bells and whistles and ornaments hanging off the side and kluged into it, written by more people you've never met, and you've got to be able to quickly and successfully hack more stuff into it and hack it and rehack it and change old stuff and keep it all running. Successful, on the fly, under the gun kluging is what distunguishes the Senior Programmers driving the big smog polluting, shitty mileage, comfy luxury cars into the front, covered parking space and getting the stock options and profit sharing and 401Ks from the idealist larval dreamers driving their small car becuase "it's good for the environment". Self-spirit-lifting-and-self justification-bull. Given the Big Bucks, you'd ditch that Civic for a gas guzzling SUV or Corvette too. So forget the dream. Getting a clean slate to build on is a rare event. 99% of all programming jobs you'll ever be hired for will be holding together someone else's code. Insane deadlines, getting the jump on the competition mid project, reamping of requirements (many times over), decision reversals by management, your latest self-gratifying achievement being abandoned and dumped because it's not needed anymore. These will all eventually break your spirits. On the plus side, once you realize this, you will be able to succeed and advance within your company or find it easy to get hired at the next comapny. because quick thinking master hackers who can do the magic again and again despite laying waste to the original vision and still keep on kluging and have it keep on working are what companies want. If you can do this, you will succeed. Getting back to the original question... do I obfuscate my code? It may certainly look that way to the idealist, but not so. True brilliance is messy. Remember the famous comment preceeding the task switching code in Unix... /* You are not expected to understand this
*/ But if you can, you'll be a god... or root... what's the difference again? Anyway, class dismissed.
Yeah yeah, and Yanks are piss-flap licking ponces.
Maybe you should insult people in their own slang, so that the full force of your juvenile outpourings. Most Brits would understand weeny to mean small, which isn't a particularily offensive insult. You wanker.
Because of these issues, we end up with an attempt to implement practices that work great for engineered processes, like building an aircraft or desiging the next space shuttle, but don't work in the "can't we just add this feature" and "oops that required feature in our database is broken" realities of general software development (ie, not embedded systems or video games, where the hardware is controlled and the bugs known, etc).
Schedules are too tight and demands too high to expect great code that is expected to run on general computers. Microsoft (no I'm not a Micro-junky) learned this and learned that software for the desktop not only cannot be perfect, but the attempts to make it so end up costing alot of money for almost no gain. Instead, make it as good as you possibly can within the timeframe and budget you have, and then make it better in the next round...and better and better.
Software development is an art (hence "The Art of Computer Programming") and not a science. The sheer number of variables and complexities are mind-numbing, and result in a process that, even after 50 years of total experience (or more like 20 years in the pc realm) of managing software projects, we still are only so good at making the process flow smoothly. Attempts to manage the beast tend to result in more time spent in process management than in the design and coding.
But the upper management, who wants this control, also does not want to spend more than they are now.
So if the Management Consultants really were telling the truth, perhaps they should be saying this: We can give you better software, but you'll have to pay 50-70% more than you are now, without expecting much more in actual output (other than reams of documentation). You won't make any more money on the sale of your product for having done so, you'll still have a design that, in 5 years, you're engineers will say "what the heck where they thinking," and you'll have paid us millions to tell you so.
That's the way I see it anyway :)
"Oh, you have an ISO Q2001 certification so at least someone in your group must be at least a little competent at keeping track of things."
They are a sales tool.
The question of if you actually use these organizational skills and written processes to do actual work is another matter entirely.
The alternative to limited government is unlimited government.
ISO 9000, 6 Sigma and pursuit of the Malcom Baldridge awards are basically a good way to burn money. These are well intentioned but counter-productive trends which swept through various manufacturing businesses during the early 90s. I've seen companies literally shut down while trying to implement these faddish ideas. 5 years later, you ask them what it bought and they don't want to talk about it, officially. Unofficially, they say it was a waste of time and money. ISO 9000, which in a nutshell is "document what you do; do what you document", is seductively common-sensical. But those who have implemented it have spent much and gained little. Did anyone notice all the ISO stuff on the Firestone sign outside the Decatur plant?
Resist this trend in the software business. It hasn't worked in the hardware business except to line consultant's pockets.
Wansu, th' chinese sailor
... despite being a management consulting company that takes money from others in order to give them advice on techniques "appropriate to the individual client's unique situation", we use none of those techniques internally. Kinda makes you think, doesn't it?
"Flame away, I wear asbestos underwear"
Anything I have to say is allready said here.
Can you see Iron City here?
First of all, what's the other alternative. Running your business without any methodology means letting everyone do their own thing their own way. That maybe good sometimes, but not always.
Several good management methodologies do exist. In Europe ITIL (Systems management) and Prince2 (Project Management), both developed by the CCTA have a large user basis. Learning these is very useful, since both are used in a large number of organisations.
Lets own up first, I was one of those consultants....
I believe every serious development shop needs processes; how rigid they are depends on the product. You'd hope the folks building air traffic control systems are very methodical about their QA, at all stages of the development lifecycle. On the other hand, an e-commerce development project is not much use to anyone if the processes mean it takes 3 years to build a simple shopfront.
In my experience, process improvements are nearly always possible - though not always justified. Solid, proven methodologies can help (and have done in many organisations).
But :
- if the change is imposed top-down, it is unlikely to succeed - programmers are by nature not likely to respond to pressure from above, and will at best comply reluctantly, at worst leave or sabotage.
- the need for change needs to be identified and championed by someone who is credible with those most affected - ideally someone with hands-on project responsibilities, a user or customer
- the process needs to fit the project and the people
- incremental change is far more likely to succeed than a revolution.
The only way I know of improving the software process is to start with the development team (including the business analysts, testers, support folk etc.) and representatives from the rest of the business, identify the concerns, bottlenecks, common failures etc., and agree on a broad framework for improvements. That framework may have a fancypants name, or may just be made up on the spot. We then agree a set of monthly improvement targets - and it is nearly always about basic stuff, like code reviews, version control, "who-does-what-when", change control, and hand-over points.
Of course, I gotta eat, so I will most likely convince the person who signs the checque that the development organisation is reaching Maturity level 32 on the Institute of Made-up Professionals IT maturity model, and that they are leapfrogging the competition yadeyadeyade.
It's all very well in practice, but it will never work in theory.
1. Listen to your people.
2. Do what they suggest most of the time.
3. The few times you do something else, explain very clearly why.
Here's the opposite, as practised by too many managers:
1. Assume you know everything.
2. Override all objections.
3. Never tell people your reasons, because it would just 'confuse' them.
Jeremy Lee | Orinoco
You are of course completely right in saying the measurement is part of the science involved, and without measurement any attempts at improvement are based on guesses at best. However, the problem with most management methods is that they do not put the measurement tools in to the work flow of the workers but only graft them on to the side.
In that case updating the measurements *is* auxiliary to the actual job at hand, and will not be done.
As an example: an editorial board can benefit greatly from knowing how long diffent stages of editing an article take, and how well a certain editor performs at each stage. Maintaining this information is a major hassle, however, as it has nothing to do whatsoever with editing articles. But, if one incorporates maintaining this information in the meta-work of finding the next article to work on, it suddenly is incorporated in the normal work to do, and the information will be kept up to date.
Would you please not post messages in monospaced font mode. While they look different, they are hard to read and cause eye strain.
Mea navis aericumbens anguillis abundat
Anyone ignorant enough to think that an IT department does the same thing at, say, an insurance company versus a heavy manufacturing firm deserves to have live weasels shoved up their ass.
Peter Berger - in defense of dubbing in Anime.
- To know your work matters. Make sure employees know their work will be used and will have a significant impact.
- To know that you are responsible for you work. You have to know that you are ultimately held accountable for your work.
- To be able to judge the quality of your work. Working in a vacuum without evaluation makes it hard to keep striving for excellence -- people need to have benchmarks to measure their work by.
I have been part of a crappy methodology (where I am now) and as well as an effort to develop a fledgling methodology from scratch. What have I concluded from all this effort? Methodology is a tool to help people communicate. It gives people vocabulary and a framework to exchange information and solutions to problems they have been working on. But in situations where communication is not encouraged or cannot flourish for other reasons, then methodology has to carry a lot of weight. I have seen it buckle and fail under that weight -- people flounder trying to communicate with each other and it is a nightmare.The bigger the project, the more important the standards that methodology brings.
I am still reading various books like the Peopleware book in an attempt to get better insight in how to manage / integrate with this on a daily level.
The problem, I think, is who developed the methodologies. IMHO, a bugzilla (modified to have fields for file revision numbers) and good CVS comments are what makes software producing an engineering. Science, it will never be, because CS is about discovering how to build things, and build the correctly, not how to make people build things correctly (however, that's another science).
--The knowledge that you are an idiot, is what distinguishes you from one.
Nope, I don't. But IMHO, that stage is best performed with a) a mailinglist/IRC or (better) b) a big whiteboard... OK, I might be a bit narrowminded and detail-centered little techie - but hey, it's I who am to _implement_ what the management comes up with...
--The knowledge that you are an idiot, is what distinguishes you from one.
A lot of great insights here that reflect an excellent understanding of the relative worth of process and people, of the difference between making work better and covering butts.
In my experience, there is a simple way to test the benefit of a process or procedure: Do you have to force your best and most conscientious developers to use it?
Good developers (generalizing here. People being people, we will always have exceptions) tend to embrace things that make their jobs easier. Things that result in a better outcome tend to make their jobs easier overall. Note: This test doesn't apply very well to initial adaptation. Few people take well to change.
The flip-side of this criterion is that every new procedure or requirement must be critically analyzed for its benefit to the people being asked to use it, and how much effort it adds.
Cumbersome processes will be circumvented at crunch time. Period. It is always better to have a lightweight process that will actually be used than a supposedly superior process that will be ignored.
So ok sure...I make my living as a methodologist.
That doesn't mean that there aren't pinheaded methodologists out there, nor does it mean that you haven't been afflicted with one.
But just because some people are jerks or are inexperienced doesn't mean that methodologies are bad.
Whether you ( and by "YOU" I mean the whining / just let me code / I don't need no stinkin' methodology gang) admit to it or not, you DO USE A METHODOLOGY.
It just happens to be one that your habits and temperment cause you to fall into easily. But like anything worth doing right, software takes some effort.
Many projects struggle with methodologies because they view them as "all or nothing" solutions. It's important that the methodology lead DELETE deliverables that don't provide clear benefit in terms of writing better code.
Quite a lot of whining going on about "extra work" and "procedure" and so on.
Is anyone out there an artist? Don't you realize that it takes years of study and practise DRAWING INSIDE THE LINES before you have the confidence and experience to break with tradition and common practise....to succesfully strike out in a new direction...to change the paradigm?
In my experience (which is VERY extensive, gang), a good,balanced use of methodology (and some are better than others) leads to an average of 6 months from conception to deployment....and the designs from those projects run solidly for years and years.
But please, always remember..."A good coder copies, a great one steals!".
Hear hear!
Plaudits and applause...
bet let's not forget that age old adage:
"People will NEVER do what you expect...they will ALWAYS do what you INSPECT."
A tiny company doesn't need management methodologies. There's only one or two bosses and the employees know what needs to be done. But a huge corporation has hundreds of bosses and no one knows what direction to go. MM ensures that everyone is on the right track. Sure it involves a lot of bureaucracy. But so what? Any company over a certain size is going to be bureaucratic, with or without MM.
There are several aspects to management methodologies. First, it institutes standards to ensure that everyone is building their piece of code the same way. It says "this is how we do things around here." Second, it tries to ensure a quality process. Software needs every bit as much quality assurance as a piece of hardware, but the industry is only now just coming to realize this. Finally, MM tries to ensure process improvement. If something was done right them make sure you do the same thing for the next project. If a defect was found, discover the cause and make sure it never happens again.
Those three things shouldn't be that hard for IT and Development to grasp, but for some reason they are. Follow industry standards, build a good product, improve yourself. When you have more than a dozen chiefs in a company, making sure that gets done involves either telepathy or bureaucracy.
A Government Is a Body of People, Usually Notably Ungoverned
If you don't believe in any sort of management methodology, then ponder the following scenario.
.. a week? a month? three months? How many people besides you will she need to get working on? What skills do they need? What other resources do you need -- software, hardware, etc?, she asks. Suppose it's obvious that it won't be a one week task, but rather involved. She wants to know periodically how well you are doing. Are you behind because something you need isn't available? Are there questions about what you are doing that weren't obvious when you first took on the task?
A coworker, not necessarily your boss, but someone you have a cordial working relationship with, comes to you with a need for a project of some size, and asks you to help out. She wants to know how long it will take you
How are you going to give her your answers? What criteria can you use to tell her accurately how long it will take, and to know as you are going along if you are going to meet that target date?
How will someone keep track of what was requested and whether or not those needs have been addressed?
If you can't give good answers, if you make mistakes in saying how long it will take or what resources you need, your coworker will be upset, you'll look bad, and life will be rotten. You don't really want to try to work 100 hours in the last 5 days before you said you'd have it finished do?
Finding ways to answer these questions are what these 'methodologies' are all about. If you can't come up to this level of expertise, you're not a good professional.
I don't approve of 'traffic laws' and I feel that things like stop signs, speed limits, one-way streets, etc, aren't worth the time it takes to learn them. Why can't we just all go as fast as we want any way we want? The good drivers just end up going slow, roundabout routes to get where they are going just because too many drivers don't know how to even steer. It's all just an excuse for bloated civil engineering companies and overpaid traffic engineers to pump the driving public for money. Creative drivers who could actually get somewhere and find new routes that others can use are held back.
It's not up to governments to say you need X amount of QA to produce software. If you concentrate on getting the job done with minimal tracable documentation of how you've gone about it, then you will indeed have it done faster and cheaper, but the phrase Caveat Emptor springs to mind.
I've both worked for and with companies that have tried churning out code without process and it's hell. Everything's fine until (aot unless) something goes wrong. If you institute good QA then not only do you have a better chance of better software (in the long run), but you also get a reputation for it.
This is the main reason for instituting good QA. Consistency. If a company consistently produces good software, they will make more sales.
Noims
This is not the greatest sig in the world. This is just a tribute.
I couldn't agree less. Quality starts at the top of the hierarchy. Unless management recognises that resources have to be allocated for proper documentation of projects instead of just tinkering along, quality control will never take off. And it pays of in the long run. Temporary systems have a tendency to become permanent solutions. Maintaining and extending functionality on those systems is a real pain if there isn't any proper documentation and you weren't involved with building them in the first place.
-- Spelling and grammar errors tend to be a sign of erroneous thinking.
The individual has to ben encouraged by the top. If the top is only paying lip-service to quality control mantra's and methodologies, it just doesn't pay of for the individual to pay attention to quality. Or in your words: the individual won't give a shit. Management endorsement won't result in the opposite, but lack of management endorsement will inevitably result in the bottom of the hierarchy not giving a shit whatsoever.
-- Spelling and grammar errors tend to be a sign of erroneous thinking.
Managers want results. They also want to bragg about how qualified their staff are.
;-)
The result of this is staff who've been trained in techniques for this, that and the other, but managers who won't let them work according to those techniques.
All in all, it's a waste of time. Of course, that hasn't stopped me making a not inconsiderable amount of money by extolling the virtues of such training
Nick.
A book that makes a similar argument (though from a completely different place) is The Social Life of Information by John Seely Brown and Paul Duguid (Harvard Bus. School Press, 2000).
Brown is the head guy at Xerox PARC, and his critique of process management and re-engineering centers on how these top-down models ignore the actual, situated practice of people doing their jobs. A lot of the examples come from Xerox' service reps, who have been studied extensively over the last couple of decades.
My question is why are the methodologies being introduced. Are products constantly late? Is quality poor? As a project manager there are basic mistakes that are made time and time again. Poor detailed design, overly optimistic schedules, poor product concept from management, and the list goes on. Management does not know the difficulties of programming; IT sometimes does not understand the marketplace. The key is good communications, common goals and attention to basics.
Answers to your questions:
No I don't buy them unless there is a plan to implement them, and the basics are already being covered. (BASICS - some sort of development lifecycle, people management, good design before any code is written, understandable product concept, good project schedule - don't just try and meet an arbitrary completion time set for management talk to them explain why it will/should take this much time instead of that much time.)
"How do you draw a line between IT & management concepts without hindering your daily work?"
Any type of training will hinder daily work and will eat into your time. If an organization needs to make changes the time needs to be set aside to put them into place. That has to be an understood tradeoff. It is worth it if it does solve problems in the longer run. Regardless people have to admit there is a problem first (kind of like AA).
If there are problems at an organization you need to identify them, try and figure out why they are happening, and make sure the basics are being taken care of. If you are covering what you define as basics and the problem persists then give something new a try.
"I don't think it's selfish, to eat defenseless shellfish." -NOFX
An interesting book. However, anybody who goes looking for it should note that the author's name is Gary Klein, not Alan.
-- Remember that we live in a world where all the really big decisions are made by people with short attention spans.
I can think of a few people who should really read the stuff on the correct deployment of coders.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Expanding a vast wasteland since 1996.
Science requires definition. You go and define what quality is before you try to measure it.
Until you can define for me what quality is and how to measure it, don't try to tell me that Quality systems measure quality.
Robert Pirsig has explored this concept extensively in his works Zen and the Art of Motorcycle Maintenance and Lila.
I think the conclusion he reaches is that you can't reach conclusions about such things. Either that, or I need to read it again. I was sorta side-tracked by the whole what-the-heck-happened-to-this-guy's-brain-anyway thing.
Seems like you've bought into management's little imaginary world a little; isn't "methodology" just a hype-inducing (and incorrectly used) version of "method", used by PHBs to subliminally make people more receptive to their "methods"?
--
SecretAsianMan (54.5% Slashdot pure)
Washington, DC: It's like Hollywood for ugly people.
Let me advise those of you out there who are thinking about working for a big company IT dept. Every big company has more interesting parts to it and less interesting parts to it. You want to work for the interesting bits of the company, and avoid the boring bits. The interesting bits of the company would be "Engineering" or "Product Development". The most boring bits of the company you can usually find under the "G&A" column. Guess who the CIO usually reports to? The CFO. Guess what the IT dept is generally considered part of? Accounting. Guess what Accounting is considered part of? G&A. Guess where the major mgt consultants concentrate their efforts on to work their special brand of, um, magic? The "G&A" part of the company. Do you see a pattern developing here?
Granted, it's not exactly this way in every company, but the majority operate similar to this.
Second, this really great quote from Richard Buetow, the Director of Corporate Quality at Motorola:
Then it seems to me that management should concentrate on hiring good help, rather than coming up with processes that control the bad help. Seems that having good people working is MUCH more productive than covering up the fact that your people suck. Also sounds like because they continue to use bad help, that in the long run it would be cheaper to pay the good help more, and raise the amount paid to entice more help. it would cut out the job of the "process manager" and would cut the need to fix the bad people's mistakes. Sounds like a vicious cycle to me. Maybe some managers should rethink and find more efficient ways to do thier job, even to the end of putting themselves out of a job. waste not want not.
.e.
www.perceive.net
People see the world as they are, not as it is.
What you should do is listen, as well. The best companies have people working on their own initiative, and the management are there to help, not get in the damn way.
Not true; if management is competent enough (which occurs in certain rare companies), they are part of the "workers" and can take part successfully in quality. An amazon search on Six Sigma should a good book full of case studies at various large companies.
I think it is possible, to come up with decent methodologies, but at least where I work, they seem to codify the existing mistakes, and make them repeatable rather than actually think about how to improve the process. Frustration with this led me to attempt to come up with a general strategy of development based on ancient Chinese military strategies. Check it out at The Art of Web Application Development. I'm curious as to what people here think of my approach (tongue-in-cheek as it is.) It's a pretty straightforward translation of basic principles on management and strategy, that I think work better than trying to document every detail of how things get done.
This is why I haven't.
--Scott 8-}
Probably a good thing that the floating fat man wasn't Duke Leto then isn't it? I'd suggest reading Dune or failing that at least watch it sometime because aparently you haven't.
If management bought into the methodology as a tool to change the enviroment (preferrably for the better), then I'd bet some of those methodologies would be of benefit to the organization. However, management ususally buys into these methodologies as a tool of excuse for the (currently bad) management practices, and (other than a name change) the environment remains the same. The only difference is that the manager now has an official piece of paper that codifies the bad management practice, and makes it 'OK'.
"values of beta will give rise to dom!"
... AND I think you need to find a better job.
"I'll take the red pill. No! Blue! AAAaaaahhhhhhhhh"
- Monty Python meets the Matrix
The ability to say something like that, with evident confidence that it ends the discussion, is what makes the rest of us suspect fraud. It may be that there is no science without measurement -- but the delusion is that once we start measuring, everything we do becomes science.
The hallmark of the management fad is faith in a Secret Handshake, something you can do without thinking very hard, and once you've gone through the process, you done something that isn't quite "management" or "leadership," but is isomorphic to them, and therefore just as good. MBAs managing technical projects, like gym teachers teaching physics, want desperately to believe that stone ignorance of the activity they lead is no handicap, because they have Process Skills. And now both the MBAs and the gym teachers have discovered they can succeed -- so long as they get to define "succeed."
For what, after all, is this "quality" thing that is being measured? It turns out that "quality" is defined as whatever today's Quality Régime chooses to measure. "You mean," I asked the Quality Manager, "unless we follow these guidelines, our product won't be any good?"
The Quality Manager knew better than to take actual responsibility for contributing to the success of the project. "No, no: 'Quality' is a technical term, meaning 'compliance with procedures written before or after the fact.' It has nothing to do with whether the product is any good."
"So why should I write procedures and compliance reports for you, when doing so forces me to do a slap-dash rush job on the product?"
"You have to do the reports," said the Quality Manager, "What's the matter? Don't you want our product to be any good?"
In short: On matters for which Quality experts want as little accountability as possible, "Quality" refers only to a small, technical, ministerial process. On matters for which Quality experts wish to maximize everyone else's accountability to them, "Quality" retains its usual, broad, and moral meaning.
Now, all that said: The impulse to write down everything that was done in the course of a project is a Good Thing. A worthwhile project will outlive the interest of any working set of participants, and, being worth while, the project deserves a memory of its own. It's why I write design notes and comment my code, or at least feel terrible when I don't.
I don't object to running projects as if all participants knew what they were about. I resent the tendency of Quality consultants to huckster deliberately content-free procedures as a pacifier for managers who are frightened at not understanding what they are about.
The link to CMM at Carnegie Mellon is:
http://www.sei.cmu.edu/cmm/cmms/cmms.htm
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
But as you said, there arent enough hours in the day to do all the exta stuff. It costs extra to do this work, especially in the same
time the work can be done with out it.
How can this be rated "Insightfull"?
Research about Software Process Improvement shows: a) you do not need extra time
b) you save time
c) every dollar invested in process improvement (of course you have to follow later the better process) gives an RIO of up to ten dollars
d) every stage of CMM level reduces costs and time around 15% and up to 50%
e) CMM level 5 software organizations, e.g. the IBM department which programmed the software of the space shuttles work for 10% of the price a standard software hosue does.
f) a standard software hosue would thus NEED for the same business the ten fold amount of money
For undertaking such hughe endeavours you either choose no process, like in "Open Source" or "Free Software Projects", because you have "no costs" or you choose an CMM level 1 organization because no one else can make it for a reasonable price or with resonable qualitiy.
I proclaim: everybody who do not believe in a well organized software process, simply did never try for 4 weeks to stick to the ruels of "his" process.
Because he "knew" it would not pay off.
for further reference of a) to f) read:
http://www.sqi.gu.edu.au/spice/
or http://search.web.cmu.edu/compass?ui=sr&view-temp
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I don't know about the rest of the "methodologies", but we'd be living in a pretty fragile world if nothing adhered to standards like ISO.
It's a way of assuring quality and conformance to a standard. That CAN'T be bad.
http://www.logient.com
The ability for a group of people to manage and understand a large interacting group of computers depends on organization.
/etc/init.d scripts.
That can mean any of the following and more:
Organized, color coded cabling.
Documented and correctly written
Keeping patches up to date.
Etc.
You need to see that these type of things happen if you are going to keep things working smoothly. If it means ISO9000, then do it. If it means a 5 page set of guidelines, by all means, DO IT!
-Jeff
It has been my experience that most "methodolgies" are simply a way for management to Cover their Asses and to assess blame whenever something goes wrong. Don't get me wrong, I believe that good analysis, design, testing and doc are critical to creating functioning systems, however, it seems to me that most of these methodolgies have been perverted to protect the guilty, not to help the innocent (user). Software creation has never been a mystery to anyone that has actually built something that works efficiently.
Confusion to the Masses
We are currently establishing an SDLC process where a consultant was brought in to get us going. He started by creating a 'framework' with the managers of the development group. This framework was split into several groups that were to come up with the details on each of the sections of our framework. Using this description, it all seems reasonable. However, the execution failed. Our framework was tainted because instead of facilitating our managers to create a process they could buy into, it was more of 'it's only right if the consultant thinks of it or fits into their pre-conceived framework'. The group meetings with the developers was worse, we rebelled. The first week's meetings were bad and we complained. The next weeks meetings were worse, and we complained more. The beginning of the third week saw the halt to all the meetings. Our CIO has realized that the meetings are not helpful mainly due to the lack of facilitation skills of the consultant. Everyone realizes the need for an established process:Error reduction, consistent development standards, ease in adding new developers to a team, etc. This week, we're going to try a 'do and review' approach, rather than a 'cuss and discuss' approach. Wish us luck.
The manage ment has been downsized, long live the Management.
<This .sig left intentionally blank>
In general, I think that methodologies are bad. They might be born out of a good thing, and people tried to capture that good thing into a "standard", but eventually most Good Things that people do depend more on the state of mind of the people than the actual things you see them do. (The Programmer's Stone is an enlightened discussion of this.)
Methodologies usually lead to the people in the right state of mind being repressed by the people following the methodologies; all new ideas are pushed into the straightjacket of the methodology, killing all fun in work for the more pragmatic workers, who also happen to be the brightest ones usually.
A friend of mine used to say that a methodology is a systematic way to overlook reality.
A big problem that I've seen is that people use the methodology as a standard of all that could possibly be done to do the trick, not as guidelines of a minimum amount of things you could do, as a baseline for the rest of the work. People start thinking that if they obey all the rules, they won't loose their jobs even if they don't even think about things at all anymore! They can just point to the methodology, say they followed the rules, and they're not to blame.
Methodologies should be practised pragmatically, using it when it's appropriate, doing more than the standard requires when it is needed and doing less when following the standard would be overkill and would just lead to bureaucracy. A little cherry-picking isn't bad at times!
Quite so.
The main reason Scott Adams can get so much mileage out of PHBs and their silly antics is 2-fold:
- 95% of the audience is managed by someone else.
- 11/12 managers are incompetent in one or more respects
and the basic reason for the preponderance of bad managers that are easy to poke fun at from the armchair is....Good Management is a Difficult Job that Few are Qualified to Do
So few managers have what an earlier poster summarized as "brains" and "ears" that most organizations run hobbled.
Codified management techniques in Quality are great iff they help managers and the managed to grasp the fundamental precept that
It's just that easy and just that hard.
"Provided by the management for your protection."
Of course resistance to change is a survival characteristic, and a learned behavior to boot.
That was really good. I just wish the Qualitarians had chosen some other word than Quality to describe what they're doing. Quality is a deep and connotative word and shouldn't be reduced to a label for a checklist wielded by an impostor.
Of course, none of this addresses freedom from bugs, which is certainly an important part of quality. But if we're aiming for Pirsigian quality, freedom from bugs is not enough.
All software sucks? No way. Most mass market commercial software sucks big time, but that is a very small part of "all software".
Take a piece of software and use it for what it was intendet for, with hard and software that is stable and you'll see very little suckiness.
OTOH If you buy a "one program, all purpose" shrink-wrapped software solution, use it for something the authors never thought of on a highly customized PC how do you expect it to work?
It's techies' arrogance that makes everything computer related suck, period.
No. Arrogant techies are part of the problem, clueless managers are too.
The problem is, has been, and probably will remain, that computers are used for everything. A F1 car is a piece of near-perfect tecnology. Still it would be worthless on an off-road track. Computer users expect their programs to be designed for both F1, Off-road and city streets. That simply won't work.
All opinions are my own - until criticized
one of the most useful aspects of (any) methodology is to allow people who have not worked together before to quickly understand where a project stands and what needs to be done. think of it as "project management patterns" and maybe it makes more sense.
A methodology is just a checklist; so let's look at where a checklist is needed. I would submit two situations: where there are a bunch of kiddies involved (sorry, just because you've been coding since you were ten does not make you an experienced commercial developer without *actual work experience*); and where there is a complex, multi-team project to be implemented. I agree with the respondent who blames the execution rather than the methodology. It's easy for a pedant or paper-pusher to emphasize the means over the end. I have worked for a few great project managers and have seen how they use these lists to keep track of the umpteen details needed to put a large project in place. The modern, n-tier architectures we are all designing and writing to these days are significantly more complex than the old mainframe or two-tier client-server apps of ten years ago. A methodology is a powerful tool in the hands of a pragmatic, experienced manager; like any powerful tool, it has the potential to be a problem when misused. Lastly, all methodologies are not equal. The good ones recognize different sets of activities are needed for say, a from-scratch e-commerce implementation vs. implementing Peoplesoft. I have, for better or worse, worked with probably a half-dozen full-bown ones and there is only one I would ever put the time into implementing, because it is flexible, extensible and makes no pretense of being anything other than a checklist.
Most attempts at implementing some methodology like this have been miserable failures, in my experience. This has been because
;-)
- a) The team was already well-organized, efficient and shared a common vision of what we were building and how we were going to build it
OR
- b) The team had no shared vision of how to build software to start with, and the methodology was no silver bullet.
In the former case, the methodology is unnecessary, except to document what's already happening, and any team that together will resent the extra work for the rubber stamp. In the latter, pressing a scattered group of individuals through the meat-grinder of a particular methodology will probably just make them work even more poorly together.
Naturally, having an organized, coherent and, most importantly, useful plan for each stage of development and the overall process is a Good Thing(tm). But having it on paper, or have it follow some management wonk's version of Utopia is irrelevant.
By all means, take the time to find some common ground for selecting lifecycle methods, designing, coding, reviewing code, writing documentation, testing, tracking defects and progress, etc., and then follow them religiously. Make sure that new hires are trained on how you do things, and understand and agree with your methods (or are at least willing to follow them for the greater good).
Later, if it turns out that more people will actually buy you're software because you're a CMM level 4 shop (or whatever) - hire some writers to handle the certification process if your engineers don't want to see it (and they almost certainly won't)
These methodologies when you study them state many of these common truths everyone knows and give you the feeling that its useless to study them, but thats their worth to repeat these things. The truth is that you will forget many of them and methodologies are here in first place to remind you the obvious. From my own experience, even if you should write your own methodology, it would be worth the effort.
If programs would be read like poetry, most programmers would be Vogons.
FWIW, most of the methodologies try to package experience and best practice into a procedure. T If you ever try to get any skilled task quantified you end up generalising or over emphasing aspects that don't really matter for Your project.
What it comes down to in the end is repeatability of consistent results. The project managers can estimate more accurately what is going to how long. The customer will know roughly what sort of end result they will have. The account managers will be able to be up front about where the projects are at. The end user will have consistent documentation.
In some cases (like for various defence or high risk projects) it is a requirement to operate under a methodology for the above reasons.
Although they give good results on large projects they tend to bog down smaller projects. So what I have seen work well is that you look at what harmonises with your projects and organisational structure and focus on that. You will find that most seasoned professionals will do large swathes of what is captured in the methodology anyway.
Methodologies move beyond doing it Joe's way and capture what Joe does and insulates the organisation from Joe being bought out by the cool new start up that just opened it's doors in the office downstairs.
Cancel them and return to section Nikita.
That said, there was one instance where our company (we do a lot of contracting for the government) was able to move ahead with work cuz the customer demanded ISO compliancy...and we could show it. In the end that means something to those guys and gals who have to put food on the table.
Before I get too off-topic here and am moderated down...Let me say that I buy the idea of standards and the idea of eliminating rework. At my level, does much implementation really happen? No...and to me that creates its own amount of frustration. I agree that a lot of upper-management gets sold on buzzword methodologies...that's nothing new! At the same time, I still need to feed my family...and its my companies customers who help me do that.
Galego
Que Deus te de em dobro o que me desejas
[May God give you double that which you wish for me]
As an IT manager, I find your question rather amusing, because I have no idea what you're talking about. Now, I realize that this is because I've come up through the ranks, rather than getting a management degree and getting transplanted into a management role. But I would think that I would have at least encountered one or two of these techniques you're referring to. *sigh*. I guess I need to go back and read "How To Be A PHB."
Apache guy, Open Source enthusiast, runner
How about this point of view: Process should be a tool that 1) Gives Management information they can use to make decisions (like identifying problems people shortages-failures, resource, etc.) Is the project getting done on time with the kind of quality required. 2) Gives the workers definite goals (like exactly what they are expected to do when. 3) Provides a known structure for getting work done that can be communicated to new folk. With that said, an awful lot of process engineering goes on without seeing if the previous process was actually used. My experience is that the process often is blamed for a failed project when the process never really got used. Somtimes people play with the tools without every really using them. E.g. Scheduling tools are used to enter dates without actually planning the project or working with the programmers that must design and prodcue the code. Single departments of people who know each other well often do everyting required of a good process without having much of their process documented. The world is filled with single departments and small shops failing when they have to scale to large shops and deal with diverged goals and points of view. They also fail when some really competent human goes away and takes coordination (that should have been part of the process) with them. I think that process is a good thing; but, that it is dependent upon people. All of the users of the process should be held accountable for the results. A good process can be a real tool to promote two way trust and foster communication. As far as I know all really successful software development uses a process. If it gets repeated time and time again the process is written or the company has an uncharacteristically high retention rate...
One way to achieve quality rather than spend endless time debating its more obscure qualities is to produce a definition that folks can support then work toward a common goal. One way to achieve a common goal (particularly when lagre numbers of people are involved) is a process... It seems to me that the real problem is that groups of people have to be brought to a finishing point where all agree that the requirements were satisfied and all are delighted with the results. I think that belief and method are closely related to this struggle.
Where I work I'm fairly lucky, the IS dept is one of the few areas that doesn't "strictly" enforce ISO 9001. (the word "strictly" is use very loosely)
...that is, give him the answer what we should be doing, not what we are doing. And the tend to steer the inspector away from the know problem areas.
We're one of those shops where we have 9001 certification only because it looks good on paper, not because we follow the methodologies of it.
It's kind of funny when the employee messages state that "the ISO inspector will be around today and any questions he asks should be answered using your ISO booklet"
It's a joke, but it allows us to put that neat little logo on our company letterhead...makes perfect sense to me....yeah right!
Sean D.
Wasn't it Dogbert who said ISO is german for "Is that my Beer?".
"Hmm. I am to metaphor cheese as metaphor cheese is to transitive verb crackers!"
Sure I believe in quality, that doesn't mean my work will magically be quality. That's why in our 'methodology' peers will review my work, including the paperwork that I've done to show WHY I did what I did.
In the open source "methodology" peers will review what I've done and use it if they like it, or reject it if they don't like it.
In the corporate world, my customers aren't interested in reading the source, they just want something to work. Therefore we have a formalized process of peer review.
In the corporate world I can't just 'release early, release often' and tell the customer that if it doesn't work the way they want it to, they should look at the code and change it themselves.
Methodologies are NOT a magic bullet, but if it is something that the developers can see value in it, it can improve the quality of your products.
A good development management process will develop quality at the lower. It sometimes is and should be just about improving the quality of the released product, not what is the latest management technobabble.
You can run a free-for-all when you have those programmers that are good, but there is the same distribution of talent in programming as there is in professional sports. Everyone can play basketball, very few make a living at it. Generally, the lame programmers don't work on open source projects.
If I sound bitter, its because I am about to spend the next four months re-configuring a huge production server in three hour chunks to correct the incompetence and stupidity of the past, AND do the job I get paid for, AND try to teach our developers how to write code that will actually work AND get them to actually test beyond the fact that it can compile.
Does having a clue about quality include reviewing your output to determine whether, for instance, you have accidentally substituted a "w" for an "f" in the word "filled"?
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
I view these management methodologies sort of like I view the toolbox that I keep in my garage - there are a lot of tools there, but for most projects I rarely need to use them all.
If your projects are always on time and within budget, then you may not need any of these tools. On the other hand, if your projects are sometimes late, over budget, out of resources, or out of control (in general) then some of these tools might be worth looking at.
Regarding implementation, the biggest barrier is peoples' resistance to change. Many people will recognize that there is a problem, but they are reluctant to support culture/process changes that require a change in what they themselves do. It's always someone else who has the problem. This is especially true with managers, who recognize that their sucess in the current paradigm may not transfer to a new one.
Even without reading the statement without malicious intent, I seem to recall 2 names from C bible; there are N+1 databases of which few were created by single person, web certainly wasn't created by just one man/woman (not even the browsers much less WWW itself). Linux in its current form hardly was created by Linux alone. List goes on.
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
Several years ago, I was a 2nd line manager in a major UNIX OS organization. Our teams were dissatisfied with the process of working across groups and productivity was low. Along came an ISO9000 "initiative" from above. Rather than grumble about it, we got a team of the top technical leaders as well as some entry people of the organization and let them define how to go about it. The end result: happier and more productive employees, *reduced* overtime and frustration (read....build breaks, breaking more things than fixing, etc...), less stress and gaming for "visibility" or "position", etc...
It's not easy, but it's been done and with benefit. Just have to make sure it does not turn into a beauracratic process, injecting more inefficiency than productivity, though they'll be bumps along the way.
Aide: Grant drinks too much to command an army. Lincoln: Find out what he drinks and give it to my other generals!
I'm probably just bitter, but in our case we ended up with a 40 page document on how you should use source control (which the auditors caught us failing to comply with). A 5 point check list would have been more in order.
How does one measure the progress of a program? Lines of code written? Hackers tend to use a more heuristic approach, giving estimates of what fraction of the original goals set forth in the spec are achieved. This is very unsettling to the kind of suits who like to see exactitudes, but 3 lines of code that do the Right Thing can be far more effective than 3000 lines of code that do not, and this effectiveness is much harder to measure than tolerances on the dimensions of a bearing or camshaft or bolt.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Methodologies are abstractions of experience; people did something once, got beat up, figured out what they did wrong, and came up with a method for future attempts.
Therefore methodologies can turn out to be the worst of all possible situations. They allow inexperienced people to imitate experienced ones. But when a problem arise for which the methodology is unsuited, the users' inexperience bites them in the ass doublefold, as the methodology will act as a screen to their understanding the real source of the problem. For that you need an experienced person, who doesn't rely on that methodology - which sort of goes against the point of having the method.
I see Linux as being a community of experienced users. This means that methodologies may be more useful for them than for non-Linux users, as they should in general be better able to do without them. It depends on your approach I guess. It also strikes me that Linux could dispense with "methodologies" of the sort described as the province of idiotic QA consultants, as the pool of experience would create a more organic approach to all problems in general, and make everyone less dependant on an abstracted form of experience.
My boss and I have an agreement:
It's my job to make him look good, to show that he is doing a good job as a manager.
His job is to further my career in any way that I see fit, because if I am not doing what I want to do, then I am no good anyways. I'm signed up for Foundry Networks training, Juniper training, and some software dev stuff that I want to do.
I get what I want, he gets what he wants, we both live happy.
"See, we plan ahead! That way, we never have to do anything now."
Take a bug tracking system, can you:
Say with certainty that if a bug has been reported than you can find the report?
Um, as a matter of fact, yes...
Know whether the bug has been fixed or not?
Actually, yep
Know who fixed it (or is supposedto) and when and what they did to fix it?
Yeppers
Say which versions contain the bugfix and which do not?
Damn, yes
If you can answer yes to each of those questions then your bug tracking system is fundamentally ISO9000 compliant.
Bugger - I always said I'd never go for that ISO9000 crap. Incidentally, we don't use paper in this process at all (OK, rarely, but then the online system refers to the paper "in hardcopy file).
Somebody once characterized psychotherapy as always excaberating whatever problem that it tried to fix. Management methodologies are like that. Say your company wants to solve a particular problem. If you determine that designing and building a good solution will take six months, but that a just-barely-adequate solution can be hammered out in two, Murphy's Law dictates that the user community will be willing to wait exactly seven weeks for a finished application. Because there are virtually no companies with the self-discipline to wait as long as it takes to produce good software, most software sucks. Management methodologies attempt to solve the problem of software sucking, but they do so by making further demands on the already limited time of the development staff AND their managers. Worse, the language that is used to present, for example, the Quality Improvement Process, is very soft and mushy. It tends not to play very well to an audience of technically-oriented employees. They will fight the implementation every step of the way. Having spewed out all of this criticism, however, I should also say that the professional techies of the world have done a singularly bad job of offering any alternative solutions. We've collectively come up with any number of design principles that are meant to enforce standards of quality on our software, but nobody follows those principles consistently. Show me a shop with five programmers and I'll find at least one person who never comments their code.
Never try to teach a pig to sing; it's a waste of your time and it irritates the pig.
All of the management techniques I have observed have boiled down to a high priced packaging of common sense - once all the buzz words are removed that is. Not to say that this is too much of a sham, as the problem with common sense is that it isnt that common, therefore it can be useful for getting some of the lesser drones pointing in the same direction.
All women want is honesty, if you can fake that, you're in.
Using ISO does not denote quality.
If you follow your procedures laid out for you then you can say 'Yes, I did it to spec'.
But where does it say that those have to be high quality procedures? I think people like to confuse quality with documentation. Decent documentation is important but I also think that herds of consultants would have you believe the mantra 'if you have ISO then you have quality.'
Cant really comment on the rest of the standards.
I think you underestimate just how much I just dont care.
A lot of these systems are about mesuring the progress on developing a system and thus provideing the information to enable management. This is generally not valued by the programmers at the sharp end as they see little benefit, just more form filling.
Oh, you said "IT methodologies". My bad.
That said, I don't disagree with the idea of trying to measure. If you can't measure, you don't know if you're meeting goals or not.
My distaste for management methodologies like those mentioned in the original article is that they often measure things that are not relevant to the work. Lines of code metric? Good, I'll be wordy and put no more than one statement per line. I'm not being more productive, but I'll look like it. It's sort of like that neural net that was trained to do a particular task. It turned out it learned very well how to optimize it's measured score, not the task that was supposedly measured.
Or in the rare case that the measurement is actually relevant, management does not allow the extra time to make the measurement. As others have said, documenting things takes time. But often management doesn't seem to realize that if they add an extra 20-30% more work to their developers, it won't make products ship faster. It won't even make them ship on time. It will slow them down.
OK, enough incoherent rambling for now, hopefully my next post will make more sense. Hey, it's early in the new year, I'm not awake yet.
To email, do the obvious.
Truer words were never written. You also said it makes more sense to generate short-term sucesses by sacrificing long-term sucess. Yup. If you measure short term success and reward based on that measurement, there is absolutely no incentive for anyone to ensure long term success.
To email, do the obvious.
In the past I always blamed bad management, bad resourcing, bad marketing for the failures I have seen in the IT industries where I've worked.
In all these cases (I've worked in 10 places I guess now, that's a reasonable size) my blame was 100% placed in the right direction. (And I wasn't tactful in my 'leaving interviews' either - I once told HR that unless they fire Brian the manager there souldn't be a softy left on the project in 6 months, and they didn't believe me (fools)).
Finally I've found a place where it's the softies are to blame. Huge project. 10 softies, none of which could program in the language of the project. By heck did they right shit code. It's the softies' faults. But who was to blame for hiring them, not training them, and not managing them properly. Alas the upper levels have got to take the blame too.
In all these places, methodology was irrelevant. Common sense would have been relevant. None was to be found.
This really is a -1, Flamebait, subject, isn't it?
FP.
-- Real Men Don't Use Porn. -- Morality In Media Billboards
Also FatPhil on SoylentNews, id 863
Blimey, I should spell-check, and proof-read.
s/souldn't/wouldn't/
s/right/write/
s/properly./properly?/
Sorry,
Phil
-- Real Men Don't Use Porn. -- Morality In Media Billboards
Also FatPhil on SoylentNews, id 863
And because IT career advancement requires job-hopping, managers and other employees will advocate new technologies for their resume-padding value rather than their real value to the company.
Agreed: I understand the importance of documentation/auditing/logging in an IT dept; the concepts are universal.
Whatever system is developed it is almost ALWAYS in place. IT people are more pragmatic than most, by their nature - and training. A good system to communitcate 'procedure' already exists before the average PHB decides one is needed... their in the audit logs, the system logs... everywhere. The IT industry knows the importance of this concept.
The most important thing to know is which methodology is best suited for which situation, and apply the one you think is most suitable for your own project/organization. Mindlessly worshipping at the altar of the latest management fad is a sure recipe for disaster.
Where are you from utopia?
IT Management is likely going to play a big role in the next year with all the now defunct companies that took a beating and made it to f*ckedcompany.com and it may be sort of a good thing.
What I see happening in certain instances are companies doing poorly in the long run due to bad management on all aspects of the business not only limited to the IT sector. With a proper foundation in place standards are kept and it becomes harder to become railroaded down the line when things are booming for a company. Once a certain criteria is established and standards are in order things in theory should only get better.
As for buying into some sort of consulting to do this, personally I think its a waste of money and management should be done from the inside since consultants in the long run will not have much to do with the company following their initial assessments, thereby leaving room for failure somewhere down the line.
Windows2000 Spoof
Thanks for the memories
I guarantee you that I can configure a UNIX box (or an NT box) that would put all of the information into the logs...and would still be impossible for someone to comprehend in a reasonable amount of time.
The ability to reverse-engineer something does not negate the need to have a documented and well-understood system.
When I ask someone how a particular feature in our product works, I do not want "read the code" as an answer, even though I am a developer on the same product.
However, computers do not operate the same way when either (a) poor admins, or (b) multiple admins work on the systems without proper procedure.
A formal procedure is necessary in any organization that wants reliable, reproducible results. The process may not need a 4-letter buzz-acronym thingy, but it needs to be something that everyone in your group knows, appreciates and follows .
You can be UNIX-god, or whatever, but the ultimate risk in any group (including IT departments) is Bus Risk: The risk of lost time and energy if someone key to your organization is hit by a Bus.
Learn to lower the Bus Risk. If things aren't documented and/or procedures not followed, then everything that someone does needs to be reverse-engineered if that Bus comes along. (Bus, of course, needn't be a big metallic object...it could be a head-hunter...or worse!)
The people who talk about quality as something that can be put into a process remind me of the Herman cartoon from years ago that showed a sign over a hen house that said "Think Grade A Large."
It might cost extra to you the individual, but a good approach to software engineering saves time and effort to the team and for that reason it is cost effective even in the short term for any activity that is more than one person to have a documented approach to this. On any but the most trivial of project, accurate communication of the requirements and the technical interfaces is what dominates costs (mainly in fixing misunderstandings during integration testing).
However, you have to be careful on methodologies. There is no silver bullet and you have to design the set of methods that you use to fit the circumstances. Inappropriate methodologies do do more harm than good.
I spent much of the 1980's trying to prevent our company from imposing such inappropriate methodologies on all development projects (we are a computer systems house and this is our bread and butter). Our approach these days is to build a [we call it] 'Quality Plan' from a set of predefined standard bricks (we try to envisage most environments and have developed over 30years a whole set of standards that are appropriate to each of the situations we encounter, we have ongoing feedback as new technology comes out to try and improve on these) - but with the option in any particular circumstance to include a customised version of any standard.
First quality needs to be endorsed from the top of the company to create a culture in which it is encouraged.
Secondly, there are other alternatives to firing people - training them (either through mentoring from the more senior people, or via formal training courses) can also sort out problems.
Thirdly, quality, as the book says cannot be chrome plated on the outside, but requires it to be built in to the low level of everyones activities. This requires everyone to take pride in what they do - and this in turn requires the organisation (and in particular the management) to recognise the value in everyone (well most people - there are always one or two that cannot or won't be redeemed:-) ).
Really? Then perhaps the problem is that the definition of "quality" as used in management sciences is flawed, or so limited in scope as to be inadequate when discussing the topic in the Real World. Or maybe it's because we've all seen stupid things done in the name of managementized quality and are thus reluctant to allow the very people who enacted such foolishness to define the terms by which their results are judged.
I find that so many of the management ideas are usually the most obvious. Redundant but true.
dinosaur comics
There seem to be two different sets of people writing posts on these topics:
The first set of people work for companies that have intentionally implemented standards for their work, be it CMM, ISO 9001, QS 9000, or any one of the numerous IEEE or ACM standards that are available to guide computer software development. To these people, these standards are just part of the background of everyday life, and are seen as necessary evils needed to get through the day.
The other set of people work for companies like mine: Anything goes. Sure we develop products, and sure we turn a profit, but could we do it next week, next month, or next year? No one really knows, because no one can describe how things get done.
Here is a personal example: We have some legacy software that needs modification. My list of questions are:
And on and on it goes.. All I am trying to illustrate is that these management techniques serve to standardize and regiment how things are done. Now, if you are a cowboy programmer, that probably upsets you. However, if you are in programming for the long hall, the rational application of selected management techniques is golden.
Sine Dubio, Nulli Secundus
Uhm, I'm not an expert in this field, but I'm going to guess that letting each individual in a team choose their own personal method of quality control is probably a recipe for inefficiency.
I can only speak from my own experience with Covey. Covey is the author of The Seven Habits of Hightly Effecive People. We have this stuff drilled into us from day one. The most Important: Be Proactive. While I think it's a good idea to fix things before they break, it is not always possible to when computers tend to crash. It is nearly impossible to foresee every possible problem. It's not a good idea to take a management theory for stockbrokers and try to apply it to IT. It's two completely different things.
Measurement is *not* the heart of science, the scientific method is. Most of these management methodologies are totally unscientific, or suited for an environment other than that in which they are employed.
Besides that (which is enough to render most methodogies irrelevant) what do you propose to measure? Lines of code? "Faults" or "Defects"? "Function Points", or something even less tangible?
I've been involved in several methodologies over the years, starting with TQM and lately a debacle involving CMM. Every single methodolgy promises every thing (zero defects, minimum time to market, guaranteed schedule and budget) to every one, except the developers who actually have to do the work. The key word in "management methodologies" is "management". Don't ignore that.
The problem isn't with the methodologies, their implementation, or even with the consultants or managment teams that propose them, although these are all easy targets. The issue in most organizations, as they relate to IT support, development, etc., is a general failure to recognize what it is the company is intending to do (read Mission), and then matching policy and process implementation to this overall goal. I've read in responses to this question that, "there are no silver bullets", "methodologies suck", and, "in organizations without methodologies, everyone goes about doing their own thing" (with some paraphrasing). No organization, development, IT, or otherwise, can operate in an efficient manner indefinitely without some means of process management. The wrong methodologies certainly do suck...for those forced to implement them as well as those expecting productive results from their implementation. The only "silver bullets" I've ever seen or heard about in any organization are those that have been carefully contrived with the overall business strategy, and more importantly, the business culture, in mind. Consultants aren't evil, they're just misused that way...
...too many people who are managing IT dept. have no concept of IT. With all the various acronyms floating about indicating each companies desire to be significant and different from the other it's hard to imagine these management types really being able to help at all. Sure, they might be able to manage people but who you hire a McDonald's manager to manage nuclear scientists? That may seem a bit extreme but consider a multi-billion dollar corporation depending on a manager whose sole management experience has nothing to do with tax accounting, lawyer firms and law, network management. But then those IT gurus who do the good job and get the newly created titles may also not know their IT from an MIT.
Bottom line is...management should know it's people, stop fucking your best workers, and learn to accept rejection over brown-nosing. It's simple. Screw the latest management technologies. I mean come on, technologies? WTF?!?!
... there is nothing that has not already been thought
Quality can be defined in a number of ways, from bugs per KLOC to errors per hour of operation.
Quality management systems, like CMM, are about establishing methods to measure the quality of code.
They are not about ensuring you create good code (that's normally a side effect), they're about making sure you know how good your are and what if anything you are doing wrong.
When properly implemented these systems allow you (and your manager) to prove beyond a shadow of a doubt that the guy in the next cubicle is an idiot. Once that's done, he can be replaced with someone slightly less clueless.
Fanatically anti-fanatical
magic bullets...
Ahh... the short term answer that's every manager's dream.
-- Hob - Java Spectrum Emulator
I've only found one 'management methodology' to be of any use, but this one makes up for all the rest: The Deming Management Method. This is not TQC (Total Quality Control) or TQM (Total Quality Management), although it is frequently confused with them, which sometimes gives it a bad reputation. However, Deming's methods, when implemented across the board without any management wishy-washy "we can't do that" cutting, work beautifully.
'Fraid I don't have time to go into detail today, but fortunately there's plenty of resources available: Several books, of which my favorite for the beginner is "Four Days With Dr. Deming : A Strategy for Modern Methods of Management (Engineering Process Improvement Series)", and websites, you can start with the W. Edwards Deming Institute Web Site. Also try Deming's Fourteen Points and his Seven Deadly Diseases. Don't be discouraged that you've seen some of these before in failed methods -- there've been many attempts to create a more management-palatable "Deming Lite", with disapointing results.
One last scrap: RE: STUDENT REQUEST: Deming's 14 points applied to a software engineering organisation.
Quotes from A Man for All Seasons
In my former job at a factory I was exposed to some of these "Management Methodologies" after we were bought out by a large organization. They claimed that these methods would lower waste and increase profits, but what they really did was hire about 20 new managers that made over $100,000 a year and bought cheaper materials. Even though the cheaper materials translated into a lower quality product, the new managers were hyping it as "the highest quality and best product on the market". The regular workers could see through this sham, and demanded to call a meeting with the management. Many things were said with the result of the management admitting loss of profits. What happened next was shocking... The managers, using something out of the "Lean Manufacturing" handbook, blamed the loss of profits not on the poor quality, but on employee waste. They started timing us and watching the workers all 9 hours of our shift, timing our bathroom breaks, and firing people for stuff like "conflict of interest". Shortly thereafter I quit.
It has been my experience while working in two IT organizations - each of which has contracted outside consultants from high profile organizations - that each consulting company has its own "methodology" that it tries to propogate, and regardless of the problem trying to be solved the consultants will shoe-horn it to make it fit the problems trying to be solved by the IT organization.
One would think that these consultants who are billing at $250+ per hour would study the problem domain of the IT organization and what the IT organization is trying to do, then evaluate the people and tools used by the IT organization, and then determine what should be done. Instead, these consultants and application architects come in the door knowing only one methodology - and this is the one that is being sold by their employer. These conultants are nothing more than defacto salespeople for their employers methodologies - and the solution to whatever problem the IT organization is having is to purchase the method and hire more conultants.
When I hired on at one of these IT companies, the consultants had been on sight for over a year and had billed over $6,000,000 in expenses, but there was no product or even code written ( to be fair, the db schema on the server was complete). The IT company scrapped the consultants and hired some experienced engineers ( which is how I came aboard ), and within four months, we produced for them release 1 of thier product. Within the next three months we released the next two phases of their product. In the end, we received huge bonuses because it was the quickest that the IT organization had ever rolled out a product, it experienced the least amount of problems once it was rolled out to customers.
"Microsoft has made computing accessible to a population who would otherwise not be able to use computers" - B. Kernigha
I find it quite strange that the same engineers who espouse the virtues of good implementation, software engineering, CS degrees and so forth one minute seem always to criticize such practices the next, particularly when they're suggested by the ever-evil management. Honestly, half of the previous post is mere ranting and, from where I'm standing, it seems that it's Sinsterian him/herself who is the more concerned with "power (Job Security). Without wishing to be too much of a language nazi, somebody making such horrendous grammatical and spelling errors isn't likely to be the best person to design or document a project in a meticulous manner. There's a vast arrogance amongst many hard-core coders who think they're the only people who have any true understanding of how a project should be designed, and that their methods are inherently superior to any more formal methodologies.
I once had the pleasure of holding a long conversation with a woman who led a team of testers on various fairly high-profile government projects. She made the point that most developers don't _want_ to document and test; they merely want to write code. She also made the point that this kind of attitude is death for any project of a significant size. The OSS movement seems at first glance to give the lie to this argument, but in reality a number of OSS projects are far more rigourously controlled and managed by their proprietary counterparts; because the individuals concerned generally have a very real desire for the success of their product, though, and because they're often very talented coders, things get done in a fairly decent way. Contrast this with designers/programmers who are the "only people who really know the code", and who (it would seem) have no interest in getting the code documented properly -- this is a disastrous situation.
I work as part of a small team of engineers, most of whom have no formal training. While I enjoy and appreciate the relatively relaxed nature of the development, my (admittedly rather lax) years at University studying a CS degree have led me to be a regular advocate of doing things in a more structured manner, especially as the size of our development team grows and project complexity grows.
As always, there's an obvious tradeoff between the demands of rigourous project management and getting code written quickly and in a decent atmosphere. The issue of how best to scale a project is one that is often addressed: for the small project, certainly, there's no need for elaborate management methodologies and indeed such practices would only detract from the success of the project. Anyone who has worked with a project on a long-term basis, though, will understand the need for a greater degree of control: individual liberties needs must be subsumed for the good of the project as a whole. The greatest danger for any project is the renegade coder who, talented as he might be, refuses to comply with accepted practices because he thinks his way is "better".
Introducing such methodologies is a whole other issue, of course, and I'm not experienced enough to pretend that I have any perfect answers. I would caution, though, against bracketing all consultants as inept, money-hungry vultures without true experience or knowledge. Such types exist, of course, but so do very knowledgeable, very intelligent consultants who can provide a unique, very valuable perspective -- and, indeed, third-party review is almost essential to any large project in which in-house developers may be too closely involved to see alternatives, problems, or incorrect assumptions made by their internal process. I'd argue that this factor is one of the chief benefits of the open source movement -- independent review is often carried out by many diverse people, each of whom may bring his or her own insights even if they're not directly involved in development.
So, think a little harder before knocking methodologies that you probably don't understand and that could probably do you a lot of good if you'd only spend the time in getting them right. You're not always the best person to judge how a project should progress, even (or perhaps especially) if it's something you've been involved in from the start.
However, while I agree with you about the difficulty that's to be found in finding competent managers, and in encouraging able programmers to move to management positions, I do think it's important to avoid the knee-jerk reaction that's so common on /. whereby the management is _always_ seen as inept and the coder _always_ considers himself The Law.
The recent Ask Slashdot on this issue highlights some of the problems to which you allude; as I commented in that discussion, though, too many programers seem(IMHO) to be satisfied with resting on their laurels and knocking the management.
Nonetheless, I don't mean to suggest that all consultants are brilliant (I've certainly worked with a few idiots); however, I think /. has a tendency to oversimplify and churn out trite arguments without considering that there might be greater considerations than the happiness of individual coders, who might just occasionally not be right about everything. And, with respect, I do think that Sinsterian makes too many of these oversimplifications: the Dilbert analogy is funny because it's true, but it's also often not true. As it were.
This makes things worse for those of us that do the work. We have to fix flawed documentation and code.
So the correct chain is:
1. someone who is well intentioned creates a methodology.
2. MBA or consultant screws it up.
3. Code monkey screws up implementation.
4. One of the few guys that does the work fixes it until he/she get pissed off and go somewhere else to do the same thing.
Also, I think we might work together. I've read Dilbert and I know I work with these guys. I think I will get all buff and become a male exotic dancer. At least that field is honest and pays well.
Women are the ruling class. Guys who don't like it should get a sex change. But I don't want to be a lesbian.
No, I wrote the article in a rush.
The paranoid, who cannot write decent documentation or do the things that should be done as they should be done will always cry foul: since you're unable to follow the processes of careful engineering, they [ we all make mistakes! ] must be a cynical method by which to protect one's own job.
I have no idea about what you are trying to say.
My point is that (poor work ethic + ass kissing) = the death of any project. Quality review is the essential element to the success of any project. If the organization has the gumption to kill bad work before it becomes entrenched, the code fumblers and ass kissers will fall by the wayside in order to protect business interests.
And for the record.... I have worked with some great consultants and managers. I have also seen a great many that could kill the best shops.
Women are the ruling class. Guys who don't like it should get a sex change. But I don't want to be a lesbian.
My point was that niether side of the issue is absolute. I did make the point that coders who document and design their project on their own are often more valuable than managers who blindly follow a "religious process".
Some of the biggest messes I have ever seen were made by "midnight coders" who whipped up non-manageable code. They were often valued for their productivity even though their code required constant patching. These were the quys who got things done.
What is needed is a sound thought process with out regard to personal desire or personal ego. Only when crap is called crap are both management and software guys doing themselves service.
I don't hate management. In fact, the manager I admired the most started off as an accountant. When he thought I was doing a crappy job, he walked up to me and told me why and how I should fix it. Unfortunately, the current trend seems to be toward blind productivity:
This is the wrong attitude and these methodologies prescribe the opposite but they are implemented too often in environments were "fix it later" has already taken its toll. How often have you seen a software shop toss out junk code to get things right?
It is a sociological problem rather than a management problem. One of the reasons Dilbert is such a clever commentary is that it comments on the sociological problems that have saddly grown common.
Peace.. and Happy New Years....
Women are the ruling class. Guys who don't like it should get a sex change. But I don't want to be a lesbian.
* obfuscating code in an attempt for job security
* software design on the fly that kills any chance of future enhancements and optimizations.
* any combination of the top two with worthless documentation to enhance job security.
* C++ code that uses classes in a way that is utterly insane. There are no damn interfaces and every thing is publicly accessable.
Management methodologies can help to combat this kind of thing but I have very often seen them create there own problems. For example, I have seen a "cmm 4 certified" shop rewrite/wrapper OS services to fix problems at the application level. Just throw the POS away and write it correctly. All to often, emphasis is placed on process and method rather than algorithm design, use of datastructures and eficiency. These are the things that aren't given decent metrics and are only discoverable by a well trained computer scientist or mathematician.
Personaly, I would hire a bunch of people that new there stuff CS wise and tried to document and design before I would take a "process" junky. A good size subgroup of MBA types care more about power (Job Security) than well thought out design. Time to market matters more than design. So a lot of extra people that have nothing to do with design are hired to document, the documents become worthless and the designers/programmers are still the only people who really know the code. But the manager doesn't care sinse more people equals more power.
OR TO SOME IT UP READ THE DILBERT BOOKS AND SEE WHAT THEY HAVE TO SAY ON MANAGEMENT AND BUSINESS PLANS. IT IS THE SAME DEAL!!!!
Women are the ruling class. Guys who don't like it should get a sex change. But I don't want to be a lesbian.
A lot of the management paradigms that you've mentioned are very solid concepts that have been successfully implemented in a large number of companies. So they can work.
/do/ work, but can require such a colossal change in the way that a company operates that corporate inertia will hold them back.
But a lot of the time (I would hazard a guess at most of the time!) they fail, or get sidelined. Why? Simple: Managers who don't understand, don't care, or are too keen to shirk their responsibilities. (Read: most of them)
Most of these quality-based operational philosophies require such a fundamental culture shift, that managers are unable, or unwilling, to cope. Especially if there is no commitment to the project to begin with. Sadly, there is no force greater than corporate inertia. ("But we've always done it this way!")
IME, employees stand to gain from these methodologies, since most of them incorporate elements of empowerment and reward. (See Silvestro's 6 precepts of TQM for a good hit-list)
Of course, when a director or some other senior mgmt figure dictates from on-high that this will be the new way of business, managers become disillusioned, and don't give the project the backing that it needs to gather employee commitment, so the whole thing falls flat, the managers blame the workers (and/or the consultants that were hired to oversee the project), and claim that everything was better off the way it was in the first place.
Short version: They
IMNSHO as a Mgmt student and consultant....
Unfortunately, so many of the people who get hung up on things like TQM don't really know what the hell they're talking about. You and I and you over there all know these guys/girls -- they have H/MBAs and shiny dispositions, they talk like their own damned marketing brochures, and it's mostly because they don't really have a clue what any of that buzzwordiness really means. In a way, the "management religion" is a little Scientological. Thought beyond the party line, they're told, leads to cognitive dissonance and death.
Incidentally, TQM and its clone-siblings has drawn a lot of well-deserved criticism from various sectors (not least in Brown and Duguid's _Social Life Of Information_...if you read only one book this year, read that one!). Based on my own personal observances (and nasty crawling feelings encountered when faced with Motivator posters & shiny, brainless Stepford marketroids), a lot of these theories (as with theories in many other "soft" -- and "hard" fields) are just a set of normalizing behaviour ("Well, if *I* do it, it *must* be normal!") and quite a lot of transferrence ("I am assertive -- you are brusque, and he's a pushy sonofabitch.").
NOT that I'm saying that policies, procedures and documentation (above all, documentation! It's just my job!) aren't important. But policies, procedures and documentation should be developed from what works for your company (more along the lines of the "best practices" or "knowledge collation" schools of thought), rather than by some imported consultant and/or the CEO's collection of Yuppie-fluppie self-help books for the corporatively inclined.
I'm not a geek, I'm just a clever script.
I'm not really familiar with a lot of those models mentioned in the original posting, but I am familiar with the CMM. It seems to me that the CMM is not followed but is attained by the methodology used to make the software process work correctly. Attaining the ability to plan a project and execute it in a reasonably repetitive fashion is not a bad thing. It still doesn't protect the project from idiots who claim to be programmers. (This particular guy is even totally baffled by source code control!)
Of course, these methodologies don't apply to open source since the whole cathedral vs. bazaar thing. The fact is that an IT consultant shouldn't be the one talking about software methodologies....it should be a computer scientist. Another fact is that idiot programmers are not the rouge programmers following their own star in their basement. Idiot programmers go to training classes for languages and expect a skill to be served to them on a plate after paying the price. A computer scientist is trained to make software happen and is often writing software for the pure joy of seeing the result. A person such as this could see who the project needs to be protected from and who should be babysat.
I also should probably mention that this guy goes into these wild rants when he gets slapped with a ton of problem reports about his software. It isn't uncommon for him to walk around the office claiming, "This IS NOT what I do!" He wrote the code, so I still am uncertain what exactly it is that he does since he seems to write the code, doesn't document it (because it "restricts freedom") and then doesn't think he should be expected to fix his own bugs. This is perfect example of an "idiot programmer."
If it wasnt for rogue programmers following their own star in their basement, there wouldnt be any software to speak of today and IT would be busing trays in the cafeteria.
You should be thankful to the corrupting effects of a company size/wealth and (large) teamwork on the individual creativity and motivation. Without these effects the little guy in the basement would never have a chance.
I've been at three jobs now, and three places were implementing these types of systems. Overall, it's a wonderful idea, it's supposed to make the workers happy, the management happy, the customer happy, you'll be dancing in the aisles and love to come to work, la la la la.
In reality, I find that these systems often become just another checkbox on the project timeline -- did we update the ISO docs to reflect this -- and just serves up another layer on top of management.
What many of these systems miss is that it is supposed to improve your processes, but they often get stuck documenting the poor management processes, which makes them hard to change. Of course, since these systems are supposed to do everything a company wants, they are the equivalent of clean water and clean air legislation -- no politician can go against a law called something like "the clean air and water purification act", even if it was chock full of harmful law. Same thing here when you try and explain why you don't want to participate in the ISO process. You'll find thousands of books explaining why the system is great, but probably none documenting that it becomes an expensive library system.
It does work well for manufacturing, however -- these very techniques were what led to the American car companies being handed their ass by the Japanese in the 80's. I'd have to believe that some aspects of the philosophy could be applied to software development, especially for a large project, to establish a framework to work within. However, I would let people within the company develop the program rather than hire a consultant who just came from the manufacturing plant down the road.
I think I agree. So let me throw another couple of gallons of 89-octane onto the hibachi...
I work as a consultant, advising clients on software development methodologies. The reason people pay me is because (a) I know how to develop software, having done lots of it; (b) I've managed development efforts, and (c) I've been successful doing both. I agree that hiring someone who hasn't written and delivered large amounts of code would be foolish. And I've seen clients who have done just that, with predictably disastrous results.
Here's why methodologies matter:
First, even among programmers, there's always the bell curve. Regardless of how well an organization works, there will be bozos, cowpersons, call 'em what you will. They can singlehandedly kill a project unless you do at least some crap detection.
Second, in a good-sized software project, with the usual unreasonable deadlines and flaky requirements, everyone will be under pressure and will occasionally do things they regret later. You may be brilliant at your best, but a little sleep deprivation and some well-timed interventions by the pointy-haired MBAs will quickly expose weak points you never knew you had. In short, typical conditions on software projects will force errors to occur. So you need a consistent way of doing things, to mitigate the impact of these inevitable screw-ups.
I've worked with some of those 100-times-more-productive-than-anyone-else programmers. At my best I've gotten close to that productivity myself (say, twenty times). People like that deserve, and get, special treatment. Write a waiver for them. Then there's the other 99 percent. Methodologies are for us mere mortals.
Incidentally, the best programmers I've seen are highly productive precisely because their code isn't shite. It's well-thought-out, does things in the simplest possible way, and has enough structure and even comments that someone else can find their way through it. It might not meet some moron's ideas of coding standards, but the objective is to have something that can be maintained by someone other than the genius who wrote it. NOT mindless adherence to a standard, whether it makes sense or not.
I tell our clients that standards and methodologies are a means to an end, not an end in themselves. In places where I've seen things get out of hand, it's because someone let the QA people, or some methodology fascist (often a failed programmer that they're too kind-hearted to fire), run rampant without adult supervision. The goal is to write code that works and is maintainable, not to have endless inspections that add no value.
To the extent that methodologies help you do this, they're a good thing. But to work, you need someone hardheaded to make sure that they're delivering the desired result. Otherwise it becomes a counter-productive paper chase.
Get your teeth into a small slice: the cake of liberty
the catch is - it must be married to your corporate management process, or everyone involved is spinning their wheels. The best example I've seen was at the Motorola plant in Fort Worth, from my pov (contractor) change was slow, and changes had to be approved by everyone in the world, but that was the way their entire operation worked, so (in that context) it was 'okay' - and it worked.
MrF
Display some adaptability.
N. Dean Meyer and Associates has some fascinating how-to books on . . process and management. They not only publish, but the contents are on-line. http://www.ndma.com/
I've read them all (aborted startup from last year) and it seems like a great approach - just great dollaps of common-sense.
Anyone? Hello?
MrF
Display some adaptability.
I was just given my first job of the year... "document our procedures!". But I'm not interested in an empire, it's taking me AWAY from work I find interesting,... and getting my code style enforced company-wide would be a Bad Thing ;)
Looking on the bright side, we don't actually HAVE any procedures. We just make it up as we go along. Yeah, we do web development, how did you guess?
--
If the good lord had meant me to live in Los Angeles
A better management method would let you add some of its practices to your current work-style, perhaps adding more over time, and perhaps gradually swapping your old practices for the new ones as the organization evolved. That is, the method should have fine-grained, pluggable, loosely-coupled practices.
The practices of Extreme Programming (which are partly to do with software design and partly to do with project management) are like this. For example, one could introduce story-based specification without initially using using the stories as the unit for estimating time and cost; story based estimation could come later. (A story in XP is like a use-case, but very informal.) And all the story-related practices are totally separate from the technical practices concerning testing, etc.
the navy was conceived by geniuses to be managed by imbeciles!
Yes, Dilbert said it all
In most organization I have worked in, IT is typically driven by the precieved crises of the day/moment. The idea of focusing on focusing on a goal that might take more then a week to complete seems to exception and not the norm. Most of these same organizations are focused on "share holder value." Yes as an employee you must bring value to the company but shouldn't you bring value to your customers? They are after all the people paying your bills.
Managment fads have some good points in them, but they are ultimatly only as good as the people in the organization that implemented them. By and large most large organizations tend to be very burecratic and very command and control oriented. These types of companies are not very good at listen to the layer of people below them. At a network intergration company I worked at, the ceo (and lackys) actually had some decent ideas but the middle tier of managment never bought into the ideas and thus the doomed the idea. Very few organization have executive leaders that motivate the organization as a whole to change direction or methodology. Cisco, Dell, Southwest Airlines and believe it or not Mircosoft seem to be the few organizations that have capable leaders.
If you had this revelation five years ago, and your name were Scott Adams, you'd be a millionaire! Welcome to the real world!
See you in hell,
Bill Fuckin' Gates®.
See you in hell,
Bill Fuckin' Gates®.
(This post is ©2001 Microsoft(TM) Corporation.)
Your project description reminds me of a quote from Dune: "If you give orders on a subject, you will always have to give orders on that subject." -- Duke Leto. I have found that if you have the right team, and they understand the mission, very little process is needed. Those are two big givens, and after 8 years in Military-Industrial complex, I know all about processes, and how to abuse and avoid them. Thank God for startups!
The strong do what they can, while the weak suffer what they must.
IMHO: As a nonprogramming member of an IT deparment. I take certain umbrage with your logic, and attitude.
First of all the leavemethehellalone attitude is why "nonIT" people are in the IT departments. If more IT professionals took the time to communicate with the operations side of a company, and not take the IT is better than (Insert any other department) attitude. This sort of oversight wouldn't be viewed as necessary by CEOs.
This arguement goes both ways. It is important for people from every part of a company to have at least a cursory understanding of what the other departments do including IT.
Fundamentally what is important is to be able to communicate among departments, and having "nonIT" people in IT and "IT" people in operations helps this.
The attitude of:
we can also read your email and disclose your interest in collecting lesbian-albino-midget p0rn... if not, we can frame you.
Is the exact attitude that requires "nonIT" the thing that you so passionately hate.
First of all, ANY consultant who dares to tell you one method is right for every situation is telling lies.
Second of all, anyone who tell you methodologies are a waste of time or money is telling lies.
Fird, people who tell you the managers/programmers/consultants/... are to blame for a failed implementation are telling lies.
A lot of people here on slashdot are coders. Not software engineers, just coders. They hack something together and hey, it works, or if it doesn't, they'll fix it until it works. No design, no documentation, no formal ways of working. This is okay when you are the only one who works on a piece of software. For a large project, this is a recipe for disaster (as somepeople on here have pointed out).
Some people on here are software engineers. They write code that people's lives depend on. I remember seeing an article here on /. about 6 months ago about the control software for the space shuttle. A bugless program. Programmed by people who use formal methods, good documentation and don't pull all-nighters fixing that last bug.I suggest some people here might read Code Complete and After the Goldrust, both by Steve McConnell.
When implementing a quality system or other method, keep in mind there are many different sakeholders. Management, programmers, the consultants etc. It is all these people who are responsible for a succesfull or failed implementation.
Final note to the persons who think ISO900X is about products... it is not. It is about processes, and in an even larger framework, it is about organisations. This is quite an abstract concept, and a lot of people will not grasp this concept. (On a side note: how many people here REALLY grasped Design Patterns?) That is okay, it is management's job to think in broad lines, to explain matters like these to the workers. If management fails, implementation is doomed.
Hiring any consultants with catchy scemes (management or not) is not good policy, you're much better off hiring the best people yourself (like Amazon did) and go in a new direction, not the one the consultants steer everyone.
Given a reasonably level playing field, who would win a fight between a bear and a shark?
Implementation is not the problem, some of the policies are just stupid. ISO - just documenting methods and materials as I understand it - is incredibly stupid even when done right.
Given a reasonably level playing field, who would win a fight between a bear and a shark?
The big problem as I see it is this. Somewhere along the merry primrose path of business this simple fact was lost. One should Manage "things" and lead "people." Too much today I see very little leadership and much displaced management. Hell, I even see books about "How to manage employees for dummies." Only a dummy would want to "manage" a person. Never did a great warrior follow a manager into battle. We follow Leaders or we are leaders. Just my 2 cents worth.
Better performance does not necessarily deem the answer as the best way to do things. Most IT pros are there through a very regimented form of training. Any thing straying from the norm in the IT profession causes serious lock-up in the minds of most of them. These are not the multi-tasked geniouses that are writing the goods, they are just the ones trying to tell you how to use what they learned about in books. More often than not in real app situations, which is where I appreciate most of my knowledge to come from.
Blinders On?
Check!
Windows Running?
Check
Free Thought Turned off?
Check
OK. Go!
.
Who are the real (potential) management experts in a company? I'd say the employees. The people who get the job done - who make the money for management are the employees. If management tries to manipulate their people, to force them into 'cleverly conceived' patterns of behaviour in order to increase productivity=$$$, I can only see limited results. Assuming employees are creative people who are willing to commit to get the job done, within their ranks are the answers to "management problems". (At least those which relate to the employees.) If management gathers their workers together to brainstorm solutions, problems could be resolved easily at the grassroots level - where the solutions really lie. After it's all said and done, management has nothing without their creative employees. If employees are smart enough to get the technical end of things done, they are smart enough to discover a better way to let this continue. This doesn't mean management doesn't have the responsibility to set up a useful matrix for their company to work within. Those who fill in the matrix, who give it form and function can best figure out how to reshape the company to get the job done better. (I'll stop rambling for now...)
You could learn from the best admin around, the B.O.F.H.. He always seems (Unlike some other ITs) to find the easiest way around!
rant { To start off I would like to say that making personal attacks is no way to begin a logical (or any kind) of argument. Everyone's (well maybe not that Gate's guy's) opinions are valid. There are ignorant consultants and ignorant programmers. } All management methodologies have a place in business. The one that fits a situation is the one that breeds creativity and positive attitudes. This is a hard goal to reach with a large number of people. At IDEO the management is very liberal: small randomized teams work on projects (under little supervision), no one gets fired...that sort of thing. Because it is a company made up of very well educated (and slightly eccentric) people with IT backgrounds, a nd it is in Silicon Valley, this methodology fits. At QED Consulting (I know it's a consulting place...bear with me!) has a moderatly liberal workplace, and because it is made up of well to moderatly educated Gen-Xers to Baby Boomers (about 15-20) this older style of management fits. I am not very well informed as to the variety of methodologies or their implementation, but success depends not only on the person who is in charge, but the type of people and the way the people work together. Pardon my lack of knowledge.
"ph34r my 1337 n3kk1d ski11z!" - largo of megatokyo
Agreed. To a certain extent, process can compensate for lack of talent. Free will certainly assumes/requires ability. With no exceptions.
We almost get into a chicken and egg discussion, though, because by allowing non-competent people easier access to success, we perpetuate the influx of people who think "oh yeah, that doesn't look to tough."
Of course, without them, we'd be doing so much drudgery everyday that we'd never have time for anything fun ourselves.
Incompentent people - you can really use them, but you can't fire them either.
Good luck, BTW. I just got done with a similar project. The end result was letting them wrap themselves in process until they turned blue. It seemed to be a self-feeding monster. The more process they created, the more they needed.
...that management methodologies are good, if properly implemented, but they are no substitute for good management. The other common theme is that poor management combined with poor morale will effectively kill any management methodology you'd care to try. What say you all? Does this sum it up?
All of this, of course, depends on what you mean by "cost". If a product kills someone doesn't it "cost" the person their life and shouldn't the company be responsible for that "cost"? Government regulation usually makes companies accountable for all the costs associated with production. From this perspective, standard practices and procedures reduce the cost of the product because paying off all of the lawsuits that would inevitably ensue from a poorly performing product is more expansive than the extra expense of following standard practices. The reason there are not more lawsuits in the software industry is that the software overall improves productivity. However, if lives depended on the software and it failed I'm sure the software maker would be sued. Don't get me wrong I'm not a fan of government regulation but it is not as simple an issue as your argument suggests.
I've had much the same thought about the "methodologies" I've been exposed to. They try to do it all and wind up being very expensive to follow. Maybe we need the project management equivalent of an LDAP -- X.500 tried to do it all regarding directory services, and wound up being difficult (impossible?) to fully implement. Along comes LDAP as X.500 Lite and it becomes widely adopted. I think that Microsoft's current fascination with methodologies (i.e., their Enterprise Services Framework, that's so big it has three (!) sub-frameworks within it) might be useful for Boeing. But small companies could really use a lite version.
And how they have pulled it off at ArsDigita (read it here). A must read, IMHO.
Very good points. The trouble is, the MM vendors are all pushing "one size fits all" methodologies. And in the case of ISO-9000, you even have European laws behind the full system. Our manufacturing plant goes under ISO-9002 (just the manufacturing and QA parts of it), and it's way too heavy of a paperwork load for three factories of about 500 employees each. Not that it isn't helpful in preventing many kinds of screwups and ensuring we keep records of how we built something last time so we can do it again, but we've got 50 people in middle-management type jobs who spend more time writing new procedures than executing them!
If that was applied to our tiny engineering section also, we wouldn't ever get anything done.
Managers are always doing some such silly stuff. Quality "training" and the like is real nice for getting a 'warm fuzzy' feeling that management has actually done something. In most cases that I have seen, training people who do not care results in money and time wasted. In IT, the needs of the company are often obscured by management who think IT is a department they can outsource. These types of managers are the same people who hold MBA's, yet do not have a business of THEIR OWN to practise upon. They grab a degree, and then think they are somehow 'better' because of the degree. IT functions can be simple or complex. Small business do not need Oracle or SAP, do not need large mainframes or the like. Training small business IT personnel can be a blessing or something else. It all depends upon the actual needs of a company. If most of the people in IT are simply software loading, password changing, wire wiggling tech types, why bother? Quality is determined rather quickly in such situations, it works or it doesn't. In larger businesses, the results are virtually identical, the system works, or it doesn't. All the training in 'quality' methodologies isn't worth spit unless the system(s) works. It must be noted that as mentioned in a previous post, many 'managers' are impressed by the level of 'training' the people in the shop have. Unfortunately, I know folks with all kinds of Certifications, and they are still clueless. I still have to help these "qualified" individuals out of simple mindless jams they find themselves in, on a daily basis. Quality is an atmosphere and excellence is an attitude. Training is no substitute.
I have worked with and without ISO amd believe me there was a hell of a difference.
I can compare my work at Ford and HP.
In one case (Ford) the project was working well, everything was documented, if I needed to know how to do something (start a big calculation on a Cray or convert from one file format to another), I could just pick up the procedure and the doc. So ok, you loose time doing all the paperwork but believe, on big projects, you soon see the big advantage of doing so...
By HP it was just chaotic, no doc (or outdated ones). No coordination between projects... The number of times our program was breaking down because of changes brought into the input file after a request from another department. Even in the same development team, things got ugly sometimes because there was no real coordination... Of course all these problems could have been avoided just by beeing clever and taking some precautions but programmers are lazy and don't like extra constraints. So ISO (and others) is there to force them to.
If there are more than one person working on the project, then yes, ISO (and other time consuming and ressource waiting procedures) are a necessity!!!
Black holes occur when God divides by zero.
Most of the TQM stuff is a waste of time in the most literal sense --- paperwork is generated for the purpose of satisfying an audit and is never again revisited nor used by anyone. As a freelance contractor, I've seen that too many times in too many companies for this to be a one-off aberration.
Here's a quick recipe for quality in the workplace: Responsibility and Traceability. Give people full responsibility over a complete part or aspect of the product, and ensure that you can trace back to the party responsible at every stage. And make the responsibility stick, all the way up to the ultimate sanction of financial penalty or loss of position or employment.
People will do a good job when they have full responsibility over something, unlike when they are made to feel like an anonymous cog in a big machine. Give them that (and the authority that has to go with it) and you'll get quality, with minimal paperwork.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Not true... from above they can fire the "bad quality" and hire the "good quality".
:-)
Sure, they can fire the bad quality, but how exactly are they going to hire the good quality?
See, it's not that simple. Resumes do not give managers any insight into the quality of a person as this is not the same thing as skill set, and even worse, if managers practice a hire-and-fire policy in a scatter-gun attempt at finding a good set of people then the better ones will start to leave because of bad team feeling. No, it's not that simple. Giving people motivation is a better approach.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
We did the TQM thing as a govt contractor about 10 years ago. Good way to burn up half a day for a couple of weeks, was a change of pace if anything. In the end, we bench techs still did things as we did before because we didn't control the procedures anyway. If anybody actually DID want to alter a 'procedure' to improve the quality of our output (in this case 'work' was 90% attention to paperwork to document the 10% actual work done) it would've taken going over heads, pissing folks off, filling out forms 99-TQ/120-X in triplicate, a congressional appropriation, and in general being such a pain to everyone involved that the payoffs didn't warrant the effort.
In short, mgmt procedures just limit my freedom to innovate! See the movie 'Brazil'.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Quality Assurance is a process that makes the difference between M$'s security holes and a secure system.
Quality Assurance is a process that let you pick up a system and shake all the bugs out.
Quality Assurance is a process for building systems st that you maintain a knowledge base to identify ALL components of a system, ALL objects, ALL methods, ALL relationships, ALL functionality and completely cross-reference eveny meme in teh knowledge base.
Quality Assurance lets you deliver a system to your clients and live with it afterwards.
That said, most corporate QA efforts are poorly implemplemented and lacadaisically enforced retrofits. QA at start-ups are lousy and the products can't evolve and don't outlast the creation team.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
How often have you been asked to do something stupid to preserve an unrealistic schedule? Did it help (rhetorical question)?
Well-implemented methdologies can control management by making them follow the same rules the programmers do. Management and business owner expectations are based on defined processes and nobody entertains the notion that the project can be started without a spec and a plan.
Poorly implemented methodologies are used to control programmers while managers continue to do their counter-productive thing. If that is the case then the wrong people are being controlled and the methodology will not do any good.
Don't throw the baby out with the bathwater - methodologies can be very worthwhile if they are implemented well and followed consistently.
Not true... from above they can fire the "bad quality" and hire the "good quality".
These methodologies are the management equivalent of profiling and debugging for programmers. When you write code, you want to know how well it is performing, where the slow parts are, etc. Management methodologies are exactly this. Process management is a science, and it has rigorous steps. A good manager will understand these methodologies, so they can focus on the intent of them and leverage trusted techniques. Of course, a manager who has only had a 2 week course in various methodologies is likely to mess them up-- just like an inexperienced programmer who has been told "use this profiler" and has never seen such a tool before. -m
The problem isn't with the various methodologies. Rather, the problem is with the implementation of these methodologies. Just like anything else in the work environment, you can force your employees to learn these practices, but if they don't actually follow them then of course the results will be poor. The root of the problem is generally something much greater than the programming methodology though; plain poor upper-management comes to mind. If you look at software shops that people do respect(i.e. IBM, NASA, etc.), you'll find that these practices do work but they work because these organizations already have a good infratructure in place. These shops also realize that these practices aren't magic bullets unlike some of the smaller shops. Sorry for the rambling.
Sources of Power: How People Make Decisions, Alan Klein, MIT Press.
This is not a book about IT methodologies, but it it gets to the heart of the problem I have with most management and system analytic methodolgies -- they are based on a flawed model of how human beings handle information and make decisions.
The standard cognitive model, whether explicitly held or not, that underpins most "methodologies" I have seen is "rationalistic decision making". This model goes something like so (more or less from memory):
(1) Define the problem.
(2) Generate options.
(3) Create framework of metrics for evaluating options.
(4) Apply metrics to options and compare.
(5) Select optimal approach.
While this methodology does occur in the wild, if you will, it turns out that it occurs exclusively among decision makers who are novices in the problem domain. Field studies show (contrary to expectations) that expert decision makers almost never work this way, and case studies show that in complex environments with many unknown factors, changing goals, and time restrictions, attempts to apply this model are unsatisfactory.
In the real world, highly expert decision makers work something like this (this is simplified and reconstructed from memory):
(1) Evaluate situation
(2) Take the first approach that comes to mind.
(3) Mentally reherse approach. If problems refine or go to 2.
(4) Execute plan and evaluate as you go. If things are not going as expected go back to 1 or 2.
The key word here is "satisficing" -- instead of searching for optimal approaches, the expert goes with the first approach that comes to mind, mentally rehearses it, executes it, and possibly reevaluates the goals. This is sometimes called Naturalistic Decision Making or NDM.
Peole use both kinds of approaches, but NDM works better than RDM in many situations. First, there is the problem of where the good options come from in the first place. NDM plays to human cognitive strengths (imagination and role playing) and avoids human weaknesses (keeping two or more things in mind at once). It fits the real world scenario where the decision making process must be non-linear -- goals may shift during execution as new data is received. Example: the fire department goes into a burning building with the plan to get above the fire and contain it, but then discovers the blaze is larger and shifts to search and rescue then keeping the fire from spreading to nearby buildings. Finally, NDM results in faster execution than RDM; this fits Peter Drucker's criterion for management excellence -- a "bias for action". In NDM you get right into planning action, and if you can't make it work (mentally or in execution) you abandon the approach and build a better one.
I think the NDM/RDM dichotomy underlies a lot of problems between geeks and managers. RDM is an academic model, and geeks, whatever there relationship to their schools and teachers, are incredibly adept at absorbing this kind of stuff. Secondly, RDM is hard precisely in ways that geeks excel over the general population -- abstraction, numerical manipulation, handling large amounts of analytical data.
In any case, this book crystalized the problem I have with IT and analytic methodologies in general, which is that they assume a problem of optimization rather than one of quick and satisfactory execution. It also explains why people again and again invent methodologies that work for them but subsequently fail to be the "answer" (although in general I think we are getting a little smarter). The missing ingredient is the experience and common sense of the successful team's members.
I think the implication of this is that IT activity should be based on developing flexible and repurposeable systems, rather than optimally solving a single goal or a bounded set of goals. I've been out of the IT world for six or seven years, but the impression I get is that the major trends in IT have been towards repurposing of data and away from complex schemes to solve bounded problem sets.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
OK this is a little OT, but here goes.
What you don't need are bureacratic methodologies. If you spend your whole time writing documentation, drawing diagrams, tracking your time and other morale destroying tasks then the methodology sucks.
Well, writing documentation, drawing diagrams, and tracking time aren't demoralizing in themselves. It's doing work that, on one hand, has no value to the company, and on the other hand can be used as a stick to beat you that is demoralizing.
I've been unfortunate to have had a high enough position that I got to participate in the sadistic excercise called "mission statement preparation". In fact, one company that I worked for was so enamored of this everybody got to spend some time in flip chart hell, because every department and work group needs to have its own "mission".
In my opinion there should be a simple social contract between higher levels and lower levels in an organization: the higher up provides leadership and the lower down provides expertise. This is a position of parity, with each party providing and receiving something valuable and which makes accountability, in both directions, a possibility. The problem is when the management abdicate the leadership role (which they are probably not up to) to a committee with a flip chart.
Speaking as a dyed in the wool left leaning liberal large D Democrat, I have to say that managers who share my political stripe are the worst offenders. On the face of it, it is all sooo egalitarian -- except that it's not. It's more a fig leaf for higher ups evading their responsiblity to do meaningful work for the company. The big cheese still gets all of his whims catered to, and is free to ignore and interpret the mission any way he pleases. Sometimes it smacks of being in a communist reeducation camp.
Getting back to methodologies, if you are cast adrift with no leadership or idea of what needs to be accomplished, no methodology is going to save you.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
We call it CYA.
Producing a libraries's worth of unusable documentation just because it fulfils a line of a checklist is not quality, only the shadow thereof.
No, I think anyone with a real CS background understands the need for the procedure. We just want procedures that help, rather than hinder, quality results. Faddish "IT" methodologies (indeed, pretty much anything with "IT" in the name) are based on a poor understanding of quality and creativity.Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
I once saw a large crate outside the building where I were that said "WASTE MANAGEMENT SERVICES".
I thought to myself... "Waste Management... perhaps I should give these guys a call."
-=-
"Everything you know is wrong. (And stupid.)"
Moderation Totals: Wrong=2, Stupid=3, Total=5.
You're damned right about the "government mandate" on ISO - here in Australia it's the same. In some cases you cannot even tender for work if you're not ISO certified (or, perhaps, just "certified" in general :)
:)
:)
It always used to crack me up that they wanted ISO certification for quality assurance but ISO-9000 never addressed quality! It ensured that you had a process and that it was monitored, but it never did anything to improve quality. You could have a process producing a large number of defects but, if it was documented & repeatable, it could get certified.
At least they've recently addressed this with an update to include quality. Pity it was never there to begin with
As to vendors pushing their way as a "one size fits all" - funny that. Vendors are always doing that with whatever is in vogue (BPR, TQM, CMM, ISO, CRM, ERP - whatever
I left my body to science, but I'm afraid they've turned it down...
There's a lot of "Methodologies are great" vs "Methodologies suck" view points out there (mostly the latter here on /. :) As has been noted in previous posts under this thread, most of the problems relate to people seeking a "Silver Bullet" solution and mindlessly applying a methodology that worked elsewhere in the inane hope that it will work here. This is similar to checking out your competition and determining that they are better than you because all their people have blonde hair, blue eyes and use brand new shiny PC's.
:) and now moved into the Analyst / Project Manager / CEO world, I'm fighting all the time against PHB's who want to just drop methodologies into development teams and walk away. I've implemented existing methodologies, I've consulted on fixing the mess from a failed implementation (not one of my own, thanks :) and I've even hacked together some methodologies for a few clients.
t -here).
I recently heard the following phrase:
"You can lead a person to a methodology but you cannot make them think!"
Unfortunately, this is all too true. I've even encountered one group who probably couldn't get Extreme Programming right!
Having come from the programmer world (yes, I was a serious code-cowboy - I've still got the spurs to proove it
The secret is to think when assessing each situation. In some situations, I throw the book away and put together a bare-bones, absolute minimum repeatable process for a small development team. This lets them put some level of control & prediction into their work while still staying loose, having fun, focusing on the important stuff and keeping the primadonnas happy. In other situations, I pull out the CMM/ISO/(insert-heaveyweight-methodology-here), start tailoring it and introducing it slowly.
It all depends on the environment, the team and the goals. If you want to do is ensure that there's a modicum of control and that programmers aren't being dragged about from target to target, go with a light-weight system. If you are developing "life-threatening" systems such as nuclear reactors or air traffic control, damn straight you do it by the numbers with full control, reviews, checkpoints and such.
In all cases, you must continue to think. Too often someone sees a methodology as a burger-flipping process (eg: plug in some staff, follow the steps and out comes a golden solution). This is complete crap and a sure-fire disaster. At all times you have to ensure everyone in the team (from top to bottom) is turned on, tuned in and thinking. If anyone tunes out and believes they can just follow the steps without thinking for themselves, fire their ass!
Many programmers say methodologies get in the way and stop them working. I say that a good methodology (eg: one that's right for the team, the task(s) and the goal(s)) will let the programmer work in heaven (eg: little to no interruptions, focussed direction, constructive reviews and awareness of the big picture).
Like anything else, methodologies do work when they're used as yet one more tool in the hands of turned on, thinking people. Like anything else, if you just drop it in and hope it works, you're a fuckwit/dickhead/(insert-national-phrase-for-idio
I left my body to science, but I'm afraid they've turned it down...
why don't you try reading the book (online version). if you are interested in what he is talking about.
---
DO NOT DISTURB THE SE
That's not to say that some process isn't a good thing, and unless your team of programmers is absolutely excellent, that process will have to be mandated from above. Without some order, your project will slip into chaos, and I've seen that happen firsthand. But process is only one part of a much larger whole, and many companies on the bandwagon treat it as if it's everything.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Here are some examples. Note that it's not just the competency of management that counts, but also the organizational structure that makes quality a priority. All too often quality just gets lip service, rather than full-scale support. Part of that, of course, could the scale of the IS department. Smaller groups don't necessarily have the resources to implement a true QA process. I was part of an IS shop that grew from 5 to 40 programmers over the course of a few years, and the need for a systematic methodology went up just as quickly as the number of programmers did...
Stop by my site where I write about ERP systems & more
Smaller projects can't handle the overhead. With eight or 10 people you can't spend time on non-critical activities and documentation. Communication within the team is easy so you don't need the support.
However, almost all teams need some kind of roadmap. Having a documented process improves your chances of success because you now have a "checklist" of activities. In my experience, projects fail not becase of insufficient skill but because things don't get done. Process documentation helps ensure that things get done, and get done correctly. I like to think of them as design patters for project success.
Neutron
I get my kicks above the
I've worked with numerous managers and project managers. The greatest blessing a developer can get is the support of a *good* manager. Good, experienced managers don't need methologies any more than a good programmer needs flow charts.
A lousy manager, OTOH is a danger to any project as well as your own sanity.
The best way to work with an inexperienced manager is to follow some methology . Most of them merely states the obvious, and serves as a check list.
Sure it is a pain in the behind to use precious time for paperwork, instead of "real" work. But believe me. The pain that comes from a manager who *should* have used a methology, but played by ear instead is worse.
And if it goes really bad. The best way to show your CEO that the reason the project went sour was your clueless manager, not you is to be able to refer to some buzzword-filled methology, not "1 4M 1337 H4x0r, M4n463M3N7 5uX"
All opinions are my own - until criticized
Hear, hear!
I was one of the lucky and very rare people who got onto a project where TQ was: (1) taught, (2) implemented, and (3) given the time and support required for success.
Even in my own organization, nearly everyone got #1 and #2, but #3 was neglected. With us (some kind of radical fluke situation, I'm now convinced), we saw all the wonderful performance gains and productivity increases that TQ promised. We also saw the initial drop in productivity while we got into the method. It was during that time that every other project I'm familiar with got shut down. Some of these methodologies do work.
Ultimately, my conclusion was that various methods work when they are committed to and given time to work. They "get everybody on the same page." Oftentimes, they provide a common frame of reference and language for describing problems that make achieving goals easy once everyone knows the language and uses it religiously! Getting to that point, though, takes time. And time is what most IT shops just don't have.
These systems exist for many of the same reasons we have our jargon. By adopting a common language, we can communicate quickly with our peers. That's valuable. How would you like to be forced to explain every programming problem in language my completely non-technical mother could understand? It could be done, but it wouldn't be worth the effort. These methodologies accomplish the same thing with management problems as our tech jargon gives us with tech problems - they give everyone a common language and base of understanding on which successful communication can be built.
But half-assed implementations are doomed to failure. And nearly everything gets done half-assed these days. :-(
I belong to a company which believes in ISO 9001 and CMM. It is one of the big Indian shops with most of its offshore centers certified under both these management / quality methods. I've personally been involved with both these activities for a long time as a Project Leader and later as a Project Manager, and I found that there are both good and bad aspects of these certifications. The methods are extermely useful in a large (or very large, say 20,000 people) company, with a high turnover rate at it is in this industry. Unless you have properly planned or written down things methodically, you're going to die when your key designer leaves the job. In big projects (with 50 - 100 people), this planning is essential. And these management methods enforce that planning and documentation. And if you are a big organization, this also enforces code and concept reuse. This really increases productivity, which I can personally vouch for. So that is the reason the management wants to implement these methods. However, there is a trap in this. If not properly implemented, this can cause severe problems. People may stop being productive or may leave. But on a whole, I found this to a useful thing. You can compare it with a knife - it is quite useful, but if wrongly used, can cause mayhem.
Through all the companies I've been in, in several departments and several positions, I've consistantly seen one thing that would improve things dramatically: Accountability. The consistant and regular application of accountability to anything you do as part of that company, weather you're a grunt or a VP. If you're a QA tech, say, and you sign off that, say, the COM loading interface of your product works, and it ships, and it turns out not to work, in trivial and stupid ways, then you should be held accountable. Even if it's just a weekly 'wall of shame' intranet site for your co-workers to look at, fine. Similarly, if a VP makes an obviously stupid decision, ignoring the advise of everybody who knows better, when the shit hits the fan, it should be made known. Conversely, success reports need to go out on a regular and consistant basis. Carrot and stick.
Vintage computer games and RPG books available. Email me if you're interested.
I hate the term.... People cannot be "managed" (with the implication being that you are forcing them to do something they would not otherwise do). They can be led....inspired...motivated.... At least if you want long term, productive teams this is the case. Funny thought, coming from a CTO that supposedly has many "management" responsibilities. One poster has it right....management is the panacea for those that are too afraid to show some leadership and trust in their team members.
Chaeron Corporation
If you are a middle manager, you success might be measured in a plain costs vs revenues scale. This method, however, lacks any strategic depth - for such a manager, specialy given the current job mobility, it makes more sense to generate short-term sucesses by sacrificing long-term sucess (for example, by burning out your best programmers to finish some project in an impossible deadline).
Also any type of investment that will hit the bottom line but only yield results on the medium/long-term will not be made.
Oops - time's up - gotta go!!!
No methodology is a substitute for your manager using his ears and brain together (at the same time - yes it can be done!:)
Methodologies are a toolkit. It's all about using the right tools at the right time. Use too many and you're going to irritate the entire team as well as waste time. The real skill (and yes it is a skill) lies in knowing how to balance this.
Methodologies are not a religion. Adhering blindly to any doctrine rarely makes sense, unless your project has come completely off the rails and it needs some discipline to bring it back in to shape. I've seen this happen and the managers who really know what they're doing can really make it work.
Methodologies are common language. If you understand the Prince 2 terminology for example, anyone conversant in it will be able to interpret project documentation quite easily. Often it's a problem if two or more organisations working on the same project all use different terminology.
If your organisation has invested in a methodology, chances are it's been looking for ways to improve how it does things. This is good, as long as enough people buy in to the process. It's also vital that it is sustained by those involved. Often it requires a iron leader to enforce this. At my previous employer, the Year 2000 program manager was hard on the team about following the processes, but in the end it all came together and all of the projects were successful.
Yes, procedure is often the enemy of creativity. It's all about achieving the right balance between the two and if you're pissed at procedures perhaps your boss has got the mix wrong.
Rob.
But as you said, there arent enough hours in the day to do all the exta stuff. It costs extra to do this work, especially in the same time the work can be done with out it.
Perhaps, but adhering to good standards and writing clear and concise code should be drummed into trainee programmers until it becomes second nature. Then maintenance of old code becomes less of a trial because it has been written properly. Code reviews should be done fairly regularly for new coders to ensure that they are doing the work correctly. This saves a fortune in the short-to-medium term, never mind the long-term, as anyone coming to modify this code doesn't have to spend loads of time figuring out an appalling hack. When IT people realise this, our job will become a great deal easier.
Plan your work and work your plan.
The most conscise statement of project management I have ever seen is codified in the Jaycees' "Chairman's Planning Guide (CPG)".
The sections of this form to be filled out are:
Planning
Implementation and Evaluation
All methodolgies are just elaborations of the above.
Don't knock "PHB's" too hard - if you're ever worth your weight in salt, one day you'll be one.
There are a hell of a lot of nonprogrammers out there with good ideas, some of which you wouldn't come across your self unless you had their perspective. Don't knock it, use it - incorporate the good ideas wherever you find them, regardless of the background of the person offering them.
That's not the same as "getting some Quality" which is what all these Quality systems imply.
Management often think they can just buy "Quality" and invest in these systems. However, you can't just buy "Quality", you have to *believe* in it. You can spend as many millions as you like on consultants and quality systems but that doesn't mean that you have a better business or better products.
Government of the people, by corporate executives, for corporate profits.
Quality does *not* start at the top of the heirarchy, what utter crap.
Quality is up to the individual. Either the individuals concerned *believe* in doing high quality work or they don't give a shit. If they don't care then there isn't a quality system in the world which will make a difference.
Government of the people, by corporate executives, for corporate profits.
'Quality' cannot be enforced from above. It's that simple.
So, saying we need to get some Quality is stupid and the people (management) who think that they can get some 'Quality' are stupid.
Government of the people, by corporate executives, for corporate profits.
I agree that it is reasonable for management to expect good quality work from employees but you can't buy Quality.
The problems is that most management think that they can simply buy one of these quality systems, hire a few consultants and they magically have "Quality".
Not the case and simply trying to get quality by implementing a quality system will not give you a quality business, quality management or quality products.
Quality is a belief, *not* a methodology.
Government of the people, by corporate executives, for corporate profits.
Science requires definition. You go and define what quality is before you try to measure it.
Until you can define for me what quality is and how to measure it, don't try to tell me that Quality systems measure quality.
Government of the people, by corporate executives, for corporate profits.
If the company you work in have such methodologies and documentation crap, just tell them that you don't like it and that it's not in your best interest to work in such a company. Trust me it's not a good idea to waste your time working at that kind of job.
That's what I did and they listened.
As with real diets, any real effort to develop a Management Methodology, whether adopted from the outside or developed internally, will have a positive effect. What won't work are fads and half-assed implementation. The latter explains most of the failures in Management Methodology. For the most part, poor managers start to look at these Methodologies to explain failures not prevent them.
This is not the way to build a lasting empire.
The most effective methodology that I've seen in IT, and I've worked for companies of a hundred or so and for a few that are over ten thousand, is to keep teams small, and to build those teams of people who work together well and get things done. It's easier to teach someone the required skills than to teach them to cooperate happily. And when someone isn't working out, don't give second chances. Give them the axe when the trouble starts. If that policy is presented clearly and up front, there are no surprises when the axe falls.
Much of the inefficiency in companies today, regarding IT or otherwise, is because of tip-toeing around petty office personality problems or silly ego pandering. Trying to keep people happy takes time and energy that should go into getting the work done. Surround yourself with people who get things done and without hassle, send the rest packing.
- Sig this!
A full implementation of ISO 9000 would be ridiculous for our 6 member office. However, some ideas from ISO are helpful. For example, ISO requires version controlled documentation for every business procedure. We wouldn't have any business procedures if we tried to do this for everything since most of the stuff we do is constantly changing in response to changing technology.
However, there are a small number of less frequent and less high tech activities such as shipping UPS packages to clients that benefit from documentation. It saves running around asking where the various supplies, price charts, etc are.
My observation is that most Management Methodologies are designed for large corporations. Small businesses can benefit by applying principles from the large scale version to create a tailored "Lite" version. Unfortunately, such "Lite" versions do not get you a certificate. (Or maybe that's not so unfortunate :-) Furthermore, small businesses cannot afford the consultant based implementation approach.
In conclusion, vendors of methodologies are missing a large market. Small businesses need streamlined, "Lite" versions which do not require an expensive consultant. There should be certification programs designed for these requirements.
I lived through years of being force fed TQL, the US Navy's version of Deming's Total Quality Management. Although Deming had a lot of good points, I couldn't help but feel that we (as an organization) got entirely too wrapped around the axle with the methodology and lost track of the objectives.
A fundamental point of Deming involves understanding the process being managed, knowing the components of the process, measuring the inputs to the process and thereby knowing what you can expect as a result of the process. The key point to all of this that seems to escape many people is the idea that you're actually supposed to know what you're doing.
Umm, you seem to have forgotten something. The IT department is not there to give a warm home to a horde of unwashed nerds with no social skills. It's there to support a business. That's it - if it wasn't for the business, there would be no IT. End of story. If you aren't supporting the business, you aren't doing your job, no matter how many MP3's on your hard drive or how many times you've recompiled your kernel.
If the MBA says you're doing something wrong in your shell scripts, ignore him/her. If the same person says you aren't giving the business the support it needs, then shut the hell up and pay attention, you might learn something.
Honestly, I'm sick of geeks thinking that knowing how to program is the only skill that matters. What would the world be like if railroad track layers thought they knew better than anyone where the trains should stop?
I read an interesting article on software methodology on Martin Fowler's site (www.martinfowler.com). In this article he discusses light weight development methods and compares a few existing methods.
Basically his arguments boil down to this:
Traditional, so called heavy weight methods, are bad for creativity because they drown developers in a sea of bureaucratic documents.
No method is not good either, because in larger development teams anarchy leads nowhere.
Any method should be based on good assumptions. One of these assumptions should be that development and creativity of developers is inherently unpredictable. Therefore there is no point in building a requirement specification because by the time you have implemented, the requirements will have changed. The so called lightweight methods fowler suggests, are all iterative methods. They involve a lot of testing and frequent milestones.
The methods he discusses all follow this pattern. He even mentions open source and mozilla as examples of light weight development methods.
Jilles
The problem with most methodologies is the people who apply it. There is an old joke: "What's the difference between a methodologist and a terrorist? -- you can negotiate with the terrorist."
A methodology must be flexible. In the projects I work on, my company is spending millions of dollars on outsourced mega-applications. One of our big management issues is vendor management. I've got to say, that some of them are dicy, but in the air transportation industry, there aren't many vendors to choose from.
The Space Shuttle programming team, has one of the most rigorous methodolgies in the world. They also have one of the lowest defect rates in the world.. Coincidence? I don't think so.
This is a boring sig
I have often considered writing a book with my subject line title. I have seen shops with no standards to shops with "standards" so ridged you can't get a report change done in 3 months. The only approach that I have seen work is hiring competent people that can work directly with the clients. This allows management to stay out of the way and let the coders do their job unhindered. All the other schemes I have seen simply slowed the process down without providing the promised benefits.
When you place tight controls on your technical staff. What I have observed is, they still make the mistakes, but it takes a really long time to move them into production. This translates into no quality increases and performance decreases. Doh! I bet if you checked an IT shops performance statistics before and after these controls are put in place. They would prove this point.
Bottom line is, let the programmers do what you pay them for and don't design methodologies for the lowest common denominator.
--Scott
--Scott 8-}
Vintage computer games and RPG books available. Email me if you're interested.
Why do people complain? Because there are often not enough hours in the day to take care of the details required by these methodologies, and to get the "other" work done. Many folks would rather "get on" with the coding (or whatever) rather than take care of procedural chores. This is the wrong attitude. The procedural chores are part of the work. CS people seem to be the only folks who don't recognize this.
Would you want the biotech labs or pharmaceutical companies to "get on" with their work while ignoring procedural safeguards? How would you like the ironworkers erecting a skyscraper to "practice their art" while ignoring the directives of engineering inspectors?
The IT methodologies put the science back into "CS".
It seems we have a few MBA-cum-IT professionals here at /. And you will all have to excuse me because I am in shock at how proto-typical my workplace is in this regard. Alot of you will believe I want a 'glass house' to 'protect my job' - that is flatly untrue and way off base... anyway..
I work at one of the Big Three(Two/Five/whatever) Auto Companies. We presently have 2 major 'initiatives' to 'transform the company into the leading provider of quality automotive products and services'. Every week our Big-PHB (CEO Jack Nasser) sends an email and the tagline is "Customer Focused and Shareholder Driven, Jack Nasser". This same joker has decided that the entire company must impalement a few things:
1) FPS or Ford Production System; an all massive project requiring all aspects of every function of every job in the company to be detailed, described, documented, proven, repeated, audited (etc (like your standard ISO schtuff)). Every job must be accompanied by visual aids and 'error-proofing' techniques. Also, the 'enterprise pyramid' is to be inverted where the 'orders come from the bottom' (bottom being rank&file labour). and much much more...
2) FTPM or Ford Total Preventative Maintenance - a system that uses the above, and other techniques to predict machine failure and try and act pro-actively. (isn't this what 'qualified tradespeople' already do?)
What is the point of telling you all this? Well, firstly this method's are mandatory for all facilities to employ be they manufacturing, accounting or IT. I would like to know what any of this mess has to do with running an IT dept? When you try and run an IT dept like a widget manufacturing plant you will soon find that they are not the same. When some bone-head MBA decides that an IT dept needs to deploy these systems he may be right- but probably not... I understand the importance of documentation/auditing/logging in an IT dept; the concepts are universal.
When the dust clears from all this crap there will be a few likely outcomes:
A) this asshole will be out of a job because it will be discovered that his 1/2 dozen projects (6 sigma, FTPM, FPS etc etc) are all bullocks.
B) Some other asshole with his 1/2 dozen idiot schemes will have convinced the self-preserving toadies (just below the last asshole CEO) that he will "transform the company" into "insert your asshole tagline here about irrelevant crap"
C) ANY economic downturn will shut all this crap-spending down.
D) People will be loosing jobs now that they have all been braking their backs showing everyone how to do their job (meaning: "Look Bob does this this and this. Lets fire Bob, give 'this' to Steve, 'this' to Mary and forget 'this'... Muhaha saved another $75k for the 'shareholders'")
E) IT depts. everywhere will be forced to shift gears and make progress in this new set of 'corporate transformation strategies'
Bottom Line? Attention MBA's: Leave the IT depts alone! We know what the fuck we are doing, YOU DO NOT, if you did, youd be a member of the IT DEPT. Computer Systems have a basic 'trueness' about them that defy your 'underlying principles of operation' - they operate the same in whatever company is employing them. Be that a shoe manufacturer, insurance business, widget painter or ?????. We do not care what you are talking about in your email, we do not care what data we shuffle, we do not care what crap you stuff in your office documents or what the data in our RDBs 'means'. Its all really just chars and ints (ultimately just bits) and its doesnt matter what it says... so listen up Mr. MBA: Leave us the hell alone - IT people can see through your nonsense, can hear the desperate lies in your office meetings, the fear of being found out for the shill you are is written all over your face... we can also read your email and disclose your interest in collecting lesbian-albino-midget p0rn... if not, we can frame you. If you want to spend money on something to improve the IT dept? Drop all this crap, provide better wages, more staff, more training, more Co-ops and clerks this all serves to give us more TIME. Remember: its all just chars and ints - and you dont really understand....
I dont advocate chaos in IT depts where everyone does as they please -- that is untrue... anyone OUTSIDE of the IT world may think without these "paradigm shifting dynamics" that this is what happens - that is not the case - people INSIDE the IT industry know that systems have a way of telling US what to do, what is the proper way to maintain them, what is the proper way to code programs, write maint scripts for them et al.... oddly it all comes very naturally. Please don't interfere with our quest for Nirdvana.
"Total Quality Management" has thus far been an excuse for managers to reoganize everything into micromanaged environments while claiming to empower employees. It's Dilberting of the highest order.
ISO9000 on the other hand, turned out to be, while not stellar, a dramatic improvement to workflow around a different company. Aside form the fact that we needed ISO compliance in manufacturing in order to sell our products to certain european governments, it finally forced a lot of the "Fast-and-loose" policies to be codified. Suddenly we had to document what we were doing - everyone, from the manufacturers to the sysadmins to the developers to the product support people. Often tedious, yes, but it ended up helping a lot - all the code had documentation, system changes were recorded, etc. While most of our IT staff had done this anyway, we finally were able to convince the management-types that 1) we needed a decent repository for this sort of data and that they too were responsible as well for knowing what was going on.
Possibly the best side effect is that managment suddenly realized that they'd lose their ISO certification if the ISO document storage systems went down, so they became very interested in uptime and redundancy - approving the requests for redundant systems that they'd shot down for expense reasons many times before.
The weirdest part of quality systems is that in the end, they're just codifications of common sense. Document your changes. Keep records of your processes. Centralize your enterprise-level information. Stuff that every IT person would consider a no-brainer, but stuff that your average marketing droid would've never had any exposure to.
----
----
"I used to listen to Null Device before they sold out."
One thing that is painfully clear after spending a short time in the land of Dilbertesque cubicle landscapes is that acronyms encapsulating total management methodologies are the bane of the clueless, talentless bore. Analyze the situation and use common sense and good wisdom to architect an individual solution for the particular peopleset and project needs? Nah. I'm using SuperSilverBullet-ECST-9 2001! Five times the productivity in half the time....or so the consultant says.
Speaking of that what you're talking about here is consultants trying to push themselves into every organization for nice big fat paycheques. ISO 900x is a hilarious set of standards that basically come down to : Document and be consistent. GENIUS! Yet there are millions of consultants on this planet making billions of dollars to go in and say "Document and be consistent. Here's a word template that would take a normal man about 3 minutes to make. That'll be $125,000 please."
What this reminds me of are software development "methodologies" that could be summed up as this : Lots of idiotic, no talent Visual Basic programmers feel contempt for their more talented coworkers so they propose and push and fight for a lowest common denominator sort of system that removes the benefits of being talented. You carefully crafted an algorithm that solves XYZ? So what did you preceed it with a completely useless blobbogram and 1,500 pages of documentation? If not then gosh you're a dangerous man! I mean how can your code be any good if some code-monkey who should be in the field of burger flipping but lucked into a programming course can't understand it?
In my experience, the "Mangement Methodology Obession" began in the 80's and unfortunately stayed with us to this day.
The basic idea of looking for ways to improve results, measure results, make rational changes, and plan ahead is great. I'm all for it. I'm one of those people that, in general, feels people do not think or plan far enough ahead.
The problem is everyone began looking for a magical solution. This methodology doesn't work? Try this one! Everyone was looking for the Magical Productivity Bullet of Total Quality, to the point where they didn't even give the methods they were trying a chance to work.
There are good ideas out there - but they're being used as crutches, quick fixes, and outright scams. There are plenty of lousy fad ideas out there as well, and thanks to all the obscufation, it's hard to tell them apart.
I distrust any new "method" unless people can show it's worked and worked elsewhere and explain WHY it worked. Usually good solid planning, review, and testing will do the job just fine.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
99.5% of management methodologies are marketing booshwah for consultant's services. The other 0.5% can make a huge positive impact in the effectiveness of a company.
Simply implementing Deming's 6 points would revolutionize the way most companies work - for these points prosletyze respect for the individual. Proper use of these ideas results in a corporate culture where each worker contributes to and takes pride in the result of his work. There is no more powerful way of improving the health of a company.
The result is merely implementation detail that is the easy part. The hard part is putting the 6 principles into action.
The problem is that too many workers (and middle managers) have been through the management fad of the month; TQM, Re-engineering, etc. and have felt the effort was wasted. It's really sad to see the baby get thrown out with the bathwater.
It's already been mentioned that the alternative to methodologies is letting everyone do their own thing. I'd like to point out that this is the same fear people tend to have about Open Source. "How are you ever going to manage people who each have independence of thought and action?"
The real problem underlying suspicions about Open Source and working with a lack of prescribed methodologies is an inherent lack of trust by the management for the people doing the work. This could come from an underlying knowledge that, as corporate managers, they typically have no real value added themselves. They know that their jobs are inherently deceitful at some level, and therefore project that world view onto other people. People without purpose must be managed.
But guess what? Even in a methodology, you're only going to achieve anything at all by the willing cooperation of the managed. You have no choice but to trust them, even though you may put structures in place to hide that fact from yourself. Take away the methodologies, and you have to look the fact straight in the face: you can't make it happen without them, but they sure as hell can make it happen without you.
God save the Queen^H^H^H^H^Hmanagement!
I haven't encountered any purely management methodologies. But I have come across, and used, several development methodologies. Every single dev meth has had a lot to say about the management of a project (some more than others).
Development methodologies are superb. If you can get everyone in the team in agreement on a methodology, then you can create software quicker and better. These has been shown academically, in the workplace, and in my own experience.
What you don't need are bureacratic methodologies. If you spend your whole time writing documentation, drawing diagrams, tracking your time and other morale destroying tasks then the methodology sucks.
If you spend all your time writing high quality, self documenting code with repeatable tests - that pass - then your methodology is good, although I suspect you're lying about the 'all' your time bit
Personally I prefer iterative methodologies (DSDM, FDD, XP) and my current project is using Extreme Programming in anger (for the first time - it's scary). XP does tackle a lot of management issues - not least of which is, "What does the manager do?" question. It points out where traditional project management tasks are handled by the methodology and where managers can add value. It deals with measuring and tracking project progress, and using those measurements to determine future project progress (thus allowing better estimation and hitting release dates). It also covers testing, including unit tests and functional/acceptance tests.
So even those I would describe it as a development methodology, it is also to a large degree a management methodology, and more importantly can greatly add value to your team.
So methodologies are essential in any business type development. What you call them isn't important, but having them, and making them easy to understand and easy to use, is.
Of course, if you have political managers (i.e. they're in the game for their own benefit, trying to promote themselves all the time, not working together or for the company) then any methodology could run into problems. So pick decent places to work where people are motivated and committed (which doesn't mean 70 hour weeks - you can be committed and go home at 5pm every day - especially if you use a good methodology to control your projects).
In the open source world something like XP could be hell to implement. Something like DSDM probably goes out the window too - how do you prioritise requirements when people send in the code that meets the requirement at the same time as they send in the requirement. But successful open source projects have their own methodology too - they have mechanisms for reporting bugs, they have source control, they usually have a single person (or committee - but either way, a single point of responsibility) for determining what goes into the next release. How much of this constitutes management I leave to the Slashdot audience; that it is a methodology (however primitive) I will state with certainty.
~Cederic
ISO9000 done correctly is usefull, done badly it is worthless. Far too many managers think that ISO9000 is all about labeling things and having lots of documents - it is nothing of the sort.
Take a bug tracking system, can you:
Say with certainty that if a bug has been reported than you can find the report?
Know whether the bug has been fixed or not?
Know who fixed it (or is supposedto) and when and what they did to fix it?
Say which versions contain the bugfix and which do not?
If you can answer yes to each of those questions then your bug tracking system is fundamentally ISO9000 compliant.
Imagine that you are developing some software, do you know:
What is to be implemented?
Who is supposed to be implementing each feature?
What the design is?
What changes each person has made?
If you can answer yes to each, then your development is fundamantally ISO9000 compliant.
Quality has become a management fad, but at its heart, it isn't. It is about being organised, taking pride in your work and having a professional attitude.
If you build a system, is it a black hole that your sucessor will curse you for or is it well documented and well run, something your sucessor will thank you for.
ISO9000 tries to codify a professional attitude. If you have done chemistry, you will be familiar with the report format, Title, Aim, Introduction, Materials, Method, Results, Interpretation, Conclusion. It is simple, but it ensures that you say all you need to say and don't waffle. The idea is that you should be able to give the report to another chemist and they should be able to follow what you did, why you did it and be able to replicate the experiment without any surprises. The same holds true for other quality methdologies, your documentation should answer all the questions that a skilled professional might have.
ISO9000 as it was intended is very good, but ISO9000 as management fad is as bad as any other management fad.