Not A Blog™

I haven’t been working in the real world for very long, but even in the few years—No, it hasn’t even been multiple years, yet. In the year and a half I’ve been working in the real world—plus four years of college—I’ve been noticing this same sort of trend. It happens without warning. Unexpected, I find it cropping up, to the point where I can’t even account for it in most cases because I don’t realized it has happened until it’s too late. It’s a phenomena I’ve decided to name—since I haven’t heard it discussed elsewhere—Unintentional Permanence.

What is unintentional permanence, you might ask? I might reply that it is something which becomes permanent unintentionally. While this is technically a correct answer, it helps no one. It doesn’t apply as much to the work of a single person, because they account for all details (at least all the ones not accidently overlooked). Even if it’s something as simple as saying, “oh, I’ll fix that later,” they’re at least acknowledging the fact that this particular detail needs work.

Unintentional permanence is something that develops within a team setting. The problem is not that the leader of the team is not properly supervising the work, nor does it really have to do with any one person’s laziness. It’s a combination of factors.

To answer the question, “what is unintentional permanence?”, I can point to just about any team project I’ve worked on over the past year. It goes like this. In order to prove that some idea or concept will work, a prototype is often built. Sometimes these prototypes develop into final projects, sometimes they don’t, but they always exist. The idea behind the prototype isn’t to say, “it will be this way,” but rather, “this idea or construct will work.” After the prototypical work has been completed, one of two things happen.

If the prototype is put on the shelf, it’s generally not forgotten. The pieces which went into the prototype can often be reused, even in some different capacity. However, when ends up happening is that the pieces—which were not meant to be final versions of anything—are usurped wholesale, so that everything they contain (bad design, I’m thinking of specifically) is imported into the new project, and used.

But more often, it works like this. You design some piece of the puzzle. There’s always something that’s not really important, but which people still see or use every day. It could be the wording of an introductory paragraph. Sometimes it’s the placement of a button or a background pattern. It’s not necessarily even something should be addressed later, because it’s at least mediocre enough that nobody notices the fact that it’s not really done yet. Whatever it is, it ends up staying even though it was never consciously designed.

Something highly visible has just been made a permanent addition to whatever you’re working on, and the amount of time you might have spent thinking about the impact of what you were creating could have been as much as two seconds. Well, this happens all the time with single-person projects. Isn’t this the same thing?

Not quite. That is intentional permanence. This issue has been considered and deemed to be acceptable for the time being. Sometimes these things are fixed later—but a decision is always made regarding them. Unintentional permanence is when no decisions have been made, something was just stuck in there as a placeholder, but the piece is implemented anyway.

It’s a byproduct of teamwork, of course. It happens because after a placeholder is put in place, the project is passed to someone else for the next stage. After it bounces back and forth a couple of times, what happened four revisions ago has now been established in everyone’s minds as the way things are, even if it really wasn’t made that way for any particular reason.

Anyone who would attempt to fix all these little things would probably be considered a micromanager. If managers have trust in their subordinates, there will always be a certain amount of unintentional permanence that creeps into a project. The trick is recognizing that the vast majority of it really doesn’t make a difference. On the other hand, some of it certainly makes a difference: it is the difference between elegance and utility. Sometimes utility is sufficient. Always, utility is a must. But it takes someone with an eye for eliminating unintentional permanence to get both utility and, following that, elegance. Most projects, even if they go through a “polish”, are rarely looked at with an eye toward eliminating unintentional permanence.

As someone who is directly working on projects, I’ve found that I must be vigilant in eliminating this before it happens. It’s not something that anyone would ever notice, but it bothers me when something I do gets locked in to a design and I hadn’t really “completed” it—I hadn’t given it any thought—before sending it off to the next stage.

So why bring this up at all? What’s the point?

I find it interesting because it can be compared to another loathsome happening with which more people are familiar: committee compromises. I’ve also seen this happen first-hand, and I hate it. Who doesn’t hate it? It’s such a disheartening event. That’s not to say that compromise is never an option; it’s a tool, like anything. But there are some things which should not be debated by committees. Usability is one that comes to mind. Usability testing is done for a reason, and no committee should be permitted to review the results and discuss them. There are clear conclusions: either a product is sufficiently usable, or it can be improved. Likewise, anything artistic or design oriented not only shouldn’t—it can not be decided by committee. It’s a matter of taste, which is individual preference. Anything which combines different aspects of individual artistic preference will always result in a solution that is inferior in every way to any single given artistic preference to begin with. It’s a universal law.

Here we have two issues that happen in projects: the committee compromise and unintentional permanence. Both result in mediocrity, but look what’s happening. Both are the result of teamwork.

That’s not to say that teamwork is a bad thing, but that it has unintended consequences. Like everything in life, “teamwork” is not a solution that can get any problem done. It helps in cases. But if Archimedes had a lever long enough and a fulcrum to balance it on, he wouldn’t need a team to move the world. The deal with teamwork (a buzzword, really, I know), is not that adding more people to a team helps get things done. Adding more people to a team who have the particular skill that the team as a whole currently lacks (or is currently capable of implementing), does.

Unintentional permanence happens when two people on a team share overlapping duties. When this happens, both people will assume the other person will fix it—and when the fix doesn’t happen, this is taken as (unconscious) validation that the thing in question is good enough and doesn’t need to be addressed further. As I mentioned, these things are good enough, but as more and more of this stuff accumulates on a project, it eventually gets bogged down, and an overall, vague sense of “quality” is lost. You can’t point to one thing and say, “that’s screwing up the whole project” because it’s a collection of things which, unintentionally, became permanent.

At this point I’m supposed to reveal the fix. I don’t have one today; I’m just complaining about problems. The only fix that works for me is personal: try and prevent it as I realize it’s happening. So—awareness, then. Be careful that your crap doesn’t become infected with unintentional permanence, because it’s a physical manifestation of mediocrity.

-Ted