S-E-P

You may have heard about Douglas Adams SeP principle in the famous Hitchhiker's Guide to the Galaxy. SeP stands for Somebody else's Problem.

The SEP principle represents an ubiquitous principle in software engineering. You definitely have heard about it or even experienced it personally in some projects.

One typical example I often hear relates to software architects complaining that their management agreed on the requirements of a concrete software project without asking them for feedback or help. The management then throws the project specification over the fence to the software engineers which is when the whole mess begins. Involved engineers are doomed to fail due to incomplete, inconsistent or even missing requirements. Yes, indeed, all these guys from management are morons like those illustrated in the Dilbert cartoon series.

But wait a minute! Is it the job of a software architect to take a specification of requirements  without any review and feedback? No, that is not the job description of an architect, at least not from my point of view. As soon as you are asked to design a new system, it is a must to consider the business case, the requirements, the risks and then to decide whether this possibly could end up as a success story or rather develop to a dead man walk. If you find any problems in a project context, it is your duty to inform the other stakeholders about your findings and ask them to solve those issues before starting the project. If they don't accept any changes and your gut feeling tells you this project is doomed to fail, the last resort would be rejecting to participate in the project. Sounds rather harsh but consider the other option: If you take responsibility as an architect in any project then you are signing a kind of virtual contract where you fully agree with the whole project specification including the project organization, the process, the requirements, etc. This means you cannot simply finger point to your management afterwards when the specification turned out to be questionable. You have become part of the system and thus it is your fault too. And it is definitely not a SEP.

What this means for software architects is the fact that architects are not just puppets on a string controlled by some evil guys in HR or Senior Management. They have responsibility and should feel empowered by management, because if they don't, the architect's role in their organization is either undefined or not well defined. Draw your own conclusions in this case.

So from now on: Whenever you feel inclined that a problem you face in a concrete project setting could be a SEP, think about it again.