Do You Buy Into Management Methodologies In IT? 230
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."
Re:Quality Consultants = oxymoron (Score:1)
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.
Unmaintainable code rules! (Score:1)
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.
Re:Yo yo yo! (Score:1)
Re:Yo yo yo! (Score:1)
process management failures (Score:1)
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 :)
They are to help your customers buy from you (Score:1)
"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.
ISO 6 Baldridge (Score:1)
Resist this trend in the software business. It hasn't worked in the hardware business except to line consultant's pockets.
I work at a management consulting company and ... (Score:1)
We do not buy! (Score:1)
Management Methodologies (Score:1)
Several good management methodologies do exist. In Europe ITIL (Systems management) [ccta.gov.uk] and Prince2 (Project Management) [ccta.gov.uk], both developed by the CCTA [ccta.gov.uk] have a large user basis. Learning these is very useful, since both are used in a large number of organisations.
Top down versus bottom up.... (Score:1)
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.
Orinoco's Rules of IT Management (Score:1)
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.
Re:measurement is the heart of science (Score:1)
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.
OT: Posts with Monospaced Fonts (Score:1)
Re:www.leavemethehellalone.com (Score:1)
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 [themestream.com].
Re:Responsibility and Traceability (Score:1)
- 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 [amazon.com] in an attempt to get better insight in how to manage / integrate with this on a daily level.
Re:measurement is the heart of science (Score:1)
Re:measurement is the heart of science (Score:1)
Re:www.leavemethehellalone.com (Score:1)
One simple test. (Score:1)
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.
How funny (Score:1)
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!".
Re:Responsibility and Traceability (Score:1)
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."
Re:Management Methodologies (Score:1)
WRONG!
ISO 900x certification is proof that you documented your activities and were consistant.
The Right Way To Do Things... (Score:1)
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.
Professionalism (Score:1)
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.
About Everyone Doing His Own Thing (Score:1)
Re:measurement is the heart of science (Score:1)
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
Re:Zen and the art of motorcycle maintenance. (Score:1)
Re:Bullshit (Score:1)
Lip service (Score:1)
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.
The Social Life of Information (Score:1)
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.
Back To Basics (Score:1)
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.
Re:Book Recommendation (Score:1)
Re:Quality Consultants = oxymoron (Score:1)
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.
Re:Quality is not a science. (Score:1)
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 [amazon.com] and Lila [amazon.com].
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.
IT methodologies (Score:2)
Re:Quality Consultants = oxymoron (Score:2)
The moral hazard of trying to idiot-proof the universe is to encourage the proliferation of idiots.
Yes, I do buy it... (Score:2)
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!!!
Responsibility and Traceability (Score:2)
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.
Hire-and-fire does not work (Score:2)
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.
Busy Work (Score:2)
In short, mgmt procedures just limit my freedom to innovate! See the movie 'Brazil'.
Quality Assurance's essential. Implementation suck (Score:2)
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.
Methodologies Control Managers (Score:2)
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.
Re:Zen and the art of motorcycle maintenance. (Score:2)
Exactly! (Score:2)
Blame the true source. (Score:2)
Book Recommendation (Score:2)
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.
Flip Chart Hell (Score:2)
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.
Of course we use Methodologies (Score:2)
Re:measurement is the heart of science (Score:2)
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/
Re:IT methodologies (Score:2)
The cause lies in industrial capitalism: how can a person feel ownership and responsibility for the outcome of their work when they are not owners and the work process is designed to make them an easily-replacable cog in a machine? What pride can one take in work that is so narrowly circumscribed?
Taken to the extreme, software process is an attempt to bring the assembly-line attitude to the development of code; and it will result in the same apathy about quality.
Tom Swiss | the infamous tms | http://www.infamous.net/
Re:Implementation is not the problem. (Score:2)
My management opinions... (Score:2)
I thought to myself... "Waste Management... perhaps I should give these guys a call."
-=-
Re:The Problem Is People Who Don't Want to Think (Score:2)
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
The Problem Is People Who Don't Want to Think (Score:2)
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
Re:Quality is a belief, *not* a methodology. (Score:2)
---
The Progammer's Stone Covers this Well (Score:2)
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.
Sure enough... (Score:2)
Useful in large projects (Score:2)
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
Re:Just ask dogbert. (Score:2)
Whilst tortured syntax and archaic word forms may be popular amongst those whom you are acquainted with, they don't make you sound smarter to someone who knows the languague.
I don't mean to belittle you so much as to make a point that it's not nice to criticize, and incidentally, that the real problem with IT management is that people not qualified to judge the quality of a job should not be doing so.
And now that I've warmed up to a cold topic, allow me expand on the incidental:
You make a good point about knocking methodologies that you probably don't understand and it is true that many programmers don't fully understand the needs of management to measure, direct, and document their work; but the greater imbalance is that management, more than ever, understands less about the work they presume to direct. In order to improve the quality of programming (or construction, or medicine) you must understand the process. The problem people have with management solutions is that they are getting furhter from solving the problem and more towards satisfying management for managements sake (job security.)
Managers who take classes in management are not qualified to judge the quality of computer programmers (steel workers, etc.) If you want management to lead effectively, they must be competent in the field they work in. It is pretty easy for an experienced programmer to tell if someone is serving them shit in a job interview or checks in sloppy code.
Now, not all experienced programmers are willing to stop doing what they love to manage. And God knows they aren't all able. And of course, there is the shortage of experienced programmers. But the truth is, they aren't encouraged to. Management hires from within. That is, managers hire MBAs over experienced programmers for management positions. And they contract with Management Consultants, rather than listen to their programmers.
Methology is not for the wizards... (Score:2)
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"
Re:Too often a crutch not a solution (Score:2)
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. :-(
Re:ISO9000 (Score:2)
Here's the easiest metho you'll ever need (Score:2)
Management is an oxymoron... (Score:2)
Re:Quality Consultants = oxymoron (Score:2)
Good methodologies are designed to protect the project from idiots of all types. These include idiot users, idiot customers, idiot programmers, idiot designers and, most importantly, idiot managers. Some of them are (in my experience in production software environments) more successful than others.
Short term sucess (Score:2)
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!!!
Re:Implementation is not the problem. (Score:2)
Before you know it you don't have your current procedures documented, you have something far more complex, but then you have to follow it to conform. This is then followed by tears and recriminations.
use the toolkit (Score:2)
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.
Re:measurement is the heart of science (Score:2)
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.
All Methodologies boil down to this.... (Score:2)
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.
Geeks Uber Alles? Hardly. (Score:2)
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.
Hiring good and firing bad != good quality (Score:2)
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.
Bullshit (Score:2)
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.
Zen and the art of motorcycle maintenance. (Score:2)
So, saying we need to get some Quality is stupid and the people (management) who think that they can get some 'Quality' are stupid.
Quality is a belief, *not* a methodology. (Score:2)
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.
Quality is not a science. (Score:2)
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.
My suggestion (Score:2)
That's what I did and they listened.
A Perfect System Run by Imperfect People . . . (Score:2)
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.
Keep it Simlpe (Score:2)
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.
ISO Lite (Score:2)
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.
Management Methods (Score:2)
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.
Re:www.leavemethehellalone.com (Score:3)
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?
Re:Management Methodologies (Score:3)
Exactly! Letting everyone do their own thing works if everyone is competent and even compentency is not enough. See here [albany.edu]
I am a lowly programmer like everyone else but I have talked to CIO's and they know the best programmers can be 10 or 100 times or more productive than the worst programmer on staff. But the CIO does not care because if the gifted programmer creates a killer product if that product( I use product as internal program used by companies since most programs fall under this domain.) may only be maintained by that programmer, not the lowest common denominator. That killer product is actually worthless. Why? Because if only person who may be able to maintain the program is the creator and this person is such a great programmer, then their time should be spent developing on new projects, not maintenance. The CIO is most interested in everyone following a similar set of rules and standards with minimal diversion from the standard (but deviation can be ok but there is a limit which is left to discretion).
If everyone follows the same rules and standards, what are the rules? That is where CMM and the others come into play. Instead of creating another standard, follow the work someone has already done. More likely, the following will happen: Take the best pieces of each standard and water them down so the common folk can understand them. KISS is the key.
martin fowler (Score:3)
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.
A methodology is only as good those who apply it (Score:3)
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.
Why corporate IT fails in America. (Score:3)
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
Re:management or development methodologies? (Score:3)
measurement is the heart of science (Score:3)
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".
www.leavemethehellalone.com (Score:3)
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.
It's not all bad, but usually is (Score:3)
"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.
----
Re:Quality Consultants = oxymoron (Score:3)
I think that the whole article deserves a big -1 Flamebait. Your comment, however, has valid points.
I think that the major problems with IT management are as follows: /sarcasm. When machine code can't be generated, the SE has specified the object or procedure so much that it there is not much room or reason to be creative when developing the code.
Bad Managers -- Let's face it, as the IT field grows older, the management styles will evolve until it grows better. New things ideas and methods are already being tested (Some very successfully, e.g. Donna Shirley's Mar's Global Surveyor [managingcreativity.com]). Eventually the bad managers will be weeded out, or at least we will have the definition of a 'good manager'. I don't think that the standard MBA program is capable of producing good IT managers, but MBA programs are changing. Math depts. around the USA are starting Industrial Mathematics Master's degree programs that provide a 'Technical' degree similar to a MBA (intense business classes combined with intense mathematics/programming).
Expensive Labor -- Face it, large companies would rather have software generate code than have programmers write it. The kill the good programmer, as AC puts it, because they want to pay less for programmers. I work for a large government contractor, and the 'Systems Engineer' approach is to use expensive packages to layout OCDs and OODs and then the packages generate code to be used in run-time systems. This effectively eliminates the programmer all together, with the exception of someone to go in and fix all of the machine generated code. Every programmer finds it fun to deal with machine generated code
Finally, I don't claim to be an expert on IT management. I find it an interesting area to learn about and I welcome all comments from people who disagree with me. I do recommend Donna Shirley's book, however.
Management Methodologies (Score:3)
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?
Too often a crutch not a solution (Score:4)
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.
Management Methodologies (Score:4)
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.
Re:Zen and the art of motorcycle maintenance. (Score:4)
You know, every hacker should read "Zen and the Art of Motorcycle Maintenance" [skynet.ul.ie].
Tom Swiss | the infamous tms | http://www.infamous.net/
Re:measurement is the heart of science (Score:4)
Forget the idea that science, good technology, or the right thing runs the world. Economics do. The almighty buck runs the show. Short sighted places will cut corners to make money, and long sighted ones will too, but to a lesser degree.
As things stand right now, Pharmaceutical companies and iron workers are forced to do what they do by rules and regulations imposed by the government, and a history of law suits, etc that were levied against the industries when they were younger and didnt play by the rules they do now. They wouldn't do it unless forced. It costs extra, alot extra, and unless everyone on the market place is forced to do the same thing, those that pay the extra amount to institute those safeguards are penalized by reduced market effectiveness, loss of competitive edge, and loss of profits. They are forced to charge more than their competitors, as they have to do much more work.
Asking companies to tie one hand behind their back in the fight for profits is ludicrious, and wont happen with out software development being turned into a regulated thing, like construction or the medical industry.
And while I cant say that this would be a bad thing, nor will I say its a good thing. You might not like it when the next version of office you buy costs 10K.
If companies got sued, fined, and otherwise penalized for not doing good work, they would be forced to do good work. but they aren't. They make things that are the least amount of work to get the job done, because that is the cheapest point they can shoot for. If every time Netscape crashed they got sued for breach of contract, there would be much more incentive for the company to try to do good work. As it is, there is really no significant results from doing bad work, as long as you pass a certain point of quality and dont turn away too many customers.
Unfortunately, neither good science, good technologies, nor good intentions rules the world. Economics is why good ideas dont go anywhere, and why mediocre ones excel.
-sbos
Problem is lack of trust (Score:4)
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!
management or development methodologies? (Score:5)
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 (Score:5)
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.