So, as the perl6 project manager, one of the things I do to pass the time is read all the project manglement books I can get my hands on. So I read "Debugging the Development Process" by Steve Maguire the week before last. I got a lot out of it. What follows are the bits that resonated with me, or that I agreed with. Enjoy!
Remove obstacles. His mantra is: "any work that does not result in
an improved product is potentially wasted or misguided effort." As
mantras go it's longer than "om" but also more useful.
He's very skeptical about regularly scheduled status meetings.
An alternative to status meetings is to have a list of what must be
done for the next milestone release, and mail out a "success! feature
X works" message each time an item on the list is checked off.
Set priorities for code. Order these from most
important to least (I've listed them in my first guess at an order for perl6):
This one sounds wanky, but I'd like to throw it out as advice for
people who want to get better. Each time to fix a bug, ask yourself:
Advice that really resonated with me was: "start each day by asking
what small things you can do today that will help the project on track
in the future?" This isn't the big things, but is stuff like
"automate the synchronization of PDDs on the web site and the docs
directory", "poke Schwern for a review, to make sure we're testing
what we should be testing", and "type up all the things you learned
from that book". In Simon's case, for instance, it might be things
like "mail whatshisname and make sure the VMS build is still happy".
Fear the debugging process that tweaks randomly rather than using gdb
to track the bad data back to the source. I know from experience that
this adds more bugs than it fixes. Maybe ParrotCode should have a tip of the week section, and have the advice on debugging be one of the tips?
There's no such thing as a free feature or product. Everything that
you think "will come for free with this design" has to be tested,
documented, and finished (because the free feature is never completely
there). By all means leave the door open to add the free feature
later, but unless it's part of the mission then don't do it. (The
Parrot mission currently being to build a perl6 runtime environment).
After every milestone, think about what went wrong and what went
right. Maguire recommends a postmortem report, a brief analysis of
the problems, solutions, and successes. The goal is to learn from
these--to be able to answer the question "what can I do next time to
prevent this?"
The whole chapter on schedules was easy for me. I think I can safely
say that I'm not a manager who creates arbitrary unrealistic schedules
and holds you to them :-)
Make sure each subproject (milestone) results in an exciting
conclusion. "Builds on all core platforms" is good. "Assembly
supports all vtabled scalar ops" is better!
"Don't allow programmers to stagnate--constantly expose them to new
areas of the project." He draws the difference between random
shuffling of employees to new groups, but is in favor of letting
people work on things that interest them. Also, don't have the best
programmer implement the task if there's a good programmer who would
learn more by doing it. That's not as easy to do in open source, but
it's worth thinking about how we in perl6 can make it easy for people to get
better.
Train your replacement. Unless you plan to be the lead forever, you
should be training someone to replace you. That makes it easier for
you to leave when you get bored. Jarkko's neck is probably aching from the nodding at this point :-)
Take immediate action when you see a way to make an improvement. If
someone doesn't know gdb and needs to, point them to a gdb tutorial.
If someone is writing shitty tests, point them to a doc that says how
to write a good test (do we have such a doc on a Perl web site?)
Simple testing advice: assume that your code contains bugs, and write
tests to find them. The alternative (assume that because it compiles
it's bug-free) is not good.
This one is bound to have a lot of resonance with perl5: Don't ship
substandard features. Postpone them until you can implement them
properly.
--Nat
