The Bus Factor

This was the best speech for someone running for the position of Treasurer that I’ve ever heard:

“Well, I’m Jewish by birth…any questions?”

GOT MY VOTE.

But anyway. On to another topic, one which the GSoC mailing list just started discussing (in lieu of the copious and nagging requests for various tax, payment, and gift information…like someone said, you’d think from reading the mailing list that this was the Google Summer of Payments and Free Shirts and Where Is My Gift Being Delivered): the Bus Factor.

This paradigm consideration states, essentially, that developers should consider what would happen if, say, a few “key personnel” were to be struck by a bus the next day and killed. Would the project derail? If only a couple or a few people were killed (or, for the sake of lightheartedness, “otherwise incapacitated”), would the remaining handful or more be able to keep the project moving forward? Would the knowledge of the project be spread out among enough people for the remaining personnel to pick up the slack? Or even better, is the documentation good enough for someone with very little prior knowledge of the system to get up to speed very quickly?

Or will the project die out completely?

(ok, I know this is somewhat morbid, but try to see past the imminent example of getting plowed by a massive internal combustion engine on wheels, and focus instead on the principle of the matter: keeping the lines of communication open and ensuring everyone involved in the project, and everyone who could ever become involved, is kept in the loop by some method or another)

Even in the Open Source world, where “supposedly” “everyone” can work on any project, the Bus Factor is surprisingly prevalent. The vaunted Linux kernel, for example, while certainly spread out among hundreds of thousands (if not more) developers, would still suffer horrific setbacks – at least for awhile – if its C-in-C/Emperor/Pharaoh Linus Torvalds were to suddenly be hit by a b–er, somehow rendered unable to perform his duties as god of the linux kernel for a long and unspecified period of time.

What then, Linux? How now, little penguin?

While this affliction tends to go by a different name in college – I prefer to call it “CS major” – it is by no means absent in academia. I am certainly as guilty of it as the next person. Time and time again our instructors have drilled into us the obvious and enormous advantages of teamwork and good documentation and effective methods of communication all wrapped up within one big happy and efficient development process. And sometimes, we actually abide by it.

But by and by our egos (or, perhaps, simple knack for gravitating toward [W]aterfalls…*rimshot*) break through the opaque cloud of best practices and dig their tendrils in deep. We employ “black magic” – unbelievably obscure code that, two days later, even its creators can’t make heads or tails of – or we skimp on the documentation, providing asinine comments like “this is a for loop” or “the purpose of this program is to provide a positive user experience” that don’t help the developers and certainly provide absolutely no foundation for anyone coming in after us to maintain, upgrade, and otherwise manage the slovenly and pseudopodded amoeba of an application we call a deliverable.

If a core group of developers are the only ones who can save an application that is dying from its own dysfunction, God forbid they vanish for a period of time…it would spell doom for the hapless program. Not to mention the company to which it belongs.

I cannot count the number of personal projects I have had to leave mid-stride, only to return to later when I’ve found time to resume development, and realized that the project would never be completed, as the very obvious lack of documentation and good design principles left me scratching my head, unable to discern whether the program was supposed to be a server log compiler or an XML-RPC blog synchronizer.

Since then, I have adopted a personal rule of thumb: for each line of code, at least three lines of comments and accompanying documentation. Yes, this equates to a lot of extra administrative work, but oddly enough it has the side effect of forcing me to think about the design I am actively attempting to implement by writing it out in plain English. Not only that unforeseen benefit, but if I leave the project for months at a time to attend to, oh I don’t know, SCHOOL, I can come back to it, reread the droves of directed and precise comments, and be back on the path of development in relatively short order.

And, if I was to be…incapacitated…I think anyone else would be able to read those same comments and pick up where I left off.

Though there is one glaring exception that I have consciously forbade myself from eliminating: I have had a work of fiction (science fiction, to be precise) in the wings for the last almost-two years now, and while I have nearly 100 pages (double-spaced) of story written, I have at least another 100 pages of materials’ worth floating around amidst the pulsing, electrified neurons of my brain, waiting to be unleashed on paper and out from the ether of my mind. This will happen in its own due time…preferably before I get hit by a bus. πŸ˜›

(to you: I’m not ever planning on this happening. the bus, I mean.Β  it’s still not gonna get published though. k? k πŸ™‚ )

So yes. Communicate. Document. Design. Document. Code. Document. And did I mention document?

Ok, it’s past midnight on a Friday night (ok fine, Saturday morning). It’s time to blow away some Strogg.

Advertisements

About Shannon Quinn

Oh hai!
This entry was posted in GSoC, Programming. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s