Re: [tlug] Up against the wall! [was: Running without Gnome...]

["Stephen J. Turnbull" <stephen@example.com>]

Josh Glover writes:

 > We can't get away from "projects" when doing things like building
 > new datacentres or migrating to a new cloud provider or whatever,
 > but I don't see much software being developed in the project style
 > in the places where I work.

I can't deny that.  I suspect you're as much a victim of the variety
of contexts where software is developed as I am, though.  I didn't say
that software had to be developed project-style, just that project
manager is a necessary role, and we can't even shoot all the people
with that title.

As I wrote, when somebody asks me to recommend a development
"organization", I recommend somebody like Curt.  As he points out in a
parallel post[1], project management skills are something a competent
developer should be able to acquire with a little training (even
self-training, although an experienced mentor is a lot of help in my
experience).  I certainly agree.  I think I also wrote that most
useful-by-themselves "tasks" are small enough to be done by a single
developer, or perhaps two.  Evidently such developers are self-
managed.  (Although maybe that wasn't obvious from the way I wrote.
python -m this | grep obvious)

Part of the problem with conventional project management positions is
that project managers manage projects, so mission creep until you've
got something big enough to call a "project" is very tempting.  That
point where tasks are "big enough" is apparently well past the level
of "useful by itself" task that you see around you.

Curt Sampson writes:

 > Plus, the actual workers are the only ones actually qualified to
 > say how fast they can get something done.

This is absolutely not true.  Saying how fast they can get something
done is a matter of having past data on productivity and good size
estimation tools for tasks.  (Note: "productivity" and "size" are not
scalars, nor is project size necessarily a linear function of task
sizes!)  Inexperienced workers will do a terrible job of saying how
fast they can get something done (unless quality standards are very
lax).  Experienced managers (with the right training -- which is not
given at any university I know of and definitely not in this country
-- and proper organizational support) do a lot better.

 > Thus, when you have a bunch of good developers working full-time on
 > a project, get them to do the project management as well.

The question is whether the "bunch" is big enough or inexperienced
enough to justify a position specialized to project management.
Evidently in your experience and Josh's it very rarely is that big.
Neither of you is inexperienced (any more, and not for decades ;-)
so you will (correctly!) perceive attempts to "manage" you as
interference.  I expect that generalizes to a lot of software
development tasks, just not all of them, and perhaps not even a
majority.

 > But if your developers are idiots, you're still screwed no matter
 > how good your project manager is.

Sure, but there's a cut above "idiot" -- and I see a lot of them on
the Emacs and Python lists as well as GSoC students ("can you spell
'inexperienced', children? I knew you could!") and Mailman workers --
where project management makes a big difference.  To me, teaching
developer-level time management is a large part of what being a GSoC
mentor is about, and part of that is actually managing the student,
while explaining what you're doing.  Of course in the case of FLOSS
volunteer projects, management is mostly about task prioritization,
leadership, and certain aspects of long-term HRM (care and feeding of
delicate egos), since "project-level" time and money budgeting really
aren't part of what makes them go.  But I expect that in most
organizations larger than 5 you end up needing some people in the "cut
above idiot" class, and when you get larger than 10, more than half
will be in that class, even if you're a startup or a top-paying
industry leader that everybody wants on their resume.


Footnotes: 
[1]  Quoted but not in References because that seems to confuse many
MUAs.