A few years back, I had the wonderful opportunity to be employed by Bob Bruce of Walnut Creek as a paid FreeBSD advocate. I lived in New Mexico at the time, but I did have a chance to visit their operation and meet many of the California-based FreeBSD core team members. I later moved on to doing custom chip design as a consultant, but I kept tabs on a lot of the mailing list discussions for quite a while.

At that time, WC-CDROM provided a comfortable home for many of the core team members, including the charismatic team leader, Jordan Hubbard. There were a great many people sharing load to get the releases out the door, but my impression was that there was also an unspoken structure of 'would Jordan approve?' in the way things were done. A while after I left, he became part of the Apple team to help them carry Darwin into Tiger and beyond. On top of that, the role of Walnut Creek changed and many of the other people found that the future wasn't safe or as comfortably predictable.

The core team screamed a collective 'oh sh!t!' that lasted about a week, but quickly rallied and got together to get professional in their methodologies for the release process. The whole FreeBSD engineering process was transformed over the course of a year. Not only do they now have processes in operation that have been hammered very deliberately into place, but they also have methodologies for handling changes in the workers and their level of capabilities. Those new structures have since survived many upheavals including an attempt by a payware company to buy and bury, changes in the core personnel and their roles and time commitments, and increasing pressure to 'keep up' with the perceived progress of Linux.

My point in this meditation -- as I'm interviewing new people for Sandia and making decisions about my outside business and its team -- is to consider our organization and its people, and the outside organizations I depend upon for my software, in the light of their survival characteristics. Sandia has a requirement that we make sure that our projects can be recreated thirty years from now and their data be recoverable. The nature of much Net-based open source development and payware business works against that goal. For an example, could you recover data from a tape made on a Colorado Backup portable drive that had only Windows 95 drivers ever written? Likewise, do your systems people document the changes they make to the configuration files and scripts of your systems as they make them? Somewhere other than on the system in question? ;-]

Most importantly, how much knowledge is embedded in the memory and experience of the one guy whose pager is always going off and who's getting tired of working 80 hour weeks. How many fixes were done by the one guy who's on vacation and unreachable until October? Where is your backup backed up? Are your CVS deltas documented? How many fixes have been done by a binary patch and forgotten because some manager never approved the time to go back to fix the software that produced the corrupt and unusable data files?

This meditation isn't specifically about Perl, but it's as important to a Perl team as use strict; and use warnings;.

In reply to Teams, Personalities, and Getting the Job Done by samizdat

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.