Header logo
Free Consultation

Programming as a Team

Grace Murray Hopper

Knowing the best approach can often make the difference between getting a job done on time and within budget when working on larger sites, difficult engineering challenges, and team projects.

It wasn't *that* long ago, that a typical day in the trenches of this magical and mysterious world of web software development might have gone something like this:

  • Start coding!
  • Whoops, that thing doesn't do what I needed ... Google time, baby!
  • Aha, found something on some techie bulletin board to answer this specific question
  • Coding, coding, some super intense brain-draining thought about solving this specific and complicated problem I'm working on (it's often said: the hard part of programming isn't the typing, it's the thinking)
  • Hmm...that approach isn't quite what I need this to do, so...
  • Scrap the last hour of work because it was the wrong approach
  • Rinse, repeat as necessary
  • Eventually get to the right solution, and now things work. Hooray!

Now, each programmer's mileage may vary, but this just doesn't seem like the BEST approach to "getting it done", does it?!

The syntax is often not the issue - the world of software development is a complex and winding path toward a goal that often moves around a bit as you work your way toward it. Out of this disconnect between approach and execution, a few philosophies have been created by various people (all WAY smarter than me!) to help to avoid this round-robin exercise in futility.

At Ashday, we've been highly successful having adopted one approach in particular for some project tasks, that actually seems quite counterproductive at first: put more than one person on the same task. It's called "pair programming", and it's being done in almost as many different ways as there are programmers to do it differently. It's a fairly simple concept, have one person do the bulk of the typing work, and have another watch them do the typing work.

So, wait a second - how can THAT possibly be beneficial? Aren't you just wasting TWICE the time on something when you're doing that (two people instead of just one)?!

In truth, this is actually an amazingly elegant way to solve certain programming challenges. Let's re-imagine my previous scenario as a pair programming task (I'll use "PP" to identify my pair programming partner in the dialog):

  • Me: Start coding
  • PP: Ah, I see what you're doing, but I think approach X might work better?
  • Me: Oh, I didn't think about that, you're right...redirect and coding, coding
  • PP: Hey, you missed a semicolon up there, FYI
  • Me: Ah, thanks - that could have taken me a good 5 minutes to track down!
  • PP: I'm going to do a bit of research over here while you finish this piece to see what the best approach is for this next thing we need to do
  • Me: Oh, I have an idea about that, because of this other thing I did a while back...
  • Rinse, repeat as necessary
  • Done.

So, what exactly happened here, that made this work SO differently? Well, for a start, there's another dynamic about working in our industry, that I haven't mentioned yet: Different Programmers Program Differently. (Yes, I just made that up, but it's true nonetheless!)

Take a bunch of developers and ask them all to build you a site, and what will you get? 100 different sites. It happens even if they're all Drupal developers, since you can "do" Drupal in an infinite variety of ways. In fact it happens in software development, regardless of platform, ALL the time. This is not to say that one developer's approach (arguably) is any better or worse than another developer's approach, just they will both approach the same problem with a different strategy, and can achieve their result through different methods.

Programming and development is often like reading a "Choose Your Own Adventure" book. The same story can be told in many different ways.

Another gloriously beautiful thing about this approach, is that not only will multiple developers bring their different approach to the problem, but they also bring their various and different experiences along with them. I might never have had to solve this particular issue before, but "PP" might have had a similar experience and struggled through a solution before -- just having his experience in the mix could possibly save me hours of research and "trial-and-error" time. And if we're building a client's website, time is money.

Now, WHY does it work so well, then? Remember before, how I said "have one person do the bulk of the typing work, and have another watch them do the typing work"? Actually, there's quite a bit more going on behind the scenes with that statement. REALLY, what this means is "have one person focus primarily on syntax, execution, low-level figure-it-out-ish-ness" and "have the other person focus on strategy and the overall approach".

I recently read a passage in a business guru book that said success in business requires that a business thinks equally in terms of strategy and execution. I think the same is true for programming. Only a TINY fraction of people are really effective at both - most people are great at strategizing but relatively not great at implementation, or the other way around, and in varying degrees. CEOs (and programmers, in this example) that are great strategists NEED someone to partner with who is great at execution, and those who are great implementers NEED someone who can help them strategize more effectively. This is exactly how pair programming approaches this problem in the software development world.

If I'm focused mostly on making this little thing work the way I want it to, but someone is there to have my back on the overall approach... then I will frequently avoid the rabbit holes I might have otherwise gotten caught in, while being focused on the nitty-gritty. Maybe my overall approach was flawed to begin with, but I didn't realize it because I was too absorbed in HOW to do it, not WHAT it was I was actually trying to accomplish.

Of course, this also goes the other direction -- thinking too generally about an approach can often glaze over the realities of how it might actually work. I might incorrectly assume this certain thing was a very simple piece, but in reality it's an engineering nightmare to build.

As a team, you're serving not only yourself, but ultimately your customer much better, when you're able to most effectively balance both your approach and how you accomplish it.

How does that old adage go? Two heads are better than one? Indeed they are.

Ashday Media Group

Recent Posts

More Blogs