On Process, and software development

Today I had a chat with a coworker about the process we use at work; the method by which we develop software, from conception (“The site should be blue”), to doing the work (filing a ticket, writing the code to make the site blue, ensuring it is the expected share of blue), to various legal and compliance requirements (“it must be documented that on such-and-such a date, so-and-so did change the site to blue, signed by someone other than so-and-so”).

In short, we hate the process.

On the one hand, it’s cumbersome. Most processes are. They are build from small parts to a Big Thing, because one time, something REALLY fucked us, and That Must Never Happen Again. So layers got added, workflows got created, and before you know it, you need knowledge of the inner workings of a complicated state machine to make the site blue.

There was a time when you could just do it, man. It was great. But now it really optimizes for the common case, and we all know what happens then.

Anyway, what got me thinking was, what’s really at fault, here.

I think there’s a couple of big problems.

As an industry, we aren’t entirely sure what the hell it is we’re doing. There is a wing of the software industry that thinks we’re some kind of code-poet-ninja-rockstar who makes these beautiful and amazing things because it’s what drives us.

Me? I think we’re just skilled labor in an information economy. We’re assembly-line workers. And that’s good: skilled labor built this country. We should reward it! We should revel in it! That used to be a fucking awesome job, that people aspired to.

But the thing about those industries was, for a long time the pace of chance was slow. Carpenters had the hammer thing settled long before most of my ancestors came about. No one showed up with a tack hammer expecting it to be useful to build a building.

Our processes don’t protect us from outside interference. They don’t give us certainty about what it is we’re doing and why.

Building codes let every tradesman building a building know, to some degree of certainty, that when followed the pipes won’t burst, the sockets won’t catch on fire, and the support beams will hold. They’re why flood walls work and why buildings survive earthquakes.

It’s a process no one likes to follow, but it moves at a pace people understand; can be comprehended and relied upon for the duration of one’s career; and has visible results.

Today a bunch of code broke because our fragile human meat made mistakes that, in retrospect, may have been impossible in the common case to prevent. A couple of jobs ago, we changed fundamental pieces of our software at least twice; last job, we went tripled the number of languages you needed to do things at work in the space of a month.

It’s madness.

We are not wizards, ninjas, rock stars, or artisans. We are the skilled labor of an information economy; a noble profession, and one that benefits from a slower pace of change.

Our processes should reflect that. They should not just protect us from lawsuits or pass a perfunctory compliance inspection, they should provide a bedrock upon which to make solid decisions when tired, or confused, or hurried, or unsure.

Leave a Reply

Please log in using one of these methods to post your comment:

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