Conway’s Law: Any piece of software reflects the organizational structure that produced it.

It’s interesting to see laws play out.  While we as technologists probably slap the word law on a few too many sayings, especially if it’s witty and we like to repeat it (so why haven’t I run across a Monty Python law?), there are a few observations that are certainly worthy of being laws.

Conway’s law seems to be one of them.  I’m watching it play out before me.

Currently, at work, I get the joy of playing with a fairly large legacy code base.  It is the product of a startup and it proudly reflects that legacy.  Anything went, so long as it worked and could be done quickly.  The best practice?  Maybe not, but I can’t hold it against the previous developers.  Their worry was about where the next paycheck was going to come from unless something went out the door and made money.

So now the code is large, bloated, and cranky.  It’s tightly coupled and a nightmare to decouple, all while being too happy to hatch bugs.  Oh well, you do the best with what you can.

The company at his point is growing and with it comes the inevitable growing pains.  New bosses are coming in, that hideous beast that is management is spawning a few more heads, etc.  I’m sure the drill is the same almost everywhere.  Structure is being imposed left and right, process is sprouting like a weed.

With all of this, the same is being asked of the code base.  Structure is being forced upon it, whether it wants it or not.  Abstract classes are appearing, along with patterns, and a bit too much inheritance for my taste.  To me, it’s the classic overcorrection.  The cars gone into a skid so you jerk the wheel hard in the other direction.  You’re supposed to steer into the skid, but that is rarely what happens.  You overcorrect and only after you’ve ended up in the ditch to you remember what you were supposed to do.

I figure it’s only natural.  It’s a learning phase that companies go through.  You make it past being a toddler, but then you have to deal with adolescence before you figure out how to be an adult.  It isn’t good or bad, although hopefully you learn some good lessons along the way and don’t end up as a dropout with no future.

Eventually, I’m sure the reins will be loosened, once the structure is found to be too constraining.  This will apply to both the code base and the management/process beast.  A happy medium will be reached and everyone can continue on their merry way.

At least, that’s the goal I’m aiming for.  We’ll see how it turns out.