OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: XML As Fall Guy

Len and John,

Both comments are fantastic, and distressingly true.

However, this also points to the same ugly truth that I think most programmers intrinsically recognize, but few in management do. Expertise matters. Experience matters. I've seen any number of teams that "jelled", at least until the point where the crap hit the fan (and it always will, at some point in the project). Expertise just doesn't mean knowing how to write code in a given language - that's necessary just to have skin in the game. Expertise is knowing what to do when the fecal matter starts flying, knowing how to prevent it from happening in the first place, and having the confidence to wade in and get things back to a pre-fan stage - or better - as quickly as possible when it does. This is why I don't believe in the concept of prima donna programmers. I've met any number of programmers over the years who could make code sing, but who became so fixated upon their own code that they couldn't spread this expertise to others.

Of course, the only way that you do gain this experience is to encounter it in the first place. When you hire junior programmers, you're getting inexperienced programmers, which is not by itself bad. When you fire experience programmers because they are "too expensive", on the other hand, you lose that ability to train newer programmers, lose institutional knowledge, and find you keep making the same mistakes over and over again. 

Kurt Cagle
Invited Expert, XForms Working Group, W3C
Managing Editor, XMLToday.org

On Fri, Nov 29, 2013 at 11:32 AM, John Cowan <johnwcowan@gmail.com> wrote:

On Fri, Nov 29, 2013 at 10:53 AM, <cbullard@hiwaay.net> wrote:

At the core was a team of civil servants who specified it, designed it AND managed its fabrication and fielding.  This team had been together developing these systems for three decades:  German Rocket Scientists.  The Von Braun Team.

In short, what de Marco and Lister call a "jelled team".  Unfortunately, we don't know how to create those, only how to destroy them.  The chapter on teamicide  in Peopleware starts thus:

What's  called for here is  a concise  chapter entitled "Making
Teams Jell at Your Company."  It should have half a dozen simple
prescriptions for good team formation.  These prescriptions should
be enough to guarantee jelled teams.  In the planning stage of this
work,  that is exactly the chapter we expected to write.  We were
confident.  How difficult could it be to cut to the heart of the matter
and give the reader practical tools to aid the process of making teams
jell?  We would apply all our skills,  all our experience;  we would
overwhelm the problem with logic and pure brilliance.  That's how
it looked in the planning stage....
Between  plan  and  execution,  there  were  a  few  distressing
encounters with reality.  The first of these was that we just couldn't
come up with the six prescriptions needed for the chapter.  We got
stuck at zero.  We'd been prepared to scale our expectations down a
bit, but not this much.  ("Zero Things You Can Do to Make Teams
Jell"?)  It seemed clear that something was wrong with the under-
lying notion of the chapter.  What was wrong was the whole idea of
making teams jell.  You can't make teams jell.  You can hope they
will jell; you can cross your fingers; you can act to improve the odds
of jelling; but you can't make it happen.  The process is much too
fragile to be controlled.

Instead, they explain seven ways (in the 2e, nine ways) to prevent teams from jelling, a much simpler matter.  Alas, in 2013 all of these ways are still in regular use by management — and they explain why both Clueless and Sociopath managers (without using those terms) are interested in preventing teams from jelling.

A truly great book, whose only defect is that those who need it most will never heed it.  I see that it has a new edition this year; I suppose I'll have to break down and buy it.

GMail doesn't have rotating .sigs, but you can see mine at http://www.ccil.org/~cowan/signatures

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS