Web Development Is a Social Enterprise

Contrary to popular depiction, professional software development is an inherently social enterprise. The astute developer quickly recognizes that writing code that works is only the beginning of the job, and that to really get cooking, their code needs to communicate effectively with the rest of the team.

If I am sick in bed or on vacation to the moon or I have left to focus on my professional skateboarding career, and everything goes south, someone on my team is going to have to step in, and they are going to have to figure out what I wrote. Then they are going to have to work with it. This is the kind of situation where a small investment of time and consideration can pay exponential dividends.

There are actually lots of these situations, and many of them include your Future Self. So if you have a selfish nature, just remember that the other people you are helping could quite possibly just be Future You trying to parse code that you wrote six months ago.

Turns out the worst developer is (yourself – 6 months)
– I Am Devloper (@iamdevloper), December 9, 2015

For the uninitiated, this is a joke. A kind of “laugh so you don’t cry” joke that for a developer is often all too real. This doesn’t have to be true! (Although I’m pretty sure we have all been there more often than we would like to admit.) There are a few strategies we can employ to keep these kinds of special surprises to a minimum, and to loop back to the title of this post, they involve exercising our social muscles just a bit.

Getting More Eyes on Your Code: Pair Programming

Pair programming is just what it sounds like. Two developers sit together at a desk with one computer. One, the “driver,” controls the mouse and keyboard, while the other, the “navigator,” observes and reviews code as it is built. The developers switch roles at regular intervals.

While it sounds counterintuitive, this process ends up reducing development time and increasing code quality, mainly by catching bugs earlier in the development process (see chart below). For an investment of about 15% in the development phase, you can get a pretty serious return.

Upsetting Tabular Data for the Unconvinced 

Average Cost of Fixing Defects Based on When They Are Introduced and Detected. Code Complete, Second Edition, p. 29.

Read that chart again. Let it sink into your brain and imprint itself into your subconscious. It should inform every decision you make as part of a software development team, whether you are a programmer, project manager, user experience architect, intern or whatever. In short, what it shows is that the cost of fixing an issue increases exponentially as the time disparity between introduction and detection of said issue gets larger.

Obviously, the phase of development we are talking about here is “construction,” so you can see that the average cost of catching these errors increases dramatically the further along in the process we get (an eye-popping 10-25 times!!!). It also removes the dreaded “single point of failure” phenomenon that can occur when only one person is up to speed with a codebase and can keep you from receiving a stressed-out phone call in the middle of your tropical vacation.

Now obviously this isn’t an appropriate practice for every development situation, especially in a fast-paced creative shop where every developer’s time is stretched pretty thin. It is probably most useful in core development projects where robust and reusable code is critical to a large project’s success. That being said, it is not too far off from what many developers do anyway, in consulting their peers about particularly thorny problems or just to bounce ideas off of informally.