Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
There are too many managers

By Herring in Op-Ed
Tue Apr 30, 2002 at 03:39:43 PM EST
Tags: You Know... (all tags)
You Know...

I remember when I first got into coding. You spoke to the user, worked out what they wanted, you coded it and then they tested it. Happy days. Where did it go?

There are no links in this story since it's purely a personal rant.


I worked on one particular team for 6 years. When I started, there were 10 people full time coding (well, 9.8 since the team leader had to do some admin crap). When I left the team, there were still 10 people but they were:
  • One project manager
  • One QA analyst
  • One technical architect (me - allegedly not coding)
  • One systems analyst
  • Six coders


  • Certainly no more useful code was being produced than before, but a lot more reports were. I saw the same symptoms throughout the organisation. When there were complaints about the quality of support, for the cost of 2 support people, they employed one "service manager" to liaise with the rest of the business and find out what their problems were. Now, I look at our IT department and I figure that we're down below 60% of staff who actually "do something". The rest are managers, team leaders, project managers and other assorted people who are more used to PowerPoint than Regedit.

    As a technical person myself, I spend more and more time on writing reports/justifications for managers - generally justifications of what would be blindingly obvious to anyone who knew what they were talking about. Why is this?

    My personal theory is this:
  • Senior management want to isolate themselves from the "coalface"
  • Middle managers do not understand the technology
  • Middle managers try to control the techies with the only weapons they understand - procedures, reports and presentations.


  • I do not believe that this phenomenon is restricted to IT - just look at the NHS here in the UK. More and more money gets pumped in every year but with little effect. From the outside perspective, it seems to me that a lot of this money is going in reorgs, marketing (why the f*ck you need a mission statement for a hospital beyond "we aim to make people better" is beyond me) and setting and meeting "targets".

    Of course, this could just be a UK thing but I do get the impression that everyone now aspires to be a manager. To be doing an actual useful job is somehow shameful. This is why I can't see XP (eXtreme Programming, not Windows XP) taking off in the UK. Get everyone doing something useful and where is the room for the manager?

    I know our user's business quite well. The users I deal with understand what I'm talking about. I am tired to have to translate this dialogue for the benefit of project managers who understand neither the business nor the technology. Whilst I appreciate the need for some sort of control (to prevent user's fantasies or geek's techno-lust getting out of control), shouldn't this control be exercised be people who at least have some sort of clue?

    I think that the Golgafrinchams were right.

    Sponsors

    Voxel dot net
    o Managed Hosting
    o VoxCAST Content Delivery
    o Raw Infrastructure

    Login

    Poll
    There are too many useless people employed
    o Yes 71%
    o No 5%
    o Show me a Gantt chart 15%
    o I am a manger who pressed the wrong button by mistake 6%

    Votes: 107
    Results | Other Polls

    Related Links
    o Also by Herring


    Display: Sort:
    There are too many managers | 139 comments (139 topical, editorial, 0 hidden)
    on a higher level... (4.33 / 6) (#1)
    by MFS on Tue Apr 30, 2002 at 11:01:02 AM EST

    there are too many managers everywhere. Look at where I work: lots of desk jokeys, not enough of us actually doing the work. And it makes for an outrageous political environment, which is pathetic for a company that only has 50 people in this location.

    Seems everyone wants to tell everyone else how to do their job, whether they're qualified or not.

    such is life in the land of the selfish, I suppose.


    Nope, not me. I must be someone else.

    Absolutely (4.60 / 10) (#9)
    by Herring on Tue Apr 30, 2002 at 11:18:50 AM EST

    Transcript (from memory) of a recent meeting with aproject manager (I am BDC, FPM = Fuckwit Project Manager):
    BDC: So I've put all of the source into source control, I've checked that another developer can get the latest version, build it and run it.
    FPM: So that's the source, not the binaries.
    BDC: Yes. The source can now be checked out and compiled to produce the same binaries.
    FPM: So how do you compile the source to produce the binaries?
    BDC: With a C++ compiler.
    FPM: Shouldn't the instructions tell the developer how to do that?
    BDC: If someone doesn't know how they should compile the C++ files with a C++ compiler, then they're not a developer.
    FPM: But I don't know.
    BDC: (barely audible growling noise)

    This exchange went on for about half an hour in total. All I can think is: what value is this person actually adding to the process? What are they doing which impacts the bottom line - aside from drawing a huge salary?

    At this point, I normally go to the pub.


    Say lol what again motherfucker, say lol what again, I dare you, no I double dare you
    [ Parent ]
    it works both ways (none / 0) (#69)
    by QuantumG on Wed May 01, 2002 at 03:23:08 AM EST

    you're not qualified as a project manager so you have no idea what he does.

    Gun fire is the sound of freedom.
    [ Parent ]
    Fuck all [n/t] (none / 0) (#74)
    by Herring on Wed May 01, 2002 at 03:54:42 AM EST



    Say lol what again motherfucker, say lol what again, I dare you, no I double dare you
    [ Parent ]
    attitude (none / 0) (#77)
    by QuantumG on Wed May 01, 2002 at 04:11:00 AM EST

    How have you come to this conclusion? Why dont you go to him, put your bias aside for 5 minutes, and tell him that you're interested in becoming a project manager "sometime later in my career" and ask him what is involved. Friends of mine are project managers. One of them changed jobs last year. She went from a project manager position in a software company to a project manager position in a civil engineering company. She can code, but she dont know anything about building bridges. I'm pretty sure those civil engineers are sitting around saying "god, she doesn't even know how to [random civil engineering concept]" and she doesn't need to. So dont go on about your pm not knowing how to compile the source. You're the one telling him about source control, when he has absolutely no need to know about it. Maybe what you should be doing is talking to him about stuff that is relevant, like when you're going to deliver the next release. If you knew something about his job you might be able to appreciate everything he does to make sure you get your next pay cheque.

    Gun fire is the sound of freedom.
    [ Parent ]
    It's not bias. (none / 0) (#80)
    by Herring on Wed May 01, 2002 at 04:14:36 AM EST

    Everyone agrees that this guy is a complete tool.

    Yes, there are good project managers but around here they seem incredibly rare.


    Say lol what again motherfucker, say lol what again, I dare you, no I double dare you
    [ Parent ]
    So get rid of him (none / 0) (#81)
    by QuantumG on Wed May 01, 2002 at 04:21:26 AM EST

    You got a team leader? Take your concerns to him first. If that doesn't work, ask your team leader to come with you to talk to your VP of engineering. You'll actually have to make a case however. Consisting of two major points: here's what a project manager is supposed to do (and he's not doing it), and this is the effect it has had on the company -- not the effect it has had on you, but the actual effect it has had on the bottom line. For example, if you're releases have slipped, it's his fault. If he has agreed to customer requirements without consulting the team leader and you subsequently cant deliver those requirements, it's his fault.

    Gun fire is the sound of freedom.
    [ Parent ]
    opinions. (5.00 / 1) (#82)
    by katie on Wed May 01, 2002 at 04:26:55 AM EST

    Civil engineers get listened to. They don't turn up and say "Steel. Obvious choice for this sort of bridge. Not going to fall down" to have management reply "Ah. Yeah. We already bought all this surplus wood. You can make it out of wood, right?"

    Software engineers don't get their professional opinion listened to. We offer the best route to do something and management decide not to do that. Not for any rational reason, but for a set of reasons that don't make any sense if you question them.

    I've been forbidden from using TCL in production code here. Testing code, yes, production code, no.

    Why?

    Because TCL is approved of by management. Excuse me? They've never written a program in their lives, how can they approve or not approve of languages? Surely I'm the best judge of which tool to use?

    But apparently I'm not. Someone with a degree in Art History who can just about work MS Project gets to make that decision. Without asking anyone technical.

    Civil engineers don't have to put up with crap like that, because otherwise bridges would be made of various managers favourite flavours of cheese.


    [ Parent ]

    well actually (none / 0) (#83)
    by QuantumG on Wed May 01, 2002 at 04:34:02 AM EST

    I can envision a situation where a civil engineer says "ok, we'll make a suspension bridge over this part" and management says "no, it has to be a causeway".. I'm sure the civil engineer says "no.. a suspension bridge is better" and they say "customer wants causeway". Not that I know anything about civil engineering!

    Gun fire is the sound of freedom.
    [ Parent ]
    source/binaries (none / 0) (#129)
    by memerot2 on Wed May 01, 2002 at 05:44:15 PM EST

    "So we sent the bridge blueprints to the construction company."
    "The blueprints."
    "Yes"
    "But not the bridge?"
    "No... they use the blueprints to build the bridge."
    "Don't you think this should be in the instructions?"
    "If they don't know how to build a bridge from blueprints, they're not a construction company."
    "Well I don't know how..."
    ..grumble

    Same shit, different terms.  In both cases the person would be justified grumbling at the manager.

    [ Parent ]

    Copout (5.00 / 1) (#86)
    by gnovos on Wed May 01, 2002 at 05:11:01 AM EST

    That's a copout, becuase you could say that, since you have no idea what a "Thimble Partitioner" is, you have no right to grudge him his $1.4m a year salary.  Any manager that does not understand what he is managing is almost by definition not doing his job.

    A Haiku: "fuck you fuck you fuck/you fuck you fuck you fuck you/fuck you fuck you snow" - JChen
    [ Parent ]
    HEY!!!! (none / 0) (#130)
    by memerot2 on Wed May 01, 2002 at 05:45:57 PM EST

    BASTARD!  You blew my cover!  My manager just read that now I'm no longer the Head Thimble Partitioner, Eastern Division.

    [ Parent ]
    Eastern Division? (none / 0) (#136)
    by gnovos on Thu May 02, 2002 at 02:02:42 PM EST

    EASTERN Division!?!?  No wonder you were fired, you fraud!  Everyon knows that Thimbles can't be properly partitioned in the Easter hemisphere.  Gravometronic vario-valence barometers are all thrown out of whack on that side of the globe!

    A Haiku: "fuck you fuck you fuck/you fuck you fuck you fuck you/fuck you fuck you snow" - JChen
    [ Parent ]
    So... (none / 0) (#93)
    by FredBloggs on Wed May 01, 2002 at 06:27:49 AM EST

    why dont you check the binaries in too? Sounds like it would solve the problem. (Unless its one of those projects which required a fairly complicated install/setup process.)

    [ Parent ]
    Wrong. (3.66 / 3) (#2)
    by /dev/trash on Tue Apr 30, 2002 at 11:04:58 AM EST

    I have no desire to manage. Codin is all ever want to do.

    ---
    Updated 02/20/2004
    New Site
    Drugs? (1.00 / 1) (#40)
    by Duende on Tue Apr 30, 2002 at 04:53:44 PM EST

    Ack. I scanned the typo ('codin'), parsed it as codiene. It made perfect sense to me... the thought of being management makes me want to take drugs.

    ================================================
    "The Yatta dance is not a martial art."
    --Midnight Phoneboys
    [ Parent ]

    Roger that. (none / 0) (#61)
    by porkchop_d_clown on Wed May 01, 2002 at 12:14:28 AM EST

    I let someone talk me into a management job despite my better judgement. Career path, you know. Worst six months of my life. Of course, for the rest of my time with that Three Letter Corporation, I was rated as a "manager" and paid appropriately. Extra 20k per year - I kid you not. 4 years later, people still gawp when I tell them how much I made that year.


    --
    Uhhh.... Where did I drop that clue?
    I know I had one just a minute ago!


    [ Parent ]
    more used to PowerPoint than Regedit. (3.83 / 6) (#3)
    by wiredog on Tue Apr 30, 2002 at 11:07:39 AM EST

    What's Regedit? Some sort of config tool? I use Pico for small config files, Emacs for big ones. Never heard of regedit.

    Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
    It's OK... (4.00 / 6) (#4)
    by Armaphine on Tue Apr 30, 2002 at 11:08:39 AM EST

    ...it's a Windows thing. We don't expect the *nix people to understand.

    Question authority. Don't ask why, just do it.
    [ Parent ]

    Hmm (1.88 / 9) (#6)
    by Kingmaker on Tue Apr 30, 2002 at 11:12:17 AM EST

    You had two choices : A)Explain what regedit is B)Insult the poster. Actually, there was a third choice, C)stfu bitch. Guess which you should have chosen.

    [ Parent ]
    Try decaf (4.30 / 10) (#8)
    by wiredog on Tue Apr 30, 2002 at 11:16:16 AM EST

    It tastes almost like Real Coffee these days...

    Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
    [ Parent ]
    I strongly suspect... (3.50 / 4) (#17)
    by maroberts on Tue Apr 30, 2002 at 11:57:12 AM EST

    ..the origional post is a joke and the rest of the thread continued in like vein
    ~~~
    The greatest trick the Devil pulled was to convince the world he didn't exist -- Verbil Kint, The Usual Suspects
    [ Parent ]
    Okie Dokie... (4.28 / 7) (#18)
    by Armaphine on Tue Apr 30, 2002 at 11:58:47 AM EST

    ...here's why you probably don't want to go jumping in with a holier-than-thou attitude. I know that wiredog knows what regedit is. He is a rather Clueful individual, and even if he didn't know right away, he has enough brains to know where to look it up at.

    I was merely making a joke based off of his own joke, and you took it somehow as a personal insult.

    OK, so now, which choice should YOU have chosen? Hmmm....

    Question authority. Don't ask why, just do it.
    [ Parent ]

    enough brains (5.00 / 1) (#27)
    by wiredog on Tue Apr 30, 2002 at 01:14:12 PM EST

    Seen this thread yet?

    Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
    [ Parent ]
    Windows Registry Editor [n/t] (4.00 / 2) (#5)
    by nosilA on Tue Apr 30, 2002 at 11:08:58 AM EST


    Vote to Abstain!
    [ Parent ]
    Management (4.28 / 7) (#7)
    by jmzero on Tue Apr 30, 2002 at 11:14:52 AM EST

    Most of the coding work I do is on small projects.  Me and a couple guys do everything and it's done.  For these kinds of projects, management has little to add - though often it's best if somebody with "nice hair" is around to deal with client management.  Each person on the project can keep the whole project in their mind for the most part.  Everyone knows what part everyone else is doing, and things roll along pretty smoothly.

    But at some point a project reaches a size where guerilla coding just doesn't work anymore.  Nobody has the whole picture, and everybody forgets what everyone else is doing.  At this point, one of the programmers has to become "the manager", and things work out pretty well (as long as "the manager" is organized).  

    When projects go afoul is when a non-programmer trys to be "the manager".  Things aren't divided well, things are designed well, and things don't go well.  That doesn't mean that management has nothing to add, only that management needs to have a real grasp of how the system is really going to work.
    .
    "Let's not stir that bag of worms." - my lovely wife

    Talk about size (1.00 / 1) (#15)
    by Betcour on Tue Apr 30, 2002 at 11:50:14 AM EST

    The software I work on (alone) has gotten so big I don't even know how some of the things work anymore.

    [ Parent ]
    Different kinds of management (4.00 / 4) (#26)
    by /dev/niall on Tue Apr 30, 2002 at 12:45:00 PM EST

    When projects go afoul is when a non-programmer trys to be "the manager". Things aren't divided well, things are designed well, and things don't go well. That doesn't mean that management has nothing to add, only that management needs to have a real grasp of how the system is really going to work.

    That just illustrates the world of difference between a product manager and a project manager. The former should decide what the product is functionally (who are your customers, what do they want etc.), and the latter should decide how to go about implementing (who will work on what etc.) it. Typically technical marketing types excel at product management, while ex-coders make the best project managers IMO.

    I have the good fortune of working with decent examples of both! phew.

    -- 报告人对动物
    [ Parent ]

    I disagree (4.50 / 2) (#44)
    by Altus on Tue Apr 30, 2002 at 05:20:39 PM EST

    with one point.

    I dont think the project manager should necessarily be a former programmer, although they could be.

    I believe that the Tech lead should be the one who has the overall concept of the project in his head, and he should be the one either assigning tasks, or at the very least, advising the project manager.  if done in this way you can actualy combine the project and product managers into one job (sometimes, obviously this hinges on haveing competent people in both the techlead and project managers position.

    I have worked in these situations before as a tech lead and the projects have always gone well.  The tech lead is the one who will know about how different parts of the code go together and what parts a new feature will touch.  they also should know the strengths and weaknesses of thier coders.  These are the sorts of things that a non technical manager simply cannot do. Even if they have previous technical experience they are often too far removed from the actual code to be able to handle things at that level.
    "In America, first you get the sugar, then you get the money, then you get the women..." -H. Simpson
    [ Parent ]

    That's nothing (4.33 / 9) (#10)
    by theboz on Tue Apr 30, 2002 at 11:19:24 AM EST

    In my last job, I had to report to a project manager, and a "regular" manager. Then, they were part of a 12 person committee that decided what development was to be done and the priority of things. I had no say in their meetings and didn't even know everyone on the committee. Mostly they tried to have me sit around and do nothing while they argued, but I snuck in a lot of small stuff that needed to be done. Finally, they agreed on a big project which was very important to the company. I had nearly finished the project and was making modifications due to QA testing (I wasn't including 1 QA person and their manager in the committee by the way) and then I got laid off. I was the only developer, but rather than lay off the fat cat management, they got rid of the sole developer of the project. This was last November. According to a friend that still works there, they have not been successful in replacing me yet. They even tried to bring me back on as a contractor, but the letter I signed for my severence package means that I can't work for that company directly or from a sub-contracting firm for a year or so unless I want to repay my severence. This sort of thing happened across the board. I forget if it was 1/3 or2/3 of the development group were in the same situation. The programmers were laid off, while the managers were outsourced to Accenture. I reccommend avoiding Accenture to anyone out there. Not only are they a spinoff of Arthur Anderson, the Enron accountant, but they prefer to take someone off the street and send them to a blitzkrieg of certification classes so they can pay them very little money, rather than hire seasoned and well-experienced people for a little more. They're well known for the low quality of their work, much like other outsourcing companies such as KPMG.

    If this situation didn't leave me without a job for a few months, I would be laughing about it right now. However, outsourcing is the way of the future. Some things can be outsouced well. Helpdesks, billing, hardware, etc. Programming is not. Fortunately for me, I have a job doing RAD, which XP fits in nicely. This morning I have been making changes in production to track the time a record has been in a certain status. My QA is to look and see if it looks like it works, and the UAT is simply waiting to see if my phone rings because the users can't enter orders. My requirements are a piece of notebook paper that my VP, a consultant, and myself scribbled on. We also have an opening for a SQL and VB expert, if anyone is interested.

    Stuff.

    outsourcing (4.00 / 4) (#20)
    by ucblockhead on Tue Apr 30, 2002 at 12:05:15 PM EST

    Outsourcing is a classic example of short-term thinking. The bean-counters look at the dollars that can be saved this quarter and miss the absolute disasters that it can set up in the long term. Corporate software is not something that can be easily changed, so hiring some other company to do it for you is analogous to asking someone to please grab you by the short curlies.

    I have seen companies fuck themselves in the manner you describe more times than I can count. Managers undervalue the coders, thinking that they are analogous to widget makers, easily replacable with the help-wanted ads. They fail to understand both the shortage of good programmers and the learning curve associated with coming onto a new software project. So a year or so after their wonderful cost cutting, they find themselves screwed. Sometimes they get screwed by failing systems. More often, they get screwed by people they used to employ charging them an arm and a leg as consultants. Lord knows, I've done that.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    Yeap (4.66 / 3) (#24)
    by theboz on Tue Apr 30, 2002 at 12:33:38 PM EST

    There is talk that the company I was working for is planning for another round of layoffs, if they haven't done it yet.

    In my case, my employer had planned to turn over all development to Accenture, and everyone interviewed with Accenture. They had assured us that almost everyone would get a job, but then the negotiations were delayed, but they didn't tell us why. Also, everyone was scared by the interview because it was a joke. Accenture's idea of an interview was to bring in someone that had no idea of what work you did, how important it was, or how good of a coder you are. Basically it was a blatant attempt at "We'll interview them, give them some snacks, and make it look like we gave them a chance." I found out from my project manager that the person who interviewed me was actually very impressed by me.

    I think that outsourcing is turning into capitalism in it's extreme. There's no longer humans or individuals, but contracts. While we were just human resources before, companies now don't even consider us to be resources, we are expenses. It's a shame. I like the idea of a free market, but freedom should be about empowering individuals (sorry for the buzzword) rather than companies.

    Stuff.
    [ Parent ]

    There is a place for outsourcing (4.00 / 1) (#59)
    by cam on Tue Apr 30, 2002 at 10:02:00 PM EST

    I think that outsourcing is turning into capitalism in it's extreme.

    There is a place for outsourcing, especially where the company acquiring the services is inefficient in an area. We have one company that we provide services for where, because we are more efficient in our management of the services, our administration overhead is 1/1000th of theirs. It saves them close to 3 million a year.

    Outsourcing part of their process to us allows them to concentrate on what they do best, which is get new customers and provide their service. It free's them from having to worry the state/management of the technical components. We do that extremely well for them. The technical components includes software, engineering and management of those processes. It is a good symbiotic relationship.

    cam
    Freedom, Liberty, Equity and an Australian Republic
    [ Parent ]

    Terminology correction (none / 0) (#54)
    by sigwinch on Tue Apr 30, 2002 at 06:53:10 PM EST

    Outsourcing is a classic example of short-term thinking.
    The proper antonym for "in-house work" is "outhouse work".

    --
    I don't want the world, I just want your half.
    [ Parent ]

    question (none / 0) (#120)
    by dostick on Wed May 01, 2002 at 03:28:17 PM EST

    what is Outrourcing ?
    My site: http://blog.enargi.com
    [ Parent ]
    Answer (none / 0) (#132)
    by thebrix on Thu May 02, 2002 at 05:45:40 AM EST

    This is hardly eloquent, but here goes:

    If a company performs a task which is vital to its continued operation but which is not what the outside world believes the company to do and that task can be run by an outside organisation, notionally more cheaply, without unacceptable risk of physical or intellectual property being leaked, transferring responsibility for that task to the outside organisation is 'outsourcing'.

    Wow!

    Typically, operations (for an IT company) such as cleaning, catering, maintenance, running helpdesks, maintaining desktop PCs and so on are outsourced.

    [ Parent ]

    Arrogance (3.88 / 17) (#11)
    by ubu on Tue Apr 30, 2002 at 11:21:03 AM EST

    This is just arrogance. What we don't see here is the wider picture. Obviously, you think the core of your business is writing code, and everything else is just an irrelevance.

    I'm very sorry, but there is a lot more to identifying what your customers want, providing it (on time and to specification) and making sure they are kept happy after that, than just locking up a bunch of programmers in a room and hoping for the best.

    Actually writing the code is a minimal part of the business, when seen within the context of everything else the business must do.

    These "managers" may seem to get in the way, from a programmers perspective, but doubtless they have a similar opinion of programmers themselves. Your manager has to worry about a hell of a lot more than you do, and sees the bigger picture.
    --
    As good old software hats say - "You are in very safe hands, if you are using CVS !!!"

    It is not arrogance. (4.00 / 7) (#12)
    by Herring on Tue Apr 30, 2002 at 11:26:40 AM EST

    What I'm trying to say is that between the developers and the users, we can quite happily get what needs to be done done. What I'm objecting to is the idiots who add absolutely no value to the process.

    You are quite correct that writing the code is the smallest part of the job. Finding out what code to write and making sure it actually does that is much more important. The (project) managers we have do not help this in the slightest.



    Say lol what again motherfucker, say lol what again, I dare you, no I double dare you
    [ Parent ]
    Useless Coders? (4.00 / 5) (#22)
    by Matrix on Tue Apr 30, 2002 at 12:10:52 PM EST

    Does anyone else see a problem when the managers theoretically guiding a team whose objective is to produce code do not see the relevance or usefulness of programmers, and think they just get in the way? What, do they think that marketing, legal, and management can get together and magically produce a product?

    Yes, management of some sort is necessary. But when you've got almost 50% of your team doing management and only management, then there's a problem.


    Matrix
    "...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
    - Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
    [ Parent ]

    Huh (4.00 / 4) (#23)
    by ubu on Tue Apr 30, 2002 at 12:25:27 PM EST

    Do they think marketing, legal, and management can get together and magically produce a product?

    You may as well say:

    • Do they think programming, legal and management can magically get together and sell a product?
    • Do they think programming, marketing and management can magically get together and defend a product?
    • Do they think programming, legal and marketing can magically get together and organise anything?
    etc. etc.

    You have to realise programming isn't especially more or less important than the others. If anything, it is less so because it is predictable and relatively risk free. Corral a group of programmers together and you can fairly easily and predictably have them produce X lines of code in Y amount of time. The important part, and the part the other components decide, the life of the business, is what code to produce, who to sell it to, and so on. These functions are the core of any business, not just programming.

    Coalminers can predictably produce X tons of coal per day. That doesn't make them the centre of a coal mining business though, and it isn't them that will make the difference between a successful coal mine and an unprofitable, unsuccessful one. It is the managers, marketers, business strategists and so on who are important for all that.

    ubu


    --
    As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
    [ Parent ]

    CoalMiners (4.20 / 5) (#28)
    by rdskutter on Tue Apr 30, 2002 at 01:32:59 PM EST

    Coalminers can predictably produce X tons of coal per day. That doesn't make them the centre of a coal mining business though, and it isn't them that will make the difference between a successful coal mine and an unprofitable, unsuccessful one. It is the managers, marketers, business strategists and so on who are important for all that.

    The coalminers are still the core essential staff of the mine. Without the coalminers, the managers, marketers and business strategists can all go and fuck themselves. If there are no coalminers then there will be no coal mine to run.


    If you're a jock, inflict some pain / If you're a nerd then use your brain - DAPHNE AND CELESTE
    [ Parent ]

    Missing the fucking point (4.50 / 4) (#29)
    by ubu on Tue Apr 30, 2002 at 01:47:26 PM EST

    If there are no business strategists, marketers, publicists and managers, there won't be a coal mine to run either. So I don't see how the miners are any more central than anybody else.
    --
    As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
    [ Parent ]
    You had a Point? (5.00 / 2) (#33)
    by Matrix on Tue Apr 30, 2002 at 02:37:51 PM EST

    You seem to have completely ignored my conclusion. Here, I'll repeat it for you.

    "Yes, management of some sort is necessary. But when you've got almost 50% of your team doing management and only management, then there's a problem."

    There, catch it that time?

    Your point that I took issue with was, also for your reference, the statement:

    "These "managers" may seem to get in the way, from a programmers perspective, but doubtless they have a similar opinion of programmers themselves."

    So you're saying that managers should think programmers are irrelevant to the business of producing code. This is not only blatant stupidity, but any manager who thinks like this should not be managing a software engineering team. In fact, managers like this are the reason software engineers and programmers have such a low opinion of management. They are the ones who actually do the work and on whose shoulders the quality the finished project rests on, and marketing and management treat them like they're totally extraneous.


    Matrix
    "...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
    - Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
    [ Parent ]

    You are pulling this out your ass (3.25 / 4) (#34)
    by ubu on Tue Apr 30, 2002 at 02:50:23 PM EST

    From a programmers perspective, it may seem odd that 50% of the project is management. I am sure, however, that management have their reasons. A software project requires a lot of management. It isn't clear to me why 50% of the project being management is a bad thing; the programmers have to be told what to do very precisely. I have seen no evidence suggesting it is innefficient or intrinsicially bad, just piss&moaning from various programmers fed up of being scrutinised and called to account.

    So you're saying that managers should think programmers are irrelevant to the business of producing code.

    No, I didn't say that anywhere. I was just illustrating that this is a matter of perspective.

    As the rest of your comment spins off from this fallacious conclusion, I can safely ignore it.

    Toodles!
    --
    As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
    [ Parent ]

    50% (5.00 / 1) (#35)
    by farmgeek on Tue Apr 30, 2002 at 03:58:38 PM EST

    You do realize that equals one manager per programmer don't you?  So,these managers should stand around and look over their assigned programmer's shoulder all day?

    Hell, I would think even a crappy manager should be able to handle two people at least.

    [ Parent ]

    One manager looking over One programmers shoulder (3.50 / 2) (#38)
    by Skywise on Tue Apr 30, 2002 at 04:09:29 PM EST

    That's XP programming aint it?  ;>

    [ Parent ]
    Only 50% ? (none / 0) (#79)
    by katie on Wed May 01, 2002 at 04:14:04 AM EST

    50% would be great. God, to work on a project where 50% of the people worked.

    I have 11 people on my project. Minus one who isn't on it because he's been pulled off to go firefighting. Minus one because he's a team leader. He's off today being taught how to do "effective appraisals" for example. Then there's me.

    The other 8 are managers.

    [ Parent ]

    Exactly (none / 0) (#103)
    by gazbo on Wed May 01, 2002 at 09:44:14 AM EST

    Then there's me.
    Yeah, And you're busy posting to K5 - Get working you lazy git, you've got 11 people's work to do.

    -----
    Topless, revealing, nude pics and vids of Zora Suleman! Upskirt and down blouse! Cleavage!
    Hardcore ZORA SULEMAN pics!

    [ Parent ]

    11 people's work. (none / 0) (#109)
    by katie on Wed May 01, 2002 at 11:06:35 AM EST

    Yeah, the minute they can produce a spec...

    See the problem is, as the specs get more detailed, each of the has, in the middle, one sentence:

    "Process these items."

    How we get them has been defined, the CPU speed of the machine that this code will run on has been defined, but no-one actually seems to have written down what "process" needs doing to the data.

    The minute someone has a sensible suggestion about it, I can do it. However for all their job titles: the Project Manager, the Business Analyst etc, none of them seem to actually understand the process that needs to happen.

    They don't seem very bothered by it not happening. After all they have company cars to drive about. They have meetings to attend and training courses to go on... they have catered lunches to order and eat.

    The project is behind schedule because it seems out of those 8 managers, none of them could do basic arithmetic and the weeks of the estimate up properly. Now they've noticed that duration & deadline don't match, the deadline's been moved.

    The milestones passed me going in the other direction.

    It's OK really, because apparently all my tasks are on schedule. The maintainer of the project plan has simply checked off as "completed" all the tasks that should have been completed by now according to the new schedule. Without even asking me which ones I really have done...

    It would be funny were it not so sad. That's the problem I have with Dilbert: It's not funny, it's *TRUE*.


    [ Parent ]

    I have the same problem (none / 0) (#124)
    by Cro Magnon on Wed May 01, 2002 at 04:41:48 PM EST

    I haven't done much coding for months because the "managers" can't decide on anything. So I spend more time online than I do working and nobody seems to care.
    Information wants to be beer.
    [ Parent ]
    i care (none / 0) (#128)
    by memerot2 on Wed May 01, 2002 at 05:35:08 PM EST

    what company is that?  are they hiring?  BELIEVE me i am HIGHLY qualified to not code for months :)

    [ Parent ]
    Not coding (5.00 / 1) (#131)
    by katie on Thu May 02, 2002 at 03:47:29 AM EST

    I'm not. It drives me up the wall. Basically, I'm not emotionally very good at trying to look busy when I'm not. You want to torture a workaholic? Hire them, promise them lots of involving work to do and then DON'T LET THEM DO IT...


    [ Parent ]
    Practice (none / 0) (#134)
    by Cro Magnon on Thu May 02, 2002 at 11:47:55 AM EST

    I've had practice looking busy. Given a choice I'd rather be busy coding/trouble shooting, and hopefully the designers/managers will get their acts together and give me some semi-stable specs I can do something with soon.
    Information wants to be beer.
    [ Parent ]
    Government (none / 0) (#135)
    by Cro Magnon on Thu May 02, 2002 at 11:56:09 AM EST

    I work for the government (I can already hear people saying that explains it). As far as I know there not hiring in my division, though they have quite a few contractors. Believe me, not coding gets boring quickly enough. I don't mind collecting my paycheck, but I'd really rather work for it, even if it cuts down my posting.
    Information wants to be beer.
    [ Parent ]
    They ARE more important. (5.00 / 3) (#85)
    by gnovos on Wed May 01, 2002 at 04:57:57 AM EST

    Because if you have 100% coalminers, there is still a small possibility that you can sell some coal (even if people have to come to the mine and pay a miner for it and carry it home in a bag), but if you have 0% coalminers then there is exactly NO chance of selling any coal, because there isn't any to sell.  The reason why they are important, MORE important, is that they actually produce something.  If the all-coalminer company goes out of business, the investors still will have piles of mined coal they can liquidate, but if the all-management business were to go under they would have nothing to sell off but stacks and stacks of org charts and quartly reports.

    A Haiku: "fuck you fuck you fuck/you fuck you fuck you fuck you/fuck you fuck you snow" - JChen
    [ Parent ]
    PUBLICISTS? (none / 0) (#127)
    by memerot2 on Wed May 01, 2002 at 05:23:29 PM EST

    PUBLICISTS for a coal mine?  
    MARKETERS?  "Burn Zimco coal, it's the best" -

    Uh.....NO!!!!  

    Business strategists?  
    Let me guess -
    "I think next year we should have the miners dig up a lot of coal.  What do you think Bob?"
    "Sounds ok to me, but lets hear what our image consultant has to say."
    "No, it's the BRANDING that's important, nobody actually cares if the coal burns, only that it's Zimco brand coal."
    "So we should fire all the coalminers and focus on branding?"
    "Exactly!"

    Does this sound like a good business to you?

    The thing is most coal miners are about as good as most other coal miners with their same experience.  The same is not true of programmers.  A genius programmer can carry a so-so software company, while bad programmers can be very well-managed and still not produce anything worthwhile.  The assembly line approach only works if all your cogs are equal and interchangeable, and programmers are not.

    [ Parent ]

    The answer of course is... (4.20 / 5) (#45)
    by peace on Tue Apr 30, 2002 at 05:29:25 PM EST

    Unix, Linux, C++, Apache, Python, Napster, Emacs, Vi, PERL, TeX, K5

    These applications were all developed by programmers and at least one of them in spite of management.

    I have never heard of a software application ever being developped with the absence of programmers. The one group that is present in all of your senerios is the programmer. My guess is that when it comes to actually programming, the people who can do the work are the ones who are the most importaint.

    If you were to task seperate groups of programmers, marketers, managers and executives with producing a product from requirements to delivery, only one group is going to have the tools neccesary that allow for even the possobility of success.

    I am sick and tired of self congradualtory managers who claim far more credit then they should for the success of any project. What the original article is refering to is the reality of the business market as it stands today. From what I have witnessed of management over the 10 years working as a programmer is that there primary purpose is to keep even bigger idiots higher up the corporate ladder off the programmers backs. I have rarely met a manager that understood the technologies there programmers were using. Generaly these managers eventualy try to "prove their worth" by interjecting some inaine requirement into the development process. One guy tried to get us to store all of our requirements in MS Word. We already had a complete document storedge system based around CVS. Another individual who was hired by the executives into the exalted position of CIO actually suggested that we write our Java code in MS Word. God I hate MS Word.

    Management in the real world is usualy a bunch of people who spend more time trying to outmenuver each other in the battle field of business politics then actually focus on what they can contibute to a project. Those that do focus on the work at hand generally find them selves out manuvered by people who spend all their time in meeting rooms.

    Kind Regards,
    peace

    [ Parent ]

    Your exmples are flawed (none / 0) (#138)
    by coryking on Sat May 04, 2002 at 03:02:30 PM EST

    They were all created as a hobby. We are talking about for profit software here. Yes, the examples you cited are great for non profit software, but are irrelavant in the context of business, for-profit software.

    [ Parent ]
    Predictable (5.00 / 1) (#78)
    by katie on Wed May 01, 2002 at 04:12:00 AM EST

    "You have to realise programming isn't especially more or less important than the others. If anything, it is less so because it is predictable and relatively risk free. Corral a group of programmers together and you can fairly easily and predictably have them produce X lines of code in Y amount of time."

    You don't want X lines of code. You want code that will do the job you want done. X lines of random code that don't work are no use to you. Hire random programmers, you're likely to get that random code.

    And risk free? In a world where the majority of software projects are cancelled because they get too complicated to be completeable?

    [ Parent ]

    and then there is the (4.00 / 1) (#43)
    by Altus on Tue Apr 30, 2002 at 05:09:01 PM EST

    management fallacy that one programming resource is interchangeable with another.

    This was a common mistake at my last job... people would constantly be moved from project to project.  Durring a major development cycle  my team went from a maximum of 4 people to a minimum of zero (for the 2 weeks I was working on something else)  the majority of the time I was the only person on.

    when things went wrong (behind schedule, what a shock!)they just wanted to throw some random programmers at the problem.

    This wont work.  you need the right programmers for the job... managers that can not understand this will never be useful.
    "In America, first you get the sugar, then you get the money, then you get the women..." -H. Simpson
    [ Parent ]

    preach it! (none / 0) (#126)
    by memerot2 on Wed May 01, 2002 at 05:13:32 PM EST

    My last boss had the habit of walking up to anyone on the development staff and starting off a conversation "So do you think you can change the pop-up at the end of the shopping cart to exclude two site ids?". Pause. "What are you talking about john?" "You know, the pop-up." "I don't know what you're talking about. Is there a pop-up?" "Yes, Manjit added it yesterday." "Well I've never heard of this project or had any idea it existed because I think it's a horrible idea, but yes I'm sure I can make that change." "Ok, that's your next assignment." "You know, it will take me 5 times as long to do that as it would take for Manjit to do it." "Why?" "Because I've never even looked at the code." "Oh, well Manjit's working on something else, so just go ahead". And of course later in the day here would come Manjit "Brian, I don't understand this section of the code where you're encrypting credit cards." Pause. Realization we're each wasting a tremendous amount of time working on each other's code when a properly directed request could have solved the problem in a heartbeat. "Um.... you're not changing that are you?" "Yes, John asked me to do some work on it." Sigh.... To him we were interchangeable parts, and anything one of us knew shouldn't automatically be known by all the others.

    [ Parent ]
    thats terible (none / 0) (#133)
    by Altus on Thu May 02, 2002 at 11:27:40 AM EST

    the experience I had wasnt quite so extreme... people would get shuffled to entirely different codebases, but at least it wasnt a day to day thing (although it was close)

    luckily at my new job everyone above me (including the owner of the company) is technical.  sure we have plenty of non-technical people but they are mostly cluefull and since most things get routed throuh a tech based management things work out pretty well.

    the only real problem we have is overly opimistic schedules (which arent that bad realy, although things are often a little late) and feature creep...

    its a much better situation
    "In America, first you get the sugar, then you get the money, then you get the women..." -H. Simpson
    [ Parent ]

    I got your wider picture right here... (4.80 / 5) (#39)
    by Skywise on Tue Apr 30, 2002 at 04:28:04 PM EST

    What you say is true, DEPENDING on your business.  If you work in a business who's primary function is to build plastic widgets, and you write the code to track sales, then programming is a MINOR part of the business.

    However, if you work in a business where the primary function is to DEVELOP SOFTWARE, your core business is to develop code.

    And if the core business is to develop code... suprise, that's the MAXIMAL part of the business.

    You still need a foundation to run the business to interface with the benefits and taxation.. that's the HR department, and you can even outsource that portion completely.  You'll also need a CEO/Owner/President and some senior management to navigate the business and translate that to the engineering staff.

    The engineering staff is the crux of the problem.  These are not "coal miners".  These are individuals with skill and talent that must CREATE SOLUTIONS on demand.  You might as well say that a Hospital's management staff is more important than the doctors and nurses... cause gosh who's out there finding out what keeps the customers happy?!

    I've been in jobs where the engineering staff was a giant pool of engineers who knew their jobs, did their jobs, and talked to senior management directly with little to 0 supervision.

    On the other hand, I've also been in jobs where the "engineers" might as well have been in daycare because they needed to be told how to code every minute detail.

    Management structure would have been wasteful and overkill in the first job, but the free wheeling attitude of the first would've killed the second.

    Management is NOT the business.  Management "manages" the talent.  But if you have more managment than talent, you have a problem but a very nice org chart.

    [ Parent ]

    Great sentence. (2.50 / 2) (#50)
    by cem on Tue Apr 30, 2002 at 06:22:15 PM EST

    But if you have more managment than talent, you have a problem but a very nice org chart. Great truth.


    Young Tarzan: I'll be the best ape ever!
    [ Parent ]
    Sympathy vote (3.57 / 7) (#13)
    by jabber on Tue Apr 30, 2002 at 11:45:38 AM EST

    Any discussion on this subject, on this board, is moot. But you've got my sympathy vote. +1 section.

    The Manager FAQ

    The Hacker FAQ

    [TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

    Making sure the roles are well-defined (4.44 / 9) (#14)
    by gbd on Tue Apr 30, 2002 at 11:47:41 AM EST

    I work in a matrixed environment, which means that I'm a member of a development shop that has its own management, but we get assigned (matrixed) to one or more technical projects, each of which has its own technical management. My shop manager is responsible for things such as personnel issues, workplace environment, career development, and so on. My project manager is responsible for overseeing the progress of the project and going to bat for us when we need a decision made at the higher levels. Additionally, we have a systems engineer that coordinates a lot of the work that we do with other projects (we have a lot of external interfaces that need to be worked very carefully.)

    Now, this might sound horribly bloated and inefficient, but in reality it works quite well. The reason for this is that everybody knows exactly what their role is, and they don't try to do things that have been assigned to somebody else. My shop manager makes no attempt to dictate technical details about our day-to-day work to us, because he doesn't care. It's not his job. All he cares about is that my project manager is happy with the services that me and my team of developers are providing. My project manager doesn't sit around and make sure that I'm showing up for work in the morning, because that's not his job. And I don't have to worry about coming up with formal schedules and coordinating them with other projects, because that's not my job.

    What this all means is that my team and I are free to do what we're supposed to, which is write code. If I have an issue with another project that is hampering my team's ability to do its job, I take it up with my management and then they go fight the fight for me. I shouldn't have to. It's an example that demonstrates that multiple managers are not necessarily a bad thing. If you've got a bunch of stuffed shirts running around, unsure of what they're supposed to be doing and yanking you in several directions at once, that's bad. But that's not an indictment against management in general... it's an indictment against bad management.

    If you don't think that managers do anything useful, it's probably because you've never had a good manager.

    --
    Gunter glieben glauchen globen.

    Matrixed ... oh dear :/ (5.00 / 1) (#87)
    by thebrix on Wed May 01, 2002 at 05:16:11 AM EST

    The problem with matrix management is when it has degenerated over time (so roles have become blurred) and you, from a non-matrixed company, try to find out who's in charge of something from the outside.

    You contact A who says 'well, B's in charge of that, and I report to him, but he reports to me on this and myself and C on something else'. The end result is rather like trying to find structure in cotton wool and drives people who do have sharply defined roles (typically salesmen who 'need to speak to someone') round the bend :/

    Unfortunately, I've yet to come across an organisation where matrix management hasn't eventually ended up like this ...

    [ Parent ]

    Customers like fancy titles (3.66 / 3) (#16)
    by Builder on Tue Apr 30, 2002 at 11:51:08 AM EST

    We have a similar issue. We're a 6 person team and when I joined we were at 11 people. One thing that we found is that potential customers want to know that there is a 'process' in place to handle their work, and that certain best practice functions happen.

    so now one of the programmers is called a QA manager, one is called a Team Leader, etc. We all still code and manage systems though :)


    --
    Be nice to your daemons
    You're viewpoint is narrow ... (4.28 / 7) (#19)
    by Bad Mojo on Tue Apr 30, 2002 at 12:03:18 PM EST

    This rant isn't unusual. Even I look around and see the same things where I work. But understanding why companies change is important unless you want to end up being the old guy who bitches all the time about how it `used to be'.

    All it takes is one fuck-up. A chain reaction of `how can we fix this' takes place and the first step is new policies. Next comes another mistake and a user's manager is raising hell. More policy. More quality control. More paperwork and project management. It's not that people have started making more mistakes, but less are willing to accept mistakes and management is seen as a way to prevent them. I'm not saying it's the right answer.

    What starts as a system to manage, quickly snowballs into a service which creates its own mistakes and problems. Now instead of making widgets, your company makes widgest and manages a process to make widgets. Both jobs are now spewing out mistakes and whatever gains you had with management are slipping away as the pyramid grows taller.

    Two words, critical mass.


    -Bad Mojo
    "The purpose of writing is to inflate weak ideas, obscure pure reasoning, and inhibit clarity. With a little practice, writing can be an intimidating and impenetrable fog!"
    B. Watterson's Calvin - "Calvin & Hobbes"

    Your theory is wrong. (+1 though for interesting) (3.62 / 8) (#21)
    by BadDoggie on Tue Apr 30, 2002 at 12:08:09 PM EST

    Senior management want to isolate themselves from the "coalface"

    Senior management is a group of people trying to sell a product or service and make sure the product is produced or service is provided. That's it. They are the conductors of the general departmental orchestras, such as Sales, Service and Engineering.

    Middle managers do not understand the technology

    Most middle managers don't need to understand the technology. They need to know how to communicate between the people who do know the technology and the people who don't. They handle timelines and production dates and heirarchies. They write reports for upper management to show stockholders and marketing. They do all the crap that you don't want to because you're too busy coding, but someone's gotta do it.

    Middle managers try to control the techies with the only weapons they understand - procedures, reports and presentations.

    Well, damned if they don't do a lot of this, but "control techies"?? Get off it! The procedures are there so that you know exactly what is and isn't your job. Procedures make sure you get from beginning to end in a controlled, logical, understandable and correct way. Reports let everyone up top know everyone at the bottom is doing his job. Presentations show what the hell is going on.

    Did I mention I'm not in management? I often growl about all the management and all the crap they do, an awful lot of which looks unnecessary, but in the big picture, most of what they do is damned important.

    I think that the Golgafrinchams were right.

    Yup. Now go back and read the book again. They were all wiped out shortly after getting rid of the unnecessary 1/3 due to a virus someone got from an unsanitized telephone. Oh, and humans are the decendants of the "useless" ones.

    woof.

    Truth is stranger than fiction because fiction has to make sense.

    C'mon... it's at least partly right... (4.00 / 1) (#53)
    by hazehead on Tue Apr 30, 2002 at 06:42:00 PM EST

    > Most middle managers don't need to understand
    > the technology.

    <wince> While it's true that many don't require a complete technical understanding of the entire process, think how much better it would be if all middle managers had a background in the tech... they'd have a working bullshit detector, be able to pin down estimates and ask the right questions of the non-techs to draw out the details needed for planning the project and divving up the work.

    > The procedures are there so that you know
    > exactly what is and isn't your job. Procedures
    > make sure you get from beginning to end in a
    > controlled, logical, understandable and correct
    > way. Reports let everyone up top know everyone
    > at the bottom is doing his job. Presentations
    > show what the hell is going on.

    I would start bringing in your own water bottle, the contents of the water cooler at your office is obviously being adjusted to improve employee morale.

    [ Parent ]

    So maybe I'm lucky. (5.00 / 1) (#89)
    by BadDoggie on Wed May 01, 2002 at 05:41:44 AM EST

    I used to own a business. A very successful business. I killed it for personal reasons I ain't going into here. Now I'm not talking about self-employment, which I also did as a tech, but a proper, licensed, tax-paying, contract-making, customer-satisfaction-concerned, people-hiring-and-firing, dealing-with-competition business, and I have the EIN and DUNS numbers to prove it.

    I'm a techie. I don't like business, except it pays the bills and I enjoyed what I was doing.

    As the business grew, I was hiring more techs to do the work Iwanted to do (and the reason I started the business in the first place!), while I was was stuck with ever-increasing piles of paperwork. Tax forms. Contracts. Customer sat. Suppliers. Sales. More contracts. Projections (so I could maybe give some people full-time work instead of contracts or part-time work). More tax forms. Accounting. Phone calls. Keeping up with technology to know what my customers would need in six months or a year. Keeping up with software to make sure my customers exactly the package that did they needed. Getting NFR copies of software and hardware from companies interested in me flogging the stuff for them. Regional hardware service contracts with major supliers. And so on.

    So when did I finally get to break the old P2P crap Windows system and set up logical nodes and subnets like I planned? Never -- jobbed that one out to Joey. Build a bulletproof file server? Nope, Tina had to do it because I didn't have the time, and I'm the guy who doesn't sleep much!

    What I needed from the start was a secretary/bookkeeper. I also needed a middle manager to do all this crap so I could run the business and also do some tech work myself. I needed someone familiar with business processes, HR, customer sat, and other stuff. If he understood hardware and systems, so much the better, but it wouldn't have been as important as the other skills for which I would have hired him.

    Yes, I'd rather not have to explain the difference between CAT-5 and RG58 or what plenum cable is. I don't want to have to explain why router "A" and switch "L" don't go together. I loathe the thought of having to explain that there is no AUTOEXEC.BAT file on a Solaris box. But if the guy knows what he's doing for his job and this will help him do it better, fine.

    If your manager doesn't understand, FFS explain it to him. If he's a good manager, he'll listen and use the new knowledge and insight to make his own job better/easier. Once you explain to a manager why you can't stress test before you debug, he'll be able to tell upper management why they can't have the timeline they want, no matter how many coders they throw at the problem.

    If this doesn't work, go to your manager's superiors (follow the chain of command). If that don't work, find a new job.

    Maybe if you look at it like Formula One:
    Programmers = Machinsts and Mechanics
    Tech Support = Mechanics and Pit crew
    Middle managers = Drivers
    Sales = Sales (for sponsorships)
    Upper managers = Race organisers

    The Driver doesn't have to know about cam positions on the crankshaft and the tension on a lifter spring to do his job, but extra knowledge about the steering linkage may help him judge the turning better. The organisers don't give a damn that the gearshift is on the steering wheel as long as the cars go around the track. Each person has his job to do and together it all works.

    Didn't mean to rant.

    woof.

    Truth is stranger than fiction because fiction has to make sense.
    [ Parent ]

    people persons (5.00 / 2) (#68)
    by christfokkar on Wed May 01, 2002 at 02:33:51 AM EST

    Senior management is a group of people trying to sell a product or service and make sure the product is produced or service is provided. That's it.

    Exactly.  Senior management is selling a product they don't understand.  They hype it to the customers, then turn to the coders to make magic happen.  When the customer calls to say it's still vapor, senior management just yells.  They yell, and threaten jobs, and everybody stays late working on a project that still has no hope of concluding successfully, because they are coding to client demands rather than technical reality.

    Well, damned if they don't do a lot of this, but "control techies"?? Get off it!

    Jesus.  I'd love to know where you've worked that was so supportive and nurturing of techies.  My experience has been that managers do control techies.  They make them feel wanted and loved, but meanwhile they are working them to death.  Techies can't tell the difference.

    I often growl about all the management and all the crap they do, an awful lot of which looks unnecessary, but in the big picture, most of what they do is damned important.

    Management is not unnecessary.  What's unnecessary are managers who don't code.  

    Managers who don't code are just people persons.  All they understand is what they're told, all they have to go on is the force of other people's emotions.  

    When the client calls and yells, the manager gets on the techies' backs.  When the techies yell loud enough, the manager pushes back at the client.

    Whether its feasible, whether its doable, the manager has no idea.  All he knows is how loud the two sides are yelling.

    My second manager was literally an ex poker dealer.  He got the job for that reason.  Meanwhile, this is exactly the problem with the current system.  These people should be on the phone, but they should not be making decisions.

       

    [ Parent ]

    I profoundly disagree (3.33 / 3) (#25)
    by porkchop_d_clown on Tue Apr 30, 2002 at 12:40:32 PM EST

    The whole point of the structure you laid out is to put structure into the software development process. As the architect, you are supposed to be doing the design, right? Would it be better if 10 guys argued about the design, or just did what ever they felt like that day?

    Meanwhile, the QA guy should be looking at what the software is supposed to do, compare that with what you are designing and come up with a list of ways to break your code.

    shouldn't this control be exercised be people who at least have some sort of clue?

    Isn't that your job?


    --
    Uhhh.... Where did I drop that clue?
    I know I had one just a minute ago!


    Is there enough management tasks for 10 people? (5.00 / 4) (#37)
    by mech9t8 on Tue Apr 30, 2002 at 04:04:50 PM EST

    Would it be better if 10 guys argued about the design, or just did what ever they felt like that day?

    No, it would be better if the 10 guys could code.  Instead, there are 6 coders, and 4 guys that aren't supposed to code.  Since the majority of work involved in this case is coding, the other four are sitting around the office trying to look busy and getting in the way of the people actually doing the work.

    It's all a matter of proportion.  For some projects, having 4 non-coding hours of work for every 6 coding hours of work might make sense.  (Note that this doesn't include marketing or legal or accounting, etc.)  For most, I'd say, it doesn't.  Perhaps in bursts - a large amount of QA time at completion milestones, a large amount of management and architecture at the beginning - but I think a lot of the time managers and architects end up sitting around thinking of ways to still be relevant to the project and thus justify their jobs.

    Whilst I appreciate the need for some sort of control (to prevent user's fantasies or geek's techno-lust getting out of control), shouldn't this control be exercised be people who at least have some sort of clue?

    Isn't that your job?

    Your missing his point.  As the technical designer, he should be able to interact with the customer to determine the best mix of customer needs and technical abilities.  Instead, he's got to explain technical things to the manager... who goes to the customer... and tries to explain things to the customer... and picks up customer feedback... and the explains the customer feedback to him... etc.  So instead of the tech architect and the customer getting together and settling issues in an afternoon, it takes weeks - and the customer still doesn't get the best result.  Because all the discussions have to go through the middleman.

    Basically, it comes down to the competence of the manager, whether he is actually helpful in a dialogue between the customer and the technical people, or whether he's a poorly-translating barrier between them.  Many programming shops have the attitude that the programmers are all just trolls that should be hid in the basement and only "qualified" managers should talk to the customers.  When, usually, some of the programmers would be way better at talking to customers than the manager types.

    For many jobs, a "customer relations"-type manager just gets in the way - not adequately explaining the technical abilities and limitations to customer, while not adequately explaining the customer needs to the programmers - and being completely useless at negotiating a compromise when technical and customer requirements clash, because he doesn't understand the issues involved.  Now, that doesn't mean every programmer is better for talking with customers, but you really need someone who can talk intelligently to customers while understanding the programming issues involved - because usually the technical issues are usually far more difficult to understand than the customer requirements.

    --
    IMHO
    [ Parent ]

    Distribute tasks (none / 0) (#64)
    by radeex on Wed May 01, 2002 at 12:47:18 AM EST

    It's all a matter of proportion.  For some projects, having 4 non-coding hours of work for every 6 coding hours of work might make sense.  (Note that this doesn't include marketing or legal or accounting, etc.)  For most, I'd say, it doesn't.  Perhaps in bursts - a large amount of QA time at completion milestones, a large amount of management and architecture at the beginning - but I think a lot of the time managers and architects end up sitting around thinking of ways to still be relevant to the project and thus justify their jobs.

    I agree. The solution to this is to have everyone on the team be a coder, as well as a designer, a project lead, a QA person... XP, basically. That way you don't have "specialized" people who a) get bored with the same work all the time and b) have inconsistent workloads.
    --
    I DEMAND RECOMPENSE!
    [ Parent ]

    arhcitect (4.50 / 2) (#41)
    by Altus on Tue Apr 30, 2002 at 04:59:26 PM EST

    is not a managerial position realy.  you dont manage, you design and then the tech lead manages the group in developing the app.

    if he was the tech lead or perhaps the project manager, then it would be his job to control things.

    belive me, in a way, I agree with you. I think that there does need to be structure, but then again, I have seen cases where the structure so grossly outways the actual work that nothing can ever get done.  I believe that is the situation that he is trying to describe.
    "In America, first you get the sugar, then you get the money, then you get the women..." -H. Simpson
    [ Parent ]

    Where I work... (4.57 / 7) (#30)
    by webwench on Tue Apr 30, 2002 at 02:04:24 PM EST

    Where I work, we have two major issues that tie in with what you describe.

    First, the software development groups have reached critical mass, where too much emphasis has shifted from putting out a good product towards managing the process of putting out an app, and doing CYA with regards to the app. This leads to more and more people getting involved with the process. In our case, it means that with even small projects, we end up hauling around the sort of manager-overhead that is only appropriate to larger efforts with more user groups.

    Secondly, for some reason the company does a poor job of hiring and developing some of these roles (specifically the team lead, project manager, and product manager roles). Hence we have product managers who don't have any idea how to go about determining a need, collecting requirements for a new application, or communicating with their users; we have project managers who don't know how to write specs, make project schedules, or communicate between technical and non-technical staff; we have team leads who don't know how to manage coding resources, don't know how to delegate, are unable or unwilling to assist or lead their teams, etc.

    It's a combination of out-of-control process-mongering and some poor fits between people and their jobs.

    When the process is flexible and fits the situation; when the project itself is well-conceived and makes business sense; when the right people know how to perform the right jobs; when the people doing the grunt coding work are up to par; things work well. The problem you describe is more complex than "Too many managers".

    Not Limited to UK (none / 0) (#31)
    by bouncing on Tue Apr 30, 2002 at 02:27:22 PM EST

    I assure you this is NOT limited to the UK. This kind of thing has been going on in the US for years, and cartoons like Dilbert and movies like Office Space have satired it.

    Nothing new here.

    It is getting fucking ridiculous (4.75 / 4) (#32)
    by MSBob on Tue Apr 30, 2002 at 02:36:52 PM EST

    I worked in an organization that will remain unnamed to protect the guility. I was on a development team that was designing a Windows based media player that was supposed to work with UDP packets. In essence it was a WMP input filter (those familiar with DirectShow know what I mean). Anyways it was probably enough work for two people and there were two full time developers on it. In addition to us two we had the following persons to directly report to:
    • Product Owner
    • Product Manager
    • Project Manager
    • Technical Architect
    • Functional Architect
    • UI Architect
    • Product release co-ordinator
    • Two or three others whose titles I don't even remember
    All those people contributed jack shit to the overall product quality but they were all there 'overlooking the progress' and consequently cashing paychecks far bigger than me or the other guy who was also doing the coding (read: doing real work instead of waving MS-Project graphs).

    Obviously the company could not exist in such a state and they subsequently shed 40% of their workforce (aka dead weight). But even now being meaner and leaner they are a shitty place to work for as they treat programmers as the lowest life form which is also reflected in their pay schedule. Needless to say I don't work for that organisation and don't expect them to be around for very much longer.

    I don't mind paying taxes, they buy me civilization.

    Methodologies (none / 0) (#101)
    by thebrix on Wed May 01, 2002 at 08:53:14 AM EST

    On the Tube a couple of weeks ago I noted someone reading a manual for PRINCE, which appears to be some sort of precast business process.

    Did your former organisation use it perchance? If similar things are used widely it explains much; I've never seen so much deadweight and fee-eating ('Design Authority Teams' with about 9 people and flowcharts to tell them when to go to the toilet, plus about 20,000 other teams).

    Certainly, on your list, the 7 named roles have been run by 2 or 3 people at most in situations I've worked on, plus possibly a part-timer or two. (The unnamed roles are presumably completely redundant).

    [ Parent ]

    Gateway process? (none / 0) (#106)
    by MSBob on Wed May 01, 2002 at 10:20:14 AM EST

    They called a 'gate' or 'gateway' process where each stage was accompanied by a 'gate kickoff' meeting or something. To me it looked just like a mutated waterfall except with more meetings and more dead weight.
    I don't mind paying taxes, they buy me civilization.

    [ Parent ]
    Project managers (2.00 / 1) (#36)
    by El Volio on Tue Apr 30, 2002 at 04:03:38 PM EST

    I've always compared most "project managers" to the old Communist Party official on Soviet naval vessels... you can figure out the rest of the analogy for yourself.

    When I was at Andersen (of all places) (3.66 / 3) (#42)
    by greyrat on Tue Apr 30, 2002 at 05:05:02 PM EST

    I learned that managers are the people who hold out their arms and block all the shit from above from falling onto the developers. Look closely at what your immediate boss does, and what his boss does. You might just see that they make your work life bearable (even enjoyable) by handling all the crap you'd have to be doing instead.

    Contradict me all you like. When you're older and/or more experienced, you'll see that it's true.


    ~ ~ ~
    Did I actually read the article? No. No I didn't.
    "Watch out for me nobbystyles, Gromit!"

    It may be the case... (4.50 / 2) (#47)
    by bobzibub on Tue Apr 30, 2002 at 06:11:07 PM EST

    ...that managers do deflect crap from tech staff, but there are managers higher still throwing it in the first place.. The "prime-movers" if you will.  This still does not change the fact that often when the number of managers grow the work grows as a result.

    Once you are older (as old as I am) you will see this to!  ; )

     

    [ Parent ]

    some of that crap (5.00 / 1) (#71)
    by QuantumG on Wed May 01, 2002 at 03:26:59 AM EST

    is things like "When are you going to have this new release done? WE WANT TO SELL IT" which is really what the company is all about: making money. Forget learning this in some insulated little corporate environment, go start your own company or join a startup with 5 people, you'll see why all these jobs are necessary.

    Gun fire is the sound of freedom.
    [ Parent ]
    From the description in the article... (none / 0) (#48)
    by magney on Tue Apr 30, 2002 at 06:11:09 PM EST

    ...it sounds, then, like the article author's boss is simply not doing his job.

    Do I look like I speak for my employer?
    [ Parent ]

    hmmmmm..... circular arguements, anyone? (5.00 / 1) (#51)
    by hazehead on Tue Apr 30, 2002 at 06:24:05 PM EST

    While I do agree with this (my PM certainly insulates me from lots of shit that is picking up speed on its way downhill) I'm not sure it's a valid argument. The reason that they have to insulate you in the first place is because of procedures and politics put in place by a small army of middle managers.

    I do see the value of some middle managers to provide "executive summaries" of what is going on... condensing things into 10,000 foot views of the progress on projects, but the majority of them simply build MS Project files from templates, collect weekly progress reports, put ballons in your cube on your birthday and fill out the HR forms.

    A really good Project Manager, one that knows the art of requirements gathering and can distill them into specs is invaluable. System Architects that make well informed decisions on platforms and methodolgies are awesome. But when someone is simply an "IT Manager", an alarm goes off in my head.

    I think that your line "When you're older and/or more experienced, you'll see that it's true." should read "When you've been ground down by the system long enough, you'll learn to question the structure less."

    [ Parent ]

    requirements gathering (3.50 / 2) (#70)
    by QuantumG on Wed May 01, 2002 at 03:25:12 AM EST

    is not the job of a project manager. Get a clue.

    Gun fire is the sound of freedom.
    [ Parent ]
    who's job is it? (none / 0) (#116)
    by hazehead on Wed May 01, 2002 at 01:47:25 PM EST

    We have an entire training class at our company dedicated to "Requirements Gathering" for PMs. Every PM I've ever met has been involved with documenting the requirements for a given project as part of their job. This is required in order to build estimates and determine costs. I consider determining scope and the requirements of a project one of the key tasks of the project manager, but perhaps this is a result of the environments I've worked in.

    Who should handle this task, if not the PM?

    [ Parent ]

    Good comment except: (none / 0) (#105)
    by greyrat on Wed May 01, 2002 at 10:12:24 AM EST

    "When you've been ground down by the system long enough, you'll learn to question the structure less."
    No. When you've decided that pissy, self-centered idealism is what's actually a crock and real life is worth experiencing, then you'll see that what happens is what happens and the way it works is the way it works. Enjoy it.
    ~ ~ ~
    Did I actually read the article? No. No I didn't.
    "Watch out for me nobbystyles, Gromit!"

    [ Parent ]
    okay, i was a *little* pissy... sorry 'bout that (none / 0) (#117)
    by hazehead on Wed May 01, 2002 at 01:54:54 PM EST

    I like idealism, you gotta be willing to buck the system a bit in order to improve it. I think experiencing real life means you have to go outside the boundries once in a while, if only to look back and get an idea of why they exist in the first place.

    "...what happens is what happens and the way it works is the way it works." is an awful sentiment to live by. If everyone questioned the way things work a little more I think we'd end up with a lot of improvements.

    My 1/50 of a dollar...

    [ Parent ]

    You left off the important part (none / 0) (#118)
    by greyrat on Wed May 01, 2002 at 02:59:12 PM EST

    Enjoy it. Not as in "bend over and...".

    I do buck the system and improve it. I wouldn't have survived in QA and testing if I didn't make things better. The increments of improvement are just smaller than you are willing to accept right now. I manage a good balance between making the bosses nervous and having them understand how useful it is to have me around.


    ~ ~ ~
    Did I actually read the article? No. No I didn't.
    "Watch out for me nobbystyles, Gromit!"

    [ Parent ]
    Exactly! (5.00 / 1) (#60)
    by porkchop_d_clown on Wed May 01, 2002 at 12:06:59 AM EST

    Actually, I would argue that the best managers are the human bidirectional bullshit filters. Important stuff passes through in either direction, garbage (from either direction) gets shunted to the side.

    Having worked for some truly brilliant idiots I don't care what other people say: technical skills are way secondary, the management skills are both essential and more rare.


    --
    Uhhh.... Where did I drop that clue?
    I know I had one just a minute ago!


    [ Parent ]
    If only... (none / 0) (#73)
    by Herring on Wed May 01, 2002 at 03:54:16 AM EST

    That's certainly what they're supposed to do. I have encountered a couple of managers who do this well whilst leaving me (the chief techie) to get on with my job. Maybe it is arrogance, but I object to spending hours explaining the rationale behind complex technical decisions to people who have no hope of understanding. I'm paid to be a guru - trust me.


    Say lol what again motherfucker, say lol what again, I dare you, no I double dare you
    [ Parent ]
    Some Pointers (none / 0) (#46)
    by levsen on Tue Apr 30, 2002 at 05:55:22 PM EST

    I think there was a discussion about this the other day on /. because of some book called Managing Einsteins. I bought it but haven't read it yet. :) The other side is in the book How to Work for a Jerk. :)
    This comment is printed on 100% recycled electrons.
    Bingo! (4.50 / 2) (#49)
    by cem on Tue Apr 30, 2002 at 06:13:35 PM EST

    I'm now 28 years in the business and I can only fully agree with you.

    This is not just a UK thing. It's worldwide.

    The management is afraid of loosing control of the projects and they don't trust their people. They are in fear that projects will fail and they will loose money, image and their jobs. And they want to make careers ...

    In such an atmosphere there is no creative work possible. No innovations will be brought to life. People are buried live.

    Despite that the solutions are getting more complex and you will need more planning efforts and more management then before. But not at such a degree as we have it now.


    Young Tarzan: I'll be the best ape ever!

    Innovation (5.00 / 2) (#76)
    by katie on Wed May 01, 2002 at 04:06:41 AM EST

    "No innovations will be brought to life"

    I like that one. I keep trying that at places. "Hey why don't you try <idea>"

    "We can't do that!! The project might fail!!"

    "Hey - your track record shows that using your old methodologies the project will DEFINITELY fail.."

    The trouble is that the planning turns out not to be planning the work. It becomes planning the *project* - organising who's going to which meetings.


    [ Parent ]

    Maybe ... (5.00 / 1) (#90)
    by cem on Wed May 01, 2002 at 05:42:52 AM EST

    ... the sentence is a result of my poor funny Tarzan-like English.

    People invest a lot of time and effort just to find a reason why something should not be done. Or is impossible. Or is ridiculous. Or too strange. Or too far away. Or ...

    And them meetings ... oh. "Meetirism" we call it. You can meet youself or any project or organization to death.

    ;) cem


    Young Tarzan: I'll be the best ape ever!
    [ Parent ]

    Meetings (5.00 / 1) (#92)
    by katie on Wed May 01, 2002 at 06:06:34 AM EST

    Someone, I can't recall who used the phrase "The meetings become the project" in a book.

    It's a great phrase. It sums up how large projects go off track.

    Unfortunately to a lot of the manager classes they start off on this track, because the meetings are the only bit they understand. The current project has only one, half-hour meeting a week {because my time is "expensive" because I'm a consultant so they don't want to waste it}, but that never happens, because the managers are spending all their time in other meetings. They're so busy being "busy" they haven't got time to do the actual work...

    Everytime I ask things like "can you ask the customer to clarify <this>?" the reply is always "not today, in meetings all day, not tomorrow... how about we get together early next week and discuss it..."

    [ Parent ]

    What exactly ... (none / 0) (#111)
    by cem on Wed May 01, 2002 at 12:22:33 PM EST

    ... is then the work of a manager? To communicate and keep things on track. This happens sure thru meetings. But the regular case is that in a normal management environment the meetings have no real result and things very often are postponed or escalated to higher management because none of them wants to take responsbility for a desition out of angst.

    I would put up a rule: The larger the organization the larger the angst.

    This was terrible english I suppose. But you get the point.


    Young Tarzan: I'll be the best ape ever!
    [ Parent ]

    It depends (4.66 / 3) (#52)
    by bugmaster on Tue Apr 30, 2002 at 06:35:10 PM EST

    It all depends on the project, and on the actual management in question.

    At my old company (now defunct), we went from "no management" to "excessive management". At first, we had 10 coders and one project lead, who was basically also a coder. We ended up re-writing everything from scratch about 8 times, because the code was a giant hack each time, no structure to it whatsoever. During the end days, we went to the other extreme: we had about 4 coders and 6 managers. Most of the managers were walking buzzword engines; they were worse than useless. And the people that talk to the customers had a very clear policy: agree with everything the customer wants, and ignore the developers. No wonder the company is dead.

    However, at the place I work now, the coder:manager proportion is about 6:4. However, the managers are actually competent. For example, whenever the customer wants anything suddenly, they call a meeting; the technical lead explains to them why it can or cannot be done; and then the customer has to withstand 4 people telling him "you can have it done on schedule, or we can implement your changes in 3 more years". Developers are also paid attention to; if I say, "this part of the project might take me a while... maybe 2 weeks", I can expect 4 weeks to be allocated in the project plan.

    Unfortunately, I believe that my situation (competent management) is quite rare. If I were to choose between "no management" and "incompetent management", I'd choose the former. Incompetent PHBs are worse than poison.
    >|<*:=

    A highly naive and uninformed post. (2.80 / 5) (#55)
    by EricLivingston on Tue Apr 30, 2002 at 07:59:39 PM EST

    This is a very misdirected, naive post by a programmer who clearly can't see the big picture of what it takes to create highly complex, modern software systems. Why does this kind of whining make the front page?

    So, the ideal model is to have 10 out of 10 people doing nothing but code 100% of the time? You remind me of the classic Dilbert cartoon in which the PHB tells the team "Just start coding and I'll go find out what the users want."

    Maybe whatever simplistic, easily conjured program you were writing back then could be pulled off with absolutely no one focusing any informed attention on architecture, UI design, proper requirements gathering, or project management (i.e. timeline, budget, coordination with other departments such as marketing, documentation, support, etc). And perhaps you and your team were such coding gods that no QA was required at all (which follows from a 100% coding resource allocation).

    But in the real, modern world non-trivial software in an enterprise requires the coordination of several teams and needs several distinct and deep skill sets. Yes, UI design is actually something one can spend a full-time effort on. And yes, architecture can in fact take more than a napkin sketch over lunch (in theory you should know this, as a supposed architect, but perhaps you've never worked on complex software). And yes, real QA of a complex, distributed, multi-tier application can in fact require people who are dedicated to just that (not to mention a team that is separate from the programmers. I guess your model is to have the fox guard the henhouse and allow coders to "QA" their code in their "spare" time when they're not coding 100%).

    Your problem is with BAD management - managers and other non-coders who suck at what they do. I have no argument with that beef. And perhaps here and there you'll find a role that is truly vapor and/or unnecessary for that application. But to claim that in all cases any non-coding role is meaningless and of no value is simply ludicrous, as anyone who's been involved in any kind of modern, non-trivial development effort can attest.

    XP (5.00 / 1) (#63)
    by radeex on Wed May 01, 2002 at 12:29:55 AM EST

    Just curious - have you ever taken a look at XP? The author of this article mentions it. The point is that you have your entire staff doing many different things, commonly trading places. So, that way, everyone is a coder, everyone is a QA person (argh, all coders should QA their own code anyway!), everyone talks to the Customer, etc. Check it out.
    --
    I DEMAND RECOMPENSE!
    [ Parent ]
    Maybe I should've re-titled. (5.00 / 1) (#72)
    by Herring on Wed May 01, 2002 at 03:49:22 AM EST

    "There are too many bad managers".

    My beef is with the fact that we used to be able to produce highly complex software which did what the users wanted without the "help" of the hordes of incompetents who have to get involved these days.

    I am attracted to the idea of XP. I have noticed in the past that test plans, code reviews and a very high level of user involvement have all been a factor in the most successful developments. Endless Gantt charts and status reports seem to have no positive effect.


    Say lol what again motherfucker, say lol what again, I dare you, no I double dare you
    [ Parent ]
    Lack of trust? Ease of producing paperwork? (none / 0) (#100)
    by thebrix on Wed May 01, 2002 at 08:45:00 AM EST

    A couple of years ago I that I'd been doing things very similar to XP for years without knowing it had a name :)

    I think much of the problem is lack of trust - 'get it in writing' - although I'm not sure where this lack of trust has come from. Fear (real or imaginary) of litigation?

    Certainly paperwork has to be ploughed through in the most improbable places; my late mother gave up Girl Guides, after about 40 years in the movement, because the amount of information that had to be reported to HQ became colossal and sucked the fun out. Of a voluntary activity, for goodness' sake!

    Another thought is that paperwork has become easier to produce and gives the impression that somebody, somewhere, is doing something; I just missed the days when there were few PCs around, final copies of documents went to the typing pool (and came back a few days later), slides were drawn by hand, and deliveries were by post.

    [ Parent ]

    XP is NOT what this guy is talking about (none / 0) (#94)
    by EricLivingston on Wed May 01, 2002 at 07:48:06 AM EST

    You said it yourself - under XP (which I have directly experienced) "Everyone is a coder, everyone is a QA person, everyone talks to the customer, etc"

    Note how under XP coding is NOT 100% of anyone's activity. What the original poster pined for were the days when no one did ANYTHING except code - 100% coding all the time. He was even disparaging towards the 20% that one person spent doing "admin crap".

    My point is simply this - that if you take this guy literally and have absolutely everyone on the team doing nothing but 100% coding, with nothing else going on in the project at all, you will likely fail big-time unless you're talking about a small team writing something not very complicated, and with no need to coordinate with anyone not on the coding team (such as document writers, marketing folks, the client, etc)

    [ Parent ]

    I'll tell you exactly where those days went (3.50 / 2) (#56)
    by EricLivingston on Tue Apr 30, 2002 at 08:12:30 PM EST

    They went nowhere - you'll still find small groups of individuals who band together an crank out code in some basement somewhere, and even get paid for it sometimes. The phenomenon you've noticed is simply the evolution of the business.

    Compare what you're seeing with aviation, or construction. In the Wright Brothers' time, if you wanted to build a plane, you got a bunch of folks together, sketched something out, and hammered and sewed away until you got something that stayed in the air. Similarly, if you lived on "Little House on the Praire" and needed a new house, you got some friends together with some tools and some wood, and you hammerd and sawed until you had something that looked like a house.

    Nowadays, one doesn't do that and expect to get paid. Now you have "overhead" positions like aircraft quality inspectors, designers, and other roles. You have folks like architects that never lift a hammer or a nail. If you feel these people are unnecessary, try building a 747 by handing a bunch of folks some tools, sheet metal, wires, etc, and say "go for it!". Try building a skyscraper by handing a construction crew some raw materials and say "start building."

    These "useless", "non-working" roles are absolutely required in todays highly complex, evolved business software engineering environment. The fact that you don't recognize that at all is simply a by-product of you not having any idea how to create complex software.

    useless, non-working roles - my experience (3.50 / 2) (#57)
    by bayankaran on Tue Apr 30, 2002 at 09:23:55 PM EST

    My experience of the last 4 projects - two of those projects had good managers who did understand the complexity the scale and had the whole picture in thier mind. The rest were powerpoint eating idiots.

    [ Parent ]
    You're obviously not an engineer... (4.66 / 3) (#58)
    by Skywise on Tue Apr 30, 2002 at 09:49:02 PM EST

    The phenomenon isn't "evolution of the business".

    It's still very possible for one man to build a jet airplane and it happens. (I, personally, know someone who's designed and built his own dragonfly style, powered aircraft...)

    It's still very possible for one man to build his own house out of wood (or bricks or concrete or aluminum, or whatever it is you think passes for modern building materials today...)

    And he could build a 747 and a skyscaper too, if he had enough of a lifetime to do it.

    But there are too many people who want what you have, and it's no fun to spend the rest of your life building the exact same thing to fulfill your orders...

    Enter assembly line manufacturing processes pioneered by Ford.  Rather than having 1 skilled craftsman churning out 1 car requiring 365 assembly steps every year.  It was far more efficient to have 365 LIGHTLY SKILLED employees (each one knowing and performing only one task) churning out one car a day.

    So management (because management is only trained these days to think about costs and assembly line style production, and not about how to actually produce product) thinks everything is an assembly line answer waiting for a question.

    What's this have to do with software?  Glad you stayed with me...

    Software CANNOT BE PRODUCED THROUGH ASSEMBLY LINE MEASURES.  Software CANNOT BE PRODUCED BY PROCESS.  Now you can write all the flow charts, UML charts, and all the documentation you want.  You can put as many UI designers and QA people and Use Case developers on staff as you want.  And it won't mean squat to your software engineers.
    Writing software is a "creative" process.  You don't just put a nail into a board.  You don't bolt the bumper onto the back of the car.
    You imagine the bumper in your head, and then you model it inside the program.  And no amount of documentation will facilitiate that process.

    Now, if your big-bad-complexly-evolved-super-b2b-peer2peer-XML loaded-AI systems you're referring to are really banking softare or web sites...
    You're right.  Because those no longer involve Software Engineering.  They can all be done with drag and drop VB or C# GUI design and standard algorithms out of a book and you're right back to assembly line processes that require far fewer skills than say, a Software Engineer who can write an OS.

    Which, of course, requires at least 50% management "overhead" because they're not going to have the skills to see outside their little box.

    [ Parent ]

    Absolutely. (none / 0) (#62)
    by radeex on Wed May 01, 2002 at 12:16:23 AM EST

    It's not enough for someone to know about their little bit of code on the project. To effectively design software, I think, you need to have a much broader knowledge of what you're working on. Of course, this doesn't work for "big software", but perhaps "big software" is a myth? discuss. ;-)

    Relevant story: Confessions of an Unrepentant Code Commando
    --
    I DEMAND RECOMPENSE!
    [ Parent ]

    Big picture (5.00 / 2) (#75)
    by katie on Wed May 01, 2002 at 04:01:43 AM EST

    If that's the case, the management need to understand software developement.

    The project plan for my current project has something of the order of 17 stages. 16 of them are about completing paperwork. One of them says simply "Write application". Because no-one here understands what happens in that phase.

    The rise of a "Professional Manager" class has led to people who think the paperwork is important. Making a building or a plane or a peice of software is a sort of byproduct.


    [ Parent ]

    god (none / 0) (#84)
    by QuantumG on Wed May 01, 2002 at 04:47:48 AM EST

    For a start, scientific management has been out of vogue for a good 15 years, but ignoring that point, some software can and is developed in a production line model. People who develop to a disciplined process will tell you that their jobs are less stressful, they're more productive and their company makes money. If you wanna be "creative" go buy yourself a paint set. You're not an artist, you're an engineer, act like one.

    Gun fire is the sound of freedom.
    [ Parent ]
    God (none / 0) (#113)
    by Skywise on Wed May 01, 2002 at 01:23:00 PM EST

    Yeah, software can be produced in a production line model.  I said so myself in my post.

    That's not ENGINEERING.  That's called ASSEMBLY.

    From previous posts, you imply that you're a civil engineer working on bridges.  So let me put it this way.  99% of all of the bridges you'll ever build have already been built.  There's customization involved in the individual implementation.  But no one is going to buy a bridge design from you that you just thought up last year.

    This is not true of software engineering (yet).  If you're building a banking system, or web site, yeah... the underlying design is pretty much standardized to a point where creativity is kept to a minimum and handled by high-priced people who  don't understand a thing about engineering, but know what they like, so they'll tell you how to make it.
    But what constitutes the latest in software technology changes almost every day.  Standardized techniques, books even beginning to explain the underlying concepts are years behind.  So coding to the bleeding edge is very much a CREATIVE endeavour.  It's why I like *being* a software engineer.  Because that way I'm not some slave to a process, where I may as well be an assembly line worker with the UAW because the benefits are far better.

    [ Parent ]

    Management != Assembly line (none / 0) (#96)
    by EricLivingston on Wed May 01, 2002 at 08:04:14 AM EST

    You're confusing two concepts - assembly-line production and high-leverage production, the key difference, in my mind, being flexibility and mentorship from senior members of the group.

    Sure, one guy could build a house. Would you ever pay for that? Not unless you were a fool. Why? Because such a man would be an extremely skilled professional billing at very high rates, and you'd start to feel a bit queasy knowing you're paying this fellow $300/hr just to hammer up some drywall at times.

    That's one key reason you have teams - let the $20/hr person tack up drywall while the $300/hr person figures out how to design your bathroom in a way that meets all your requirements. In the same vein, if all jet planes were built by hand by skilled individuals, they'd be priced out of just about any market imaginable. That's one reason why prototypes (which are built by individuals or very small, skilled teams) cost millions.

    Same with software - it's just stupid to have the guy with years and years of deep experience in high-speed transaction processing, for instance, placing buttons on a GUI dialog box most of the day, when a freshly minted CS major out of college could be doing it just fine.

    And that's when you start getting into non-coding "admin crap." Because somebody's got to watch over those junior folks and make sure they're not screwing it up. Somebody's got to lead them along, mentor them, teach them the ropes, and grow them. Experts need to periodically put down their tasks and review the code of more junior folks to ensure it's up to spec, just as a sr. foreman on a construction site will periodically inspect the work of his crew. Work like this is crucial, is not coding, and is not "admin crap."

    This is just one example of why coding 100% is just a dumb idea and not a model that any intelligent client would want to pay for.

    [ Parent ]

    Management := Assembly Line (none / 0) (#112)
    by Skywise on Wed May 01, 2002 at 01:04:53 PM EST

    No.  I'm not confusing two concepts.  "High-leverage production"  (IE Peer-to-peer or master/journeyman production) is still production without management.

    You're mixing all of your "management" groups together. Exec's are responsible for steering the business and generating income flow.  Management's sole and only purpose is to oversee labor and see that product P is developed to specification S by time T.  I said it before, I'll say it again. Management, at its best, facilitates production.  Management has not, will not, and will never cause a product to be produced because of its existence.  Engineers, however, can produce a product without management.

    There seems to be an misguided assumption in your logic that just because a coder doesn't have a maangement person overseeing his work, his work will not be up to spec.  I say, if the coder can't code to spec, it's time to dump the coder and find someone who will.  Not pay another guy twice his salary to sit over his shoulder and make sure he's doing it right.

    And yes, I would buy a house built by one person.  So long as his price is reasonable for the house.  I'll spend a little more for a guy who takes pride in his work and craftsmanship over a slapped together model built by immigrant labor paid $5/hour but charged to me at $50/hour any day.


    [ Parent ]

    The problem... (5.00 / 2) (#66)
    by webwench on Wed May 01, 2002 at 01:36:14 AM EST

    The problem is that the managerial equivalent of a Boeing design team is applied to the project equivalent of a kite.

    [ Parent ]
    backwards (none / 0) (#67)
    by christfokkar on Wed May 01, 2002 at 02:05:41 AM EST

    No, you have it backwards.  The problem is that the managerial equivalent of a kite is applied to a Boeing.  

    Software is complex.  The managers are not.


    [ Parent ]

    I dunno... (none / 0) (#114)
    by Skywise on Wed May 01, 2002 at 01:31:58 PM EST

    What really is the difference between the mars rover which had very little management and cost under a million to build, and the mars probe which slammed into the planet which cost billions of dollars and had tons of management...

    [ Parent ]
    Ah! (none / 0) (#121)
    by webwench on Wed May 01, 2002 at 03:44:26 PM EST

    Problem, rephrased: A management team with the strength in numbers appropriate for a Boeing design team, where each management team member is qualified only for metaphorical kites, is applied to projects of any size.

    Summarized: Doomed to failure :)

    [ Parent ]

    Exactly. This is why MS rocks my world (none / 0) (#123)
    by memerot2 on Wed May 01, 2002 at 04:36:39 PM EST

    Fuck open source. People just making code, only coders collaborating? What good software could ever possibly come out of that? No, give me the many layers of middle management at Redmond, the proven model to make non-buggy, non-crashing, secure software.

    [ Parent ]
    Complex software (none / 0) (#125)
    by memerot2 on Wed May 01, 2002 at 04:52:08 PM EST

    PHPNuke, PostNuke, Tcl/Tk, Perl, Python, Zope, MySQL, Linux, HTML - how many middle managers were involved in creating any of these? Would middle managers have helped? Or hurt? Most were driven by one person or a small group (at least at the beginning). There are other ways (better ways) of working. Groove is a promising direction, facilitates group interaction, leaves a paper trail (well.... bit trail i guess) of all decisions made on a project, all docs, emails, etc. Designed to allow people to work together without managers. What would a manager of a Groove group do? THERE is an example of a highly evolved system that pushes the focus to the fringes of an organization and allows people to work. Centralized bureaucracy is inherently inefficient and the different power levels between 'worker drones' and 'managers' and 'queen bees' automatically produces problems as people below lie to the people above and tell them what they want to hear. And then turn around and yell at the people below to hurry up and produce because the guy upstairs is making these impossible demands.

    [ Parent ]
    The problem here is... (3.50 / 2) (#65)
    by porkchop_d_clown on Wed May 01, 2002 at 01:24:22 AM EST

    People are confusing crappy managers (which are common) with the idea that management is bad (which is patently untrue).

    I will readily admit that while I have worked for 10 or 12 companies in my career I have only known one or two really good managers. Most of the rest were either MBAs looking to climb the ladder as fast as they could or (more common) geeks who had been promoted beyond their abilities.

    Personally, I would rather you staple one of wiredog's posters to my forehead (picture side facing me) than have you promote me to management again. I know what I am - a damn good code grinder. I also know what I am not - a manager or anything approximately like one. I wish more people knew the difference.


    --
    Uhhh.... Where did I drop that clue?
    I know I had one just a minute ago!


    Danger of too many people (not just managers!) (5.00 / 1) (#88)
    by thebrix on Wed May 01, 2002 at 05:31:53 AM EST

    In my twelve years in IT what has worked best, for 'small to medium' projects (less than about a dozen people, possibly liaising with other organisations in other locations), is:

    - a small team of developers, architects, designers, whoever is needed;

    - one person who is the 'coordinator' or, if you like, 'team leader'; they do their own technical work, manage the team day-to-day and report monthly, or when needed according to their best judgement if problems arise, to the manager (in about a 9:1 ratio of technical:coordination - no need to overcook things!);

    - one manager working part-time on several projects who keeps an eye on things, deflects stray bombs, and only intervenes directly when asked to by the coordinator.

    This stops anyone becoming bored, means there isn't a person or people not up to speed with what's happening constantly interrupting, and keeps things flowing. That the coordinator does technical work is crucial. (Also, I encourage the team members to work on their own, or in ad hoc groups, with clients and/or partner organisations as long as I know what's happening; they're intelligent people and channeling their communications through one person would be silly, as well as insulting).

    Putting too many people at any of the three levels is dangerous; as soon as alternative channels of communication open up, or passengers appear, there's trouble ahead.

    (I admit to being greatly helped by the fact that, in my company, it's fairly certain everyone will be competent or capable of learning).

    [ Parent ]

    I'm amazed (4.75 / 4) (#91)
    by cem on Wed May 01, 2002 at 05:50:28 AM EST

    k5 is the work of two guys ("great work!"). Blogger is also the work two ("simple as that!"). A lot of other - maybe the most - interesting tools and sites today are the work of one or two people who realizes their ideas and put work in it. Fantastic!!>p> That shows me you can change the world by innovation (and transpiration) with a small team or even alone. You need no managers for this. And this works! And is very productive too ...

    THINK! and then JUST DO IT!


    Young Tarzan: I'll be the best ape ever!

    Engineers don't scale linearly (5.00 / 3) (#95)
    by bored on Wed May 01, 2002 at 07:53:37 AM EST

    You touch on a couple of serious points but like myself got trapped in rant mode. As other people have pointed out there isn't anything wrong with 'managers'. The problem may be that they tend to reproduce faster than the programmers. Part of this is because of the misnomer that no one seems to understand how to make quality software. I concluded a while back that this is complete crap.

    Manager / business types see the single engine prop plane created in a garage in 4 months and figure that if they can make a 737 in a year then they see $ signs. They then proceed to hire a couple engineers (after all if 1 engineer can build a little single engine plane by himself two should be able to build a two engine jet), give them double the time and expect a quality 737. What happens though is that they fail to realize that while building a 737 isn't as complicated as building a 747 its a LOT more difficult that just a single engine prop. So a year later they are scratching their heads thinking "we must have hired a couple of bozo engineers" they come to the conclusion what is needed are more engineers. After all, hire enough of them eventually two will prove their worth and get the product out the door, at which point you can just fire the other ones. What they fail to realize is that engineering teams don't scale linearly (see the mythical man month, 20 years old and still no one gets it) and that it still takes time. Two engineers don't get it done twice as fast, and four engineers sure done get it done 4x as fast, its more likely that 4 engineers get it done 2x as fast it they have been working on it from the beginning. The 777 was a decade long effort by a large ( 10,000) engineering team. I guess this must have something to do with lack of math skills (otherwise they would be engineers right :>), everything is a linear plot for my managers.

    Anyway, what i've seen is (ex engineer) business man comes along. He gets it and hires a manager type to calculate the cost and time requirements as well as to build a team to build the idea. The manager type completely screws up and promises everything in 6 months with 4 engineers. The business guy is skeptical but buys it because he figures heck how far off could this guy be? So the manager type hires a couple of engineers to build the product, and a couple sales and HR people to get ready for a product in 6 months. 6 months goes by, the product is missing most features and buggy. The sales, HR and now support people have staffed their teams larger than the engineering department (because they accurately predict the requirements to sell the product) and the engineers are catching crap for missing the schedule. The solution from a management perspective is the patented 'more engineers'. So the new engineers come on and instantly blow productivity away for 3 months while they come up on the product complaining its a nasty mess. The old guys just nod and point out that it was written in 6 months. A year into it the product is marginally beyond where it was 6 months ago, hire more engineers. This continues until the company goes under or they manage to finally release a product. It doesn't help the financial situation that there are 3x as many people working 'support' roles than there are engineers.

    Who gets blamed for this whole mess? The overdue and low quality engineers of course. Its their fault they couldn't produce to schedule or build a reliable schedule. Where is the real problem is that when the engineer often says this will take me a year, the business guys come back and say you don't have a year, get it done in 6 months, like it was some kind of negotiable deal. Predicting the future is HARD. We don't expect the weather man to predict the rain with 100% accuracy, so when he says 10% chance of rain and it rains its accepted. While the engineer says i think it can be done in 2 years he means there is a 90% it can be done in 2 years, when the manager says you have 1.5 years the engineers says fine, there is a 60% chance we can get it done. The managers type never gets in the shit for taking the gamble, only the engineer for being wrong. These are the situations the cause professional labor organizations to form. Ever wonder why law, medical, airline, auto, etc workers are paid more and treated better?



    Managers & Mythical Man Months (none / 0) (#97)
    by mjs on Wed May 01, 2002 at 08:04:18 AM EST

    (see the mythical man month, 20 years old and still no one gets it)

    I disagree: many managers get it, the problem is that the concept is the antithesis of management.

    Management is the physical manifestation of the concept of anti-entropy: everything has order, is subject to rules, and with enough of it all problems can be overcome up to and including the heat death of the universe. The "mythical man month", on the other hand, represents entropy and the decay of the proton. Software 'engineering' is closer to quantum foam, popping into and out of existance in an essentially random manner, than it is to, say, a bridge. As you say, some things just aren't linear and software engineering is one of them. To a manager, this kind of thing is heresy, or possibly blasphemy, threatening the order and logical progression of events which forms the pinions of their 'profession'. They tend to just ignore it and hope that the idea goes away and gets forgotten.

    Either that or I have to lay off the Pepsi and Pop-Tarts for breakfast... *twitch*

    [ Parent ]

    Exactly! (none / 0) (#99)
    by thebrix on Wed May 01, 2002 at 08:33:39 AM EST

    It amazes me the number of people (never mind 'managers') who don't realise that, if something is behind schedule, the solution is not to put more people on because those who are competent will be distracted because they're instructing those who aren't and less will be done overall ... ! (Rather, the milestones have to be renegotiated with the same people in place; I rather like the phrase, spotted on /., that 'The project isn't late. The milestone was early.').

    In the former Soviet Union this mad rush towards the end of each month was called 'storming' - even before the MMM - and had similarly disastrous results.

    [ Parent ]

    babies and doctors (crude) (none / 0) (#104)
    by bored on Wed May 01, 2002 at 09:56:13 AM EST

    The project isn't late. The milestone was early.

    I like the crude ones, :> "9 women, 1 month and an abortion doctor does not make a baby, it just makes a bloody mess"



    [ Parent ]
    Yowch! (none / 0) (#107)
    by minusp on Wed May 01, 2002 at 10:29:40 AM EST

    Did you work there, too???

    Not only put more people on it, to dilute the efforts of the few that actually understand the project, but also, and this is CRUCIAL, impose mandatory overtime. Anything less than 16 hours, 7 days out of the tools is a sign of Management Slack, and shall be punished, or something. Just make sure that anyone actually hands-on is operating in a sleep-deprived caffeine dementia, while Management is gone by 4 PM, or otherwise "unavailable."

    Oh, and I nearly forgot, make sure that you call DAILY meetings of mid-management and supervisory techs (8AM to noon, minimum) to discuss why all the projects are behind schedule.

    Feh.

    Remember, regime change begins at home.
    [ Parent ]

    The French Revolutionary calendar (none / 0) (#115)
    by thebrix on Wed May 01, 2002 at 01:35:01 PM EST

    Can be adopted if all else fails; 100 hours to the day, 10 days to the week, everything with different names and 'we ship on 14 Brumaire, Year 1 or the guillotine shall fall' ... (And it had 12 months of 30 days with 5 days left over at the end, presumably for 'over-run' or 'last-minute adj^H^H^Hcomplete rewrite'; these people were 200 years ahead of their time :)

    [ Parent ]
    Work in the Soviet Union (none / 0) (#119)
    by thebrix on Wed May 01, 2002 at 03:13:28 PM EST

    Yes - as part of my course I spent 9 months at the A.N.Bogolyubov Institute for Theoretical Problems of Microphysics, which was worth going to for the name alone :)

    There was no sturmovshchina (the original Russian expression for the monthly mad dash), but it was peculiar to see Slava Sovetskoye Nauke! ('Glory to Soviet Science!') picked out in gold leaf on various buildings ... who needs managers with that sort of encouragement? ;)

    [ Parent ]

    They called them 'death marches' (none / 0) (#137)
    by mjs on Fri May 03, 2002 at 04:18:59 PM EST

    Anything less than 16 hours, 7 days out of the tools is a sign of Management Slack, and shall be punished, or something.

    At least, at one place where I worked that's what they were called. Management by Death March was the standard mode of operation until I got sick of it. One Saturday afternoon the entire 36-person project team was taking 10 minutes outside to smoke and try to remember what that big bright thing in the big blue room was called when, as I recall, I said, "Fuck it. There's no way we can meet this schedule so why the hell are we killing ourselves knowing that we're going to fail? Why don't we just fail now and save the suspense?" Half an hour later I was in the project manager's office explaining why his team was going home for the weekend. I recall being rather blunt: either he could negotiate a more realistic schedule or he could start concocting his explanation to management of why the project was late now. From the look on his face, no one had ever done that before. I figured I'd get fired (and was at the point where I didn't care,) but instead we got a new project. The team inheriting our old project failed, of course, and eventually the whole rotten idea died (and it was a dumb one, too.) I was there for several more years. Funny how things work out sometimes.

    [ Parent ]

    NHS issues (none / 0) (#98)
    by thebrix on Wed May 01, 2002 at 08:26:20 AM EST

    Some remarks on 'little effect'.

    The NHS is a minefield; some time back I worked on things which had possible medical applications and was told "you don't want to do that 'ere there" from my company.

    The three main problems with the NHS and IT are:

    Almost all of the business processes are pre-computer (or non-computer) and cannot be 'improved' by gluing a computer on to them (unfortunately some have, so there's a huge patchwork of incompatible systems of different ages and variable competences);

    There are deliberate bottlenecks built into the system for sensible reasons. For example, a regulator or other overseeing body may have to approve treatment W, a consultant can only sensibly examine X people a day, test results take Y weeks to process, a letter takes Z days to arrive, and so on; there is actually a lot of time built in where nothing much is happening. Joining these 'sub-optimal' events together (from 'Mrs A falls ill' to 'Mrs A is discharged from hospital, cured' and a thousand other branches in between) is phenomenally hard to model.

    Because of a combination of regulatory oversight and the fact that, if you make mistakes, people can die there's a mass of logging, verifying, validation, reporting and whatever else (and a lot of managers to do it, Heaven forbid ;); information flows from A to B via X,Y and Z. That demands a lot of bespoke development.

    The best of British to anyone working in that sort of environment; I have a horror that increased NHS spending will be poured down the throats of people who don't understand these fundamental 'inefficiencies which aren't' and come up with all sorts of superficially optimised schemes which fall apart when worked.

    Economics and management structure (none / 0) (#102)
    by richc on Wed May 01, 2002 at 09:26:21 AM EST

    The increase in management structure could also be due to the change in the economic situation globally. As the economic situation becomes less good companies want to squeeze as much money as possible out of their existing revenue streams so management and control from higher levels is tightened up. As the economic situation improves flexibility and new ideas gain greater importance and a flatter management structure is adopted. This repeats itself with a certain amount of lag following the cycles of the economy.

    Hierarchy to handle O(n^2) (5.00 / 3) (#108)
    by Paul Johnson on Wed May 01, 2002 at 10:38:52 AM EST

    Hierarchy is a natural solution to the problem of co-ordinating large groups of people. If you have n people then you have O(n^2) (n squared) interactions between them. As the team grows it gets to the point where you can't move a muscle for fear of treading on someone's toes.

    There is also a non-linear effect due to the size of the human brain. Most humans can "know" (i.e. recognise by face, recall name, recall relevant history) about 200 people. Subtract relatives and non-work friends and that usually leaves around 100-150.

    I've heard people talk about being in organisations growing past this size. One quote: "It was funny. Suddenly I kept meeting people I didn't know". This is important. If you don't "know" someone you don't know what they do or how well they do it. Smaller companies can work with personal negotiation where both parties want to do well because they know they'll probably have to depend on the other person some time. Once you grow past that stage the personal relationship system breaks down and you suddenly need procedures and management for stuff that previously happened automatically.

    It looks like the best architecture to handle this is a tree with some horizontal links. Tree structures handle the complexity by modularisation, but they impose a heavy communications load on the higher nodes, and hence managers become the communication bottlenecks. You can avoid this by setting up horizontal links wherever there is significant amounts of communication.

    And another point on management:

    One thing you need in particular is risk management. In software development a key risk is that its not going to happen. I've seen a bunch of projects where time and money were just thrown away in return for zero progress, and it wasn't due to lack of technical talent. One of the big duties of managers is to recognise this situation and kill the project before it kills the company. The second big duty is to try to stop this happening in the first place. One big disaster can swallow up the profit from an awful lot of successes, so its worth adding quite a lot of overhead if it results in a reduction in the disaster rate. Like good security, all this stuff doesn't look productive because you don't see the disasters that it prevents.

    Paul.
    You are lost in a twisty maze of little standards, all different.

    Another experience: (none / 0) (#110)
    by KiTaSuMbA on Wed May 01, 2002 at 11:08:29 AM EST

    I am not professionaly involved in the IT, I work for a university lab in neuroscience. However, I see many common traits: it's the business model that doesn't work not just the IT specific case.
    What's wrong with this model?
    There is a "multi-scale" control over the process, from middle management (assistant researchers, post-docs) to the top (professor in chief, chairman of the department etc.) while the proccess itself is being done by tech. employees, PhD students and undergraduates. This generates some serious trouble: since the top of the ladder ignores what goes into the base (through multi-step miscomprehension of the problem in hands and often through lack of knowledge on the specific issues) either the expectancies (time or other) are above any really probable success or too moderate for the real targets in play (ever seen an experiment turn form a brilliant idea into an almost useless "prove-the-obvious" worthless publication?).  
    Furthermore, people are assigned in "workgroups" by written-in-paper CVs and skill reports, making them change "partners" every couple of experiments. In my (ok, rather short) experience, when I work with people I merely know about, the effectiveness diminishes by about 50% against working with my "standard" group of 3 people where I can turn my back and still know what everybody does, how he does it and what he is thinking of while doing it! I insisted on forming "stable" workgroups handling a portion of all the experiments each rather than the scheme of "everybody does everything with everyone upon necessity" and this model is a lot more effective AND gratifying. So here we are with a group for behavioral stuff, another for imaging (microscopes and the like), another for genetics and another for electrophysiology. Every group has an embeded "manager" (a post-doc/assistant researcher) fixed to the guys he/she works with and reporting directly to the professor in chief. Everybody works, jobs get done, nobody steps on the toes of other and, well, if you get it before deadline you can get the joy of having some (lots) of beer with your "partners" who by now you consider friends.

    Now, to make things clearer I will give you an example of the "wrong model" related to IT...
    Suppose the department/Univ. could afford a specialized IT group (rather than outsourcing). I go to the prof. in chief and talk about the extreme loss of time doing statistics over "standard" commercial tools instead of having a custom-designed toolbox suggesting we should develop that with R (a multi-platform statistics and graphics language) and an SQL database (so it would be the last time we went floppy-hunting to find those 2 yrs old results for comparison). The prof. agrees so I give the IT guys a call and ask about that. They say it could be done in a couple of weeks ("that's dead easy man!")  plus another 15 days for us to overview it and set things tight to our needs. I refer that back and get a green light. Trouble is, the prof immagined of a GUI and some really stupid interface so that even no-computer-experience-whatsoever undergraduates and the secretary could use it. So by the time he explicitly asks this kind of thing to the IT group they *know* it will need more than 2 months (instead of 2 weeks) to get done. Let the rants begin: "You *promised* it would be ready in 2 weeks and I have a deadline to respect and...!!!!" Multi-step management control, especially by people who do not understand the technical matters underlying the project, cannot be effective on non-linear processes.
    There is no Dopaminergic Pepperoni Kabal!

    Yup (none / 0) (#122)
    by broken77 on Wed May 01, 2002 at 04:18:36 PM EST

    Also applicable to the health care industry. Administration costs are eating up larger and larger portions of the revenue. I'd like to find some data on this in regards to IT. I'm sure it's the same.

    I'm starting to doubt all this happy propaganda about Islam being a religion of peace. Heck, it's just as bad as Christianity. -- Dphitz

    Too many managers (none / 0) (#139)
    by eucalyptus on Wed May 15, 2002 at 10:25:53 AM EST

    I am a middle manager. I manage 4 developers (some would call them engineers). My observations and response to this article. I would love the developers I manage to manage themselves more. But at least one of them at some time would be off with the fairies developing wizz bang code that no one asked for and is not suitable to any requirements of the customer. Therefore part of my job is 'controlling' the developers. How did I become a manager. I was a developer who realised that only someone with some idea had a chance of influencing management of IT in a sensible direction. I pushed for the role and was given it. Another part of my role is to try to moderate marketing types and others from promising (or expecting) unreasonable deliverables (time, cost or features). This problem and role is alluded to in many other of the posts. 'Too many managers' is way too simplistic in it's assessment. How about lack of competant developers and/or lack of good project managers and/or lack of sensible marketers ....... I rant. I cease!

    There are too many managers | 139 comments (139 topical, 0 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!