Software As A Team Sport

Right now, I’ve found myself in a contrast.  I am working on Software, alone.  Sort of.

I’ve previously remarked in passing my firm belief that Software is a Team Sport. And I have set out with the intention to directly contradict myself by successfully conducting a software project by myself. Sort of.

It’s a natural and reasonable question as to why I keep backing away from the notion of solitary work. I’m doing this for two reasons. Firstly, because the code I’m working on was written by a great multitude of people over the years and no single person can understand the whole lot. And because there is an entire team who is technically available to answer my questions. Except for the fact that they’re half a world and an extremely inconvenient time difference away. So while, due to the former reason, I have been asking questions of various people in parts of the code I don’t yet understand, the latter means I have been quite reticent to do so and have in fact spent at least an entire day trying to figure out an answer I was provided in roughly 10-20 mins on the other end, because I had to wait that whole day before my email was answered, anyway.

I am finding that I want to substitute the tools I would normally have at my disposal and today scanned in a hastily drawn diagram in place of wandering over and using a whiteboard. Having realised there was a mistake in the diagram after scanning it, rather than quickly correcting it with a quick wipe of a handy sleeve, I was forced to use words to explain it – negating my whole use of a diagram as my communication medium in the first place.  Speaking of words and substituting tools, I’m finding that I really want to talk about my work.  It would be nice to explain to someone that the async events aren’t firing in my mocks without said audience glazing over.  But it’s not just about having an adult conversation about my work, it’s also about the fact that I don’t have all the answers.  I would like to sanity check with someone that the design route I am taking gets the check mark of sanity – preferably before I’m too far down the rabbit hole.

Another natural and even potentially reasonable question to ask would be “How is this any different from a personal project?”  In a personal project, I never seem to have large design conundrums, but I guess that’s because I have made *all* the design choices thus far, so the pieces fit naturally together for me and where they don’t, I have no reticence in refactoring because I know the code well and have an insanely clear direction of where I’m headed.  I still like to talk about the projects I’m working on with my colleagues, but it’s more of a general interest in swapping stories, rather than some pathological need to clarify the details or vent the insanity of the particular portion I’m currently working on.  And in a personal project, if I lose motivation for a particular piece of work, I can just put it down and walk away for 6 months or so.  When I’m being paid to get something done, I feel far more obligated to stick to something, even if I would really rather not.  Maybe that’s some latent professionalism seeping through.  Or something.

And usually, my personal projects aren’t aimed at anyone else having to maintain this code for years to come.  A personal project is not a novel where all the facts and events need to be clear, it’s a hand-scrawled note, which is barely legible enough for me to understand what I meant.  In a year’s time when someone sees my name marked against this code in the source control, I’ll want to have left a trail of breadcrumbs to be able to answer their questions.  Because let’s be honest, that person asking the questions is going to be me.

And all of the previous seems to be negative; there are some absolute positives here!

• I have been given a task which is exciting for me, something I’ve been wanting to work on for over a year, but haven’t been given the opportunity until now.
• I get almost no interruptions.  Sure, I do have some other work I need to get done, but that’s done in large chunks, rather than fits and bursts.
• The corollary to having to make all the design decisions is that I get to make all the design decisions.  I’m off on a branch, only choosing to sync with the rest of the team’s churn every week, so I’m largely unaffected by their rate of change, doing work in a reasonably isolated part of the program.
• Due to the time difference, I have almost exclusive access to the full power of the build farm.  I don’t have to wait for anyone else’s build to finish (usually) and I would struggle to clog up the system all by myself.

But those positives all pale in comparison to the quality of the programming I would be able to produce were I able to have better contact with my peers.  They make my environment better, but that’s about it.  They do almost nothing to improve the quality of my output, which is where my colleagues would normally come in handy.  I can get their influence, ideas and claw at them desperately when my sanity is about to hitch that ride to crazy town.  On my own (and isolated) I have to walk myself to crazy town, step by agonising step, either solving the problem eventually (the hard way) or getting a cheap haircut, one fistful at a time.

So all in all, I guess my answer is simple:  Either write all of a program yourself, or work in a team with genuine, real professionals.