student project

On a sunny day (Sat, 04 Dec 2010 09:34:09 -0800) it happened John Larkin wrote in :

Yes, you can start a new projec there :-)

Jack Ganssle's newsletter had an article some months back about how that productivity ratio (between the best and worst programmers) tended to drop precipitously with the size of the project, though: As projects grew larger, vast amounts of time start being eaten up with meetings, additional documentation, and so on.

Which I consider to be a good argument for hiring people who are as diverse as possible so that you don't need, e.g., one guy to write PID code, one to writer FPGA interfacing code, one to write Ethernet routines, etc.

Yet many companies seem to actively frown on "generalists" who actually did pay attention in *all* of their engineering classes rather than just "programming in Java" (...assuming they even have degrees at all -- I see little correlation with programmers between their formal education and how productive they are... but good luck getting hired without a degree these days!...). These places have self-imposed rules about what one's title has to be if you want to write a certain type of code or design a certain type of hardware, even though they'd be the first to rally against the idea that, e.g., only journeyman union electricians are allowed to wire up lightbulbs. Bizarre...

Anyway, you might enjoy some of his articles:

---Joel

Yes. Lucky for us, we are doing relatively small embedded products, so one person can handle all of a project. That's much more efficient. I think.

Jack usually makes sense, except occasionally when he discusses hardware!

John

In a large project, the best programmers/engineers should be doing the documentation so the rest know exactly what they're trying to accomplish. The documentation is the design and if it isn't complete (and of course correct) the rest waste time, or worse.

Your idea of "diverse" and mine are different. ;-)

I've been reading Ganssle since he started his newsletter. He does have a lot of good ideas but he's also into selling Ganssle lectures and consulting. I'm not so sure his methods are _that_ transferable. Management eats that stuff up, though.

I'll buy that. The grey area is in how much documentation you want to put into just *how* some objective should be accomplished as opposed to just

Yeah... you worked on superscalar CPUs at IBM for some time, right? -- That's clearly a very complex and diverse kind of project. (...clearly no one person in the entire world has all the skills needed to build a space shuttle all by themselves...) But stuff like John does, or, oh say, something like a digital wireless radio system you or I would do is far less diverse and shouldn't need more than a pretty small handful of people to pull it off. Yet I see a lot of companies that really want to make that transition to "big company" mode, even when they're still a small shop and just modestly successful. Heck, I've now worked at two companies that chose to adopt heavy-duty (high-5-figure price tag) ERP systems only to never actually finish implementing them! (Company #1 went bankrupt after about 3 years of this, company #2 is still hanging on some

Heck, on a bit of a tangent, this is some of the same problem we have in health care today: Most all medical students wants to specialists rather than generalists (presumably because it pays more?), and yet the vast majority of people and widgets just don't need *that* level of diversity. The end result is higher prices and/or lower quality care/widgets.

Hmm, you may be right about that.

Some management would like to believe that there's some magic-bullet training course out there that'll let them turned monkeys into high-quality designers, when in actuality the core problem is often that the people who were hired just aren't that good. ...and while (as John has been mentioning) finding good people is always a challenging prospect, when management themselves has a weak technical background it becomes nearly impossible.

---Joel

That depends on the size of the project, certainly.

I actually worked on CPUs for only the last eight years, or so.

John's products are quite small, in comparison. A single person can easily wrap his head around these sorts of things and avoid all the organizational complexity. Documentation still needs to be done so people know what is to be built. ...and in case someone gets run over by a bus.

All of your tasks above were software. It certainly takes all those things but also a lot more diversity than that.

Growth kills a lot of companies. I think they spent a *lot* more than they needed on our IT systems, too, but that's really none of my business. What they did buy is EOL, too. It'll be even more expensive to replace them now.

There is some of that, certainly. The problem is really reversed, at least as stated. Your comments were, AIUI, about management wanting specialists. With health care, the people making the decisions aren't the ones paying the tab. ...though perhaps it really is the same issue depending on who "management" is.

What I mean was, that his methods seem to work, but an eight hour lecture isn't going to do much.

Good managers who are also strong technically are exceedingly rare. Very few of the best managers I've had have been top engineers. In fact I can't think of one (competent, sure, but not outstanding). You put your finger on it above, "takes more time than just doing it yourself", will kill a project (and a manager).

One of my managers told me that they once promoted the best engineers into management but found that they didn't often get a good manager AND lost a good engineer, so they stopped doing that. He was one of the better managers, BTW. ;-) IBM, BTW, has a dual ladder system so engineers and managers are rewarded more or less equally. That takes the a lot of the incentive out of becoming (and demand to become) a manager for those who would rather stay technical.

Yeah, that's a good point. HMOs, I suppose, are an attempt to put the generalist/specialist decision more into the hands of the (generally) more-educated person (the primary care provider), but that hasn't proven popular with users. (Which I suppose isn't at all surprising...)

The current administration's seems to have the idea that providing a certain basic level of universal health care means that you also have to active try to discourage people from spending their own money on additional services of their own choosing, which is unfortunate. See, e.g., the new restrictions on HSAs.

Or maybe none of the higher-ups in the administration actually read those 1500 pages either. :-)

Agreed. I think I'd prefer "just competent technically, great at management" over "great technically, just competent at managent," but it's hard to say generically. (Those in the later category probably should end up as project leads?)

I think HP has something similar; sounds like a really good idea.

---Joel

It didn't prove popular because they were, in general, mismanaged, treating people like cattle. They get enough of that from government (see: DMV).

It's not just the current administration. Hillary care had that feature, too. Like AGW, it's not about what it seems. It's all about control/power.

Of course not. They meant it when they said they'd have to vote on it before anyone would know what was in it. Tens of thousands of bureaucrats are needed to find out what it means, and they couldn't be hired until it was passed.

If you're hinting at "Matrix Management", that's a bigger problem.

I don't know about HP, post Carly, but it really did work in IBM. Perhaps it took more money to do than a lesser company could afford, though.

Joel Koltner expounded in news:FqUKo.427681$ snipped-for-privacy@en-nntp-12.dc.easynews.com:

There are nuggets of wisdom in the book "Mythical Man Month" by Fred Brooks. Like "adding manpower to a late software project makes it later". He was managing the writing of the OS/360 at the time.

The one other observation that stuck out in my mind, was that a large project should only have 1-2 (3 at most) architects. The design will only be a homogenious vision when held in the mind of one person (it is seldom, if ever fully captured in documentation). A 2nd person is necessary as a backup and must otherwise have similar vision. Beyond that you risk ending up with a hodge podge of incompatibilities and painted into a corner design problems. Like govt projects. ;-)

Warren

snipped-for-privacy@att.bizzzzzzzzzzzz expounded in news: snipped-for-privacy@4ax.com:

Sure, it's only 1 bit. Why fuss about it? ;-)

Warren

Take the optimistic approach: if 10% of the lines of code contain bugs, it's 90% right!

John

Yeah - according to the democrats, the US has almost 90% full employment!

Cheers! Rich

Certainly there should at least be a hierarchy of architects. Some projects, like OS/360, are just so large that one (or three) can't do it all.

One bit is only 6dB. ;-)

Kinda like they're doing with Linus's kernel? ;-)

Cheers! Rich

Depends on which endian you are. ;-D

Cheers! Rich

Rich Grise expounded in news:idnc0u$5ie$ snipped-for-privacy@news.eternal-september.org:

Yes. A hierarchy works, but one person should steer the overall vision and keep it on course.

Kinda like herding cats.

Warren

One person should be able to design and code an OS kernel. But it would have to be a small kernel, not a monster like Windows, which has the GUI and all sorts of junk running in kernel space. I think Linux is a big-kernel OS too.

We live in the dark ages of computing.

John

The only good low-endian is a dead low-endian.

John