The Bus Problem

Software engineering practitioners joke about this all the time, and it’s a classic management problem that is deeply rooted in the software engineering folklore. There exists a person who singlehandedly built software program that supports some important business function (in production environment of course). Everyone knows that there is virtually no documentation, no one else knows the code, there is no source control, and this is the only person who can maintain the program. And if that person gets hit by a bus and dies there will major issues, but it’s better not to think about it.

Even in the organizations that have mature software engineering processes the bus problem persists. This is because all organizations have opportunistic projects (programs) developed by a person or two. These programs, usually developed as unofficial side projects, support informal business processes that provide significant benefit to the end users at little cost. These opportunistic projects are usually developed in a haphazard way, because there is no spare time and they are targeting a very specific audience. Examples of this type of program may be a custom authentication mechanism that is small enough to be developed and maintained by a single person. Such solution may have been intended to be used for just a single software solution, but over time it became an important component of multiple software intensive solutions, or this program became the vehicle for supporting a core official business process.

My colleague responsible for a project that fits the description above has been hit by a “bus”.

Future posts will provide lessons learned from the experience written from an architect’s point of view:
• Dealing with the bus problem
• Anticipating the bus problem
• Preventing the bus problem

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Comments

Popular posts from this blog

Why we do agile

Quality Attribute Refinement