Programming with
a dose of satire.
Lifecycle
|
| ||||||||
 |
 |
|||||||
|
Lifecycle |
||||||||||||
|
Processes and the Bad Manager By Meryl K. Evans What is the big deal with processes? Why spend the time and resources documenting the "how" when we can just do it and not under the control of a set of rules?
Let's take a look at how Big Bad Manager handles his shop without processes. - Throw new employees to the wolves - Big Bad Manager Big Baddie's counterpart put a training program in place for new employees. Not only did the training cover the company's basic background, but also the way the software configuration management worked, file naming details, check-in and check-out procedures, and any other significant processes that impact the programmer especially in interacting with other teams.
Big Bad Manager implements another brilliant strategy and that is to add more staff whenever the project grows. After all, the more people on the project, the faster things get done. Reality is adding more employees to a late project only makes it later because of economics. Economics is not a favorite word in an IT department, but it's a simple law of supply and demand. A client's demands will always increase to match your supply of programmers. - Take Credit Big Baddie figures as long as he gives something to the customer, he's doing his job. It doesn't matter if it is late and buggy, he provides results. Hey, there are no metrics in place so how can they find out if the product is good or bad? The process calls for the client to do acceptance testing when receiving the final product. Baddie figures the client can find the bugs for him instead of spending valuable dollars on a quality assurance shop. After all, why mess with testing if the customer does it? Any problems they identify can become part of the next version.
Goody-two-shoes Manager implemented a peer review process, reward programs, and a quality metrics system. Programmers are motivated to produce bug-free code and review one another's work to ensure the team's metrics improved and earn a team bonus plus a day at the go-cart track. Big Baddie gets his overworked programmers to fix all the bugs, but it takes too long and the company loses customers. In the end, no one looks good. Programmer John and his co-workers again devote extra hours to fix bugs. More overtime means using computers, office and building resources plus double pay, all of which cost money. Tired of overtime, a programmer quits and Big Baddie has to search for a replacement, which again costs bucks. The later in the project life cycle when someone finds a bug, the more it costs to fix it. If you follow a cookbook recipe and miss a step, it will take more money and time to go back to fulfill that step. If the cake is cooked, then the baker has to start all over again. - Dreams of Superpowers
Big Baddie dislikes processes because they prevent heroic efforts. He prefers to stick with ad hoc and chaotic processes so he can be the hero and save the day. The team runs into a configuration control problem (or lack thereof) and Big Baddie sends his programmers to deal with the problem. After an all-nighter, the new version is in, but a piece of code is from the previous version. Sure, he manages to get the code loaded into production, but it's of poor quality due to the mismatched code. Our good guy manager in white has a documented process for configuration control. All of his developers and analysts know their roles in safely getting the code into production. - Time for Plumbing
Just gently coax B.B. Manager and explain that going forward, the department will document all interactions between teams and the work done by each employee. Documentation is always a good place to start. Ask yourself:
When you answer each question, you gain another step toward creating a process. Another starting place is THE REQUIREMENTS. They rule! They are what make the project. They should be traceable to all future documents: high-level design, systems requirements, and testing. Oh, and another thing. Create a process for requirement changes. If you skip that, you'll be in an endless loop and the product will never make it to production. Come on and join the plumber corps.
About The Author: Meryl has been hanging out on the Internet since 1993, 1800s in digital years. She cut her first process tooth in the USA government and continued to grow more process teeth in the telecommunications / IT industry. Ms. Meryl-like-Meryl-Streep is the [pick one] prez, CEO, CIO, CFO, UFO, and founder of meryl.net, writing, Web designing, editing, and all that extra stuff services. Her articles manage to sneak into the Dallas Morning News, Geek.com, A List Apart, ibizhome.com, Webreview, Webreference, and PalmPower. Go ahead and bug her - meryl at onramp dot net.
Elsewhere - Related Sites and Things: Article about Software Engineering The Tale of Three Project Managers: A Cautionary Tale
Talkback - Have Your Say: Message Index:
The Messages: Why Do Bad Managers Keeping Hiring More ProgrammersYou say itīs economics, and that work will expand to fit the size of the job corps... and thatīs true, but I think the real key problem with adding more programmers as the job gets further behind is INTEGRATION COSTS. The more people on the team, the more time must be devoted to communication to keep people informed of how othersī work impacts their own. There is definitely a point at which adding another programmer actually makes the project as a whole take LONGER to finish. Also, constant enforced overtime makes people stupid. Yes, of course, there will OCCASIONALLY be a need for overtime at the very end of the project even with a good manager, but the IT industry is rife with frequent or always overtime. In my experience, if it is not just a one-weekend oddity, but a months-long death march worth of overtime, work slows down in general over all the hours of work because people are just not as sharp when they are not well-rested. So they make more mistakes. Nor are they as creative. And letīs not even go into whether people do more personal-type stuff during the time they spend at their desk when they donīt have enough time at home to get the stuff done. Of course, I am fortunate enough now to be working 24/7 with no hope of vacations or sick leave for years these days, as Iīm a stay at home mom now, but before this career change I had more than 10 years in the IT industry. Joan Cole joancole@mindspring.com Champaign, IL, USA Wed Nov 14 15:07:20 EST 2001 No requirements, no project plan, no time to test You read it right. I'm on a project with none of the above ! What fun it is... Here's a typical day in a nutshell : John can you start writing module x now please? Ok what is module x supposed to do? Um I'll get back to you on that. A couple of hours later... John how's your work on module x going? John John@hotmail.com Anonymous, Canada Tue Dec 10 18:33:25 GMT 2002 The joy of deathmarches Joan Cole sez: Of course, I am fortunate enough now to be working 24/7 with no hope of vacations or sick leave for years these days, as Iīm a stay at home mom now, but before this career change I had more than 10 years in the IT industry. Sure, the hours suck, but just think of the fringe benifits. Chris Cooney chris@disjoint.org Washington DC, USA Wed Feb 26 22:45:01 GMT 2003 |
||||||||||||
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright Đ 1998-2007 Matt Stephens. ALL RIGHTS RESERVED.