Thrown Over The Wall

Category: AntiPattern (CategoryAntiPattern)

Context: You understand the roles of contemporary software development: analysis, design, coding, and quality assurance. You want to ensure all these roles get acted upon.

Therefore: (mistakenly)

You assign each role to a separate individual (or group, or geographical location). The artifacts of each role are ThrownOverTheWall to the next role.

Resulting context: Extremely slow learning cycles. Lack of CodeOwnership (analysis ownership, design ownership) of any kind. Belief that intermediate artifacts are in and of themselves important. Artifacts that get out of sync with one another. (See DisposableAnalysis for a way to avoid the last.)

There are lots of approaches to avoid this pattern. Xp (ExtremeProgramming) is one, I think. -- PaulChisholm

I talk about this one in my PLOP98 paper, "Streamed Lines" (available from http://jerry.cs.uiuc.edu/~plop/plop98/final_submissions/), about patterns for how to use the branching facilities of version control tools. In the context of branching and merging, this is an "AntiPattern" I call Integration Wall: developers code and test their changes in isolation, then throw their changes over the integration wall for someone else to deal with merging and integration testing. I see two fundamental issues that often arise from having things ThrownOverTheWall:

Systemic Disconnection: People can become disconnected from the "whole" because they lose awareness or interest of the effects of their efforts further downstream. I think GeraldWeinberg writes in one of his books that the best approach to quality is to have each person throw their work upstream rather than downstream, so they have to deal with the effects they cause.

Social Isolation: When you throw over a wall, the wall can prevent you from seeing and effectively interacting with the folks on the other side. When the two sides focus primarily on different issues they can develop different priorities and concerns. The two sides can often become adversarial rather than synergistic. If one needs the other to effect a change for their mutual benefit, the other side may be more resistant to change if the benefit affects them only indirectly, or is not aligned with their different set of goals.

Having said all that, I should note that these two things (systemic disconnection and social isolation) are not automatic results from having things ThrownOverTheWall. Sometimes they can be avoided, and things work rather smoothly. But these two problems sure do happen a lot and can be especially tricky to avoid. One of the preventative (or corrective) measures is a pattern I dubbed "MYOC" (Merge Your Own Code). There are other patterns of branching that address this as well (lots of non-branching ones too I'm sure ;-).

In "Streamed Lines", I suggested that a better approach is to try and Isolate Work, Not People. It's the work that typically needs to be partitioned up. But we still want the workers to function synergistically as a whole. Isolating people from their own work is what causes systemic disconnection, and isolating people from other people is what causes social isolation. Split up the work by all means, but keep the people and the team as close and collaborative as you can manage. This is strongly related to InterTeamCommunication.

-- BradAppleton

In their book ReengineeringTheCorporation, MichaelHammer? and JamesChampy? say that companies should reengineer their processes to keep from having a lot of people get involved in handling a single process. They argue that the old way of improving efficiency by pipelining no longer works, and results in high latency and companies that cannot cope with change.

One of the main techniques that they use to reengineer a corporation is to assign each process to a single person, or to a small team of people. For example, a bank traditionally handles loan applications by having a list of people who must approve the loan. Each of them looks at one aspect of the application. A reengineered loan approval process would have one person look at the application, decide if it was an exceptional application that had to be forwarded to someone else, and otherwise approve or turn down the loan. Ideally, less than 10% loan applications would be exceptions. Instead of taking a week to approve a loan, the re-engineered bank might take an hour. A boon to embezzlers -- TimRobinson?

I think that you are talking about the same thing. Instead of having three or four people involved in adding a feature, assign one person to talk to the customer and then to analyze, design, code, and test that feature. XP does them in a different order, of course! But I think that this idea of having one person involved with all aspects of adding a feature is a key to highly-productive software development.

-- RalphJohnson

I am yet to see the technology that cannot be used to ruin the project. Formal process is no exception, it is just another tool, like a hammer. A hammer is a useful tool, but if you just hammer everything everywhere - china, computers, people - do not expect to build something useful. -- AlexJouravlev

If I am a hammer AllProblemsLookLikeNails.

CategoryMethodology CategoryManagementAntiPattern