The 9-1 versus 1-9 theory

[BJCooperIT]

Many of us have worked for them. You know the type. A manager who subscribes to the theory that if one woman can make a baby in nine months then nine women can make a baby in one month. Sometimes bringing in more help drags a project down.

Case-in-point was a project I consulted on that migrated from an application conversion into a full-blown new custom application development. My co-worker and I were 2 months into the coding and the project manager wanted us to off-load some of the development onto two of the client's programmers who had not been involved in the project. They were new to the technology (IDMS replaced by Oracle), new to the tools (mainframers who had never coded GUI), new to the application, and had never even seen an ERD.

Had we stopped development to bring these folks up to speed we would have spent more time training them than it took to complete the project. I quietly spoke to the manager and stated my case and in the end we compromised by training them for 2 hours each morning for 2 weeks. Even with that the "new" help was "no" help and we were glad we maintained control of development. As it was, the programmers were moved off onto maintenance tasks and totally forgot everything we showed them. We wasted those training hours and slowed development for nothing.

Have you encountered this problem? If so, is there a better way to handle it?

select * from Life where Brain is not null

Consultant/Custom Forms & PL/SQL - Oracle 8.1.7 - Windows 2000
[sup]When posting code, please use TGML to help readability. Thanks![sup]

 

[meadandale]

Hand your manager a copy of The Mythical Man Month by Fred Brooks and make sure that he/she reads it.

 

[BJCooperIT]

Thanks for the title. After doing a google search and reading the reviews I think I will purchase a copy for myself!

select * from Life where Brain is not null

Consultant/Custom Forms & PL/SQL - Oracle 8.1.7 - Windows 2000
[sup]When posting code, please use TGML to help readability. Thanks![sup]

 

[sleipnir214]

Any manager who thinks "mongolian horde" programming can work except in a small set of specific cases should be bludgeoned into submission with a copy of The Mythical Man Month.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[palbano]

>> Have you encountered this problem? If so, is there a
>> better way to handle it?

Of course i have encountered it. You can’t take three steps without tripping over one of them.

My experience is that someone like that is totally unqualified for the position. Since the company saw fit to place a totally unqualified person into that position the person responsible for that decision is also totally unqualified for their position…. Repeat until you reach the CEO of the company. Now you may think I am joking but I am not. That situation reflects a company suffering from lack of leadership and quite frankly I don’t believe there is a bottom up solution for it.

So, is there a better way to handle it? Well the first idea that comes to mind is to quit and go somewhere that has some qualified leadership. If you find that place, please let me know. Since I no longer believe that Shangri-La exists, I find that the I don’t care attitude serves me best.

Now does this mean that I don’t perform my work to the best of my abilities? No, I have to live with myself. But I refuse to be stressed by conditions that are not of my making and that I have no control over.

If management asks me for recommendations or dates I will break my back to see that things run smoothly and dates are hit. When they make decisions that are obviously flawed or proclaim arbitrary dates for tasks, I refuse to bear any stress related to the operations resulting from those decisions.


-pete
[sub]I just can't seem to get back my IntelliSense[/sub]

 

[EdwardMartinIII]

The problem with the baby - month analogy is that it isn't flawed. It is patently obvious that if you have a single mechanism that produces a result in 9 months, then 9 mechanisms will probably produce results at a one-per-month rate after the initial startup period and with either sufficient staggering, or in batches every 9 months. Monogamy is the hidden assumption that makes people think the analogy doesn't work. . Lifestyle issues aside, the Earth's population is not increasing solely by one baby every nine months. Obviously, there's some multiple processing business at work!

Most managers realize that this is useful in theory and are willing to accept a little more dev time and a little more in the way of capital costs if they can show that they'll be producing a unit in 1/9th the time. This radical idea worked for Henry Ford.

Frederick Brooks' book should be required reading for anyone who is involved at any level with a large piece of software development. Some of the best managers I know swear by it.

That said...

The only thing that seems to consistently work with me when I'm faced with a situation such as this (which, happily, is rare) to to run through the process and find the unique resources (the phrase my co-workers are probably sick of me using is "the slowest boat in our fleet&quot. It is rarely what people think it is. Application of precise power to this point provides the greatest effect.

Sometimes the best thing to do is to approach the problem as solvable by splitting it up, but to do so intelligently. This means you have to look your manager square in the eye and say "Well, Jack, you just might have something there. Can we work out some ways to implement this that make sense?" This sometimes requires restructuring the problem, and almost always requires start-up time. Managers like to hear "yes" more than they like to hear "no", so feel free to steal: "Yes, we can do this, and it might have the effect you're looking for, but it's going to mess with the schedule or some other resource".

So, I advise people to get involved. Help your manager find the best technical solution so that you can meet their needs in the way they want. If your manager is coming up with outrageous ideas, then talk with them and find out what results they want. After all, according to HR, you were hired for your expertise. Use that expertise to find a good solution. The ideal business relationship is mutually solving a clear goal.

On the occasions I've designed complicated programing projects, I've always designed projects that could have portions farmed out. Sometimes, that farming out occurred and as long as the architecture was obeyed, it worked great. One of my most recent projects is massively distributed among 30 different worker bees. The only thing that keeps it from exploding in my face is that it was designed to be distributed.

Cheers,


Edward

Like Lovecraft? Know Photoshop? Got time for the Unspeakable?

http://www.petting-zoo.org/Movies_Dreamquest.html

 

[CajunCenturion]

I believe that the 9/1 - 1/9 analogy is flawed because nine women cannot produce one baby in one month. Nine women can produce nine babies, one month at a time for nine months, but that is not the same as nine women producing one baby in one month. Over-production is not necessarily any better than under-production. And even that only works with complete autonomous parallelism.

The type of manager that BJCooperIT is referring to is one that first doesn't understand the concepts of serialization and parallelism as they apply to project development. They are also failing to take into account the increased overhead that a project incurrs as the participants are increased.

By overhead, we're talking training, communication, interfacing, documentation, coordination, standardization, and project management. The result is that, even if we assume full parallelism, when one server can produce nine widgets in nine months, then nine servers will produce nine widgets in two months, because half their time is now in overhead, and not development.

Do you want to discuss the overhead of dealing with one pregnant woman, as opposed to the overhead of nine pregnant ... never mind - won't go there.

I personally feel that Dr. Brooks's book (first published in 1972) was and still is one of the definative texts on Software Engineering. As much as we would like our managers to read and understand these concepts, it may be wishfull thinking to believe that reading one book will open their eyes.

Dealing with the problem requires communication between you and your manager. You can use the Critical Path Method along with documented task dependancies to deal with the serial/parallel issues, and the overhead issue is practical common sense. Yes, I know I'm making some assumptions about management, but regardless, if the manager does not want to hear what you're saying, then all you can do is document the project development and do the best you can. At some point, hopefully you'll be able to not only tell, by show your manager the effects of why 1/9 to 9/1 simply does not work.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[OhioBreeze]

>They were new to the technology (IDMS replaced by Oracle), new to the tools (mainframers who had never coded GUI), new to the application, and had never even seen an ERD.


I think there is probably something else at issue here. Either the manager wanted to see if he had some hidden talents in the chosen staff that you were asked to "off load" to or there was a degree of mis-trust in your skills and the manager wanted to confirm your work output to give it a "sanity check". Sometimes a manager will use this technique to checkpoint a project to see if the skills that are being used are really what the project needs. Perhaps when the Request for Quote (RFQ) was developed there was some debate as to what direction the methodology should take; which programming lanuage to use, operating system to base it on what kind of hardware to sit it on. A sanity check is usually taken by any manager that wants to know he made the right choice (or know that he is going to live with).

 

[BJCooperIT]

In this case I believe it was motivated by the fact that those folks were going to have to maintain the system after we consultants left. This definitely is an additional wrinkle in the scenario. The Man Month theory appears to be predicated on the idea that the additional help has the necessary skills to do the job - which wasn't the case.

This was a government client and the decisions of methodology, language, operating system, hardware were dictated by the powers that be, not made by the project manager.

select * from Life where Brain is not null

Consultant/Custom Forms & PL/SQL - Oracle 8.1.7 - Windows 2000
[sup]When posting code, please use TGML to help readability. Thanks![sup]

 

[EdwardMartinIII]

This underscores what CajunCenturion wrote and I (I thought) alluded to: the best way to avoid these kinds of scheduling mishaps is to engage as much as possible and communicate with your management.

Sure, at times, management is insane, and during those times, you either weather it as best you can, or bail. Or, you can get whapped around and hope that you come out smelling nice after all is said and done. Then bail, while your employer still has a nice taste in their mouth.

I suppose it's possible that a situation such as suggested by OhioBreeze might be happening, in which case you are working for someone who is insane or paranoid, or just nutty. (see above)

A lot of times, you can help the situation tremendously by offering to sit in and help analyze the difficulty and offering to help come up with solutions. After all, you're all supposed to be working toward the same goal, right...?

Sometimes, the best move is the subtle move of managing your manager.

Cheers,


Edward

"Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door

 

[lionelhill]

ohje, the more time goes on the more things stay the same. Richard Feynmann describes exactly this situation when he started using punched cards to do calculations. It's a pity managers responsible for IT units, more than 50 years on, haven't twigged to the concept of a pipelined production-line yet.

 

[jtb]

the only thing that trumps either irresistable force or immovable object is when one of the sales team starts talking about your team "not being committed" to winning the business...

At that point, regardless of reality, you either agree to the unreasonable demands or get fired.

So, build a WBS, enough DFD to sink a ship, and all the project plans you can fit into your presentation... because your team will be building 1-month babies and they'd better be pretty...

JTB
Senior Infrastructure Specialist
MCSE-NT4, MCP+I, MCP-W2K, CCNA, CCDA,
CTE, MCIWD, i-Net+, Network+
(MCSE-W2K in progress)