Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

gnat (29)

gnat
  (email not shown publicly)

Journal of gnat (29)

Thursday October 11, 2001
10:28 AM

Management crap

[ #961 ]
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):

  • maintainability
  • portability
  • testability
  • speed
  • robustness
  • size
  • safety (algorithm or feature choice based on probability that the implementation will be bug-free)
  • simplicity
  • reusability

Fix your bugs as they're found. The other approach (delay bug fixing in favor of feature addition) leads to an unmanagably long list of bugs that reach into every feature and which can consequently be impossible to fix. I think Jarkko probably agrees with this one.

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:

  • How could I have prevented this bug?
  • How could I have easily and automatically detected this bug?
  • How can I avoid this problem in the future?
  • What can I learn from this mistake/experience?

Think in terms of negative feedback loops. That is, the output of an action becomes the input to the next iteration in such a way that bad behaviours are minimized or even eliminated. That's the point of fixing your bugs as soon as they're found.

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