Most readers will be intimately familiar with Douglas Adams’ work. If you’re not, it’s definitely worth a read. One item that relates to engineering and project planning that always springs to mind too late in a project was a concept he included in Life, The Universe and Everything: The ‘SEP’ – ‘Somebody Else’s Problem’.

This concept is basically a sort of cloaking field where people ignore something by assuming it’s somebody else’s problem.

“An S.E.P., […] is something that we can’t see, or don’t see, or our brain doesn’t let us see, because we think that it’s somebody else’s problem. […] The brain just edits it out; it’s like a blind spot.”

—Douglas Adams. Life, The Universe and Everything, Chapter 3

I read this book in the 80s, as a kid, and that notion has stuck with me ever since. In college, every now and then you’d see something really weird as you walked to class, like a guy walking in a hamster wheel in the main Quad, and you would just elide it from you consciousness, like it was somebody else’s problem.

Now, this has probably been brought up by others – there is a fairly strong overlap between folks in IT and Douglas Adams fans, but I fee that I bring it up often enough to blank expressions that it’s worth talking about.

There is a surface view of this phenomenon in daily life as an engineer. Sometimes you kick the can down the road just because. It might be a question of how your part of the system is operated, how it will log, or how it will be installed. That is someone else’s problem, to be sure, but that is something that a junior developer, in the right environment, can learn to avoid (see Vertical Integration).

As we gain experience, too, these become more and more rare. The first time you build a system, you may not consider the web server setup, but after a few times around, you will get a sense of all the components of a project.

However, as we gain experience, new types of SEP arise: The true blind spot, and the Grey Area.

The True Blind Spot

The true blind spot arises when you try to apply your experience to something that almost fits. Say you have built dozens of PostgreSQL systems, and you are doing your first project using Solr. You put a bullet in your project plan for ‘Install Solr’. You and your team have it running nicely locally, and in the dev environment where you are admins. You have a good app, and it passes testing. It’s time to deploy. However, no one told the systems group about the new need for Java to be installed, nor any idea of how to run it as a true service that is production ready. In the back of the collective heads of the team, everyone assumed another resource would do it, and it was collectively edited out.

The Grey Area

The Grey Area occurs when you have multiple teams working on a project, and each team could be responsible for a risky dependency that no one is comfortable with, and everyone just sort of assumes that one of the other teams is better qualified to do it, and therefore will. Here, a strange form of humility takes hold, where people assume that someone will be a more logical choice than they are. Deployment time comes around, and everyone says – ‘Well, this is really something that I’m not qualified to do, so I didn’t do it, because I didn’t want to do it wrong’.

Solutions

When confronted with projects that have unknown path components, especially 3rd party modules, integration with stuff like Auth systems, and such, I fall back on my preferred technique for developing software: the Rational Unified Process. I’ll go into the benefits that I see in this down the road, but one of the primary drivers of this is to address risk early, and deliver the riskiest parts first. (Or make a good prototype). So in both these cases, the SEP is based on an un-managed risk that we hope the process will magically manage.

Instead, all members of a project team (but mainly those in leadership roles) must honestly look at their project and continually analyze its components or tasks, and ensure that there are no high risk items left without an owner.

This takes dedication and seriousness. All too often, these topics are glossed over. When they are discussed, the risk is minimized. After all, no one wants to play the role of Cassandra, always prophesying doom. Finally there is the worst possible outcome: the meeting where no one writes things down. You plan, inventory and understand risk, make assignments, and then don’t write it down. Then you repeat.

The SEP field is trying to protect its contents any way it can.

NB: I wouldn’t say I’m a RUP fanatic – it’s just the first framework I learned, and it has served me well.