Structure and zombies.
Introduction.
A recent survey asked more than two hundred I.T. project managers a simple question: what is the greatest threat facing software-development projects today? Over ninety per cent of those polled replied with a single-word answer: zombies.
Global zombie contagions and infestations have always dogged the software industry, of course, but recent decades have witnessed an alarming proliferation of project failures due to developers suffering brutally violent deaths only to reanimate and swell the pestilential hordes of the undead.
The problem is communication.
Let us examine a typical, small, software-development project to see how lines of communication facilitate the spread of these profit-sapping plagues.
Meet Hank.
Hank, project manager in a well-known software company, leads a team of nine gifted software-developers working in a rather plush downtown office. More than a mere manager, Hank considers himself a trusted friend of and mentor to his team, wishing nothing more than to see them healthy, enthusiastic and typing. This presents a difficulty, however, as outside their offices zombies swarm maniacally through the streets searching for any morsel of living flesh into which they can sink their fetid teeth.
Ever the realist, Hank knows that the chairs, desks and tables barricaded against the ground-floor doors will only last so long. Eventually one of the undead will squeeze inside and start biting its way through the hapless staff, reducing the team's velocity. Hank concludes that he must do what every manager must do when facing a crisis.
He must re-organize.
But how can he dissect and re-constitute his team to minimise this threat?
The impact set.
He reviews his current organization, recalling with pride how he had already bolstered the structure some months before when the latest tide of brain-guzzlers began to rise. Then, Hank had institutionalized three processes.
Firstly, Hank collected all the software requirements for the project and delegated their implementation to just a couple of programmers, thereby assuming the role of supervisor to their subordinates. The subdivision being still too much for one person, those programmers could enlist the help of other programmers, thereby assuming the same supervisory relation with them, and so on forming a classic labour hierarchy.
Secondly, he had forbidden all physical contact between employees except for a weekly one-on-one meeting whereby a subordinate was allowed to visit his or her immediate supervisor to report progress. Emails effaced the subtleties of these exchanges; they required tangy, whites-of-their-eyes closeness, thus spoke managementia.
Lastly, with everyone allocated a private office behind a locked door, each employee received an RFID badge that automatically unlocked only the door of his or her immediate supervisor. This would successfully avoid all that peer-to-peer infection nonsense. Which was good.
As far as he can tell these three insightful measures would limit - if not arrest entirely - any infection-propagation.
Hank steps to his white-board to draw the structure into which his team self-organized once he had distributed the requirements to subordinates, see figure 1.
Figure 1: Initial organizational structure.
(Yes, Hank has issues with Al.)
Hank studies figure 1 for a while before deciding to theoretically stress-test the layout, to poke it for hidden weaknesses. He considers a random developer, say Bren, and investigates all the vectors that might lead to his becoming a zombie. He produces figure 2.
Figure 2: Bren's been bitten.
Bren need not worry about Sal, for example, because Sal, not being Bren's subordinate, has no way of unlocking the door to his room. If either Tom or Jill were bittern, however, then Bren's succulent jugular would quickly succumb to an incisor or two as their RFID badges would automatically unlock his door, both being his subordinate.
Here, either Tom's or Jill's zombification would inevitably lead to Bren's. Not so good.
Sullen, Hank chooses another developer - this time Ann - and works out who she must worry about in infection-vector stakes, see the gluttonous aftermath of figure 3.
Figure 3: Ann's been bitten.
Disaster.
Yes, Ann remains safe if Hank or any of the right-side of the team turns, but were Al or Bren to be bitten and lusting for some zombie action, they would surely dine on her, being her immediate RFID-packin' subordinates. Worse still, as Hank has already seen, Bren's fall is assured with the loss of Tom or Jill; a devoursome cascade sets in motion. So the random turning of any of these four would punch Ann's card. No, this would not do at all.
Hank then notes that he can characterize a person's susceptibility to infectiousness by assigning a set to each person, that set containing all the people whose zombification would ruthlessly lead to that person's own zombification. He calls this the, "Impact set," of a person.
Thus, Jill's impact set is empty: she fears no colleague's being zombified because she has no subordinates to threaten her. Bren's impact set contains Tom and Jill. Joe's contains Sal, Sam and Tim.
He then adds the numbers of people in all these sets and divides by the total number of people in the structure, generating at a crude measure suggesting the structure zombability. He arrives at a figure of 1.9.
He also feels that the lower this number, the fewer programmers will be lost to random bitings and thus the more resilient will be the organization. It sounds reasonable, but is 1.9 a good number?
A fresh approach.
White-board cleaned he starts again, this time sketching, off the top of his head, a possible re-organization: he promotes Bren out from under Ann so that Bren now reports directly to himself. That is, Hank will break the requirements down and delegate directly to Bren without going through Ann. Bren will, however, continue to delegate to Tom and Jill: Bren remains their immediate supervisor.
Similarly, Hank promotes Sal also to his direct supervision. Sal will no longer have to report to Joe though she will retain Sam as a subordinate.
Hank steps back to admire figure 4.
Figure 4: First new structure proposal.
Intrigued, he selects Bren again to work through the pathways leading to his being bitten, resulting in figure 5.
Figure 5: Bren bitten again.
Hmm, no change there. Bren goes very non-vegetarian if Tom or Jill turns. How would this new structure affect Ann's chances of being bitten?
Figure 6: Ann bitten again.
Bingo!
Previously four others could potentially threaten the loss of Ann, yet now Ann's zombification stems only from Al's falling. Dragging Bren, "Up a level," has reduced Ann's vulnerability to infectiousness.
Hank re-calculates the impact set and find this new structure to yield just 1.4, a pleasant fall from the 1.9 of figure 1.
Flatness and shallowness.
Realizing that flattening the structure has reduced the impact set, Hank then tries the radical extreme: what would happen if the structure were almost completely flat, with all developers reporting directly to himself? He quickly sketches figure 7.
Figure 7: Flat structure.
With this structure, all his team - baring himself, of course - are isolated from one another; they cannot infect one another. The impact set metric plummets to just 0.9, the minimum possible.
Hank rummages through his desk-drawers and finds that bottle of champagne that he had been saving; popping the cork, he savours a deep swig. Yes, he will have more work, effectively breaking-down the entire team's requirements, but this seems a small price to pay for minimising everyone's infectability.
Bubbles rising to his nose, he realizes, however, that he is, "Going zombo," no matter who in the team falls first and no matter which structure he deploys.
This realisation demotivates him.
Summary.
A previous post described the impacted set and the derived principle of depth - one of the Tulegatan principles of source-code structure - which advises to keep transitive dependencies short and, basically, to sunburst. The impacted set of a function is the set of all functions that it can potentially impact if it changes (a function can impact the functions, "Upstream," from it).
This post examined its opposite, the impact set: the impact set of a function is set of all functions whose changes it could potentially be impacted by (a function can be impacted by the functions, "Downstream," from it).
This post found that, whether analyzing the impacted set or the impact set, keeping transitive dependencies short - and hence adhering to the principle of depth - minimises potential ripple-effect impacts on the source code and helps minimise the cost of changes.
So, no surprises here, then.
Photo credit attribution.
CC image Zombie pilot statue courtesy of Gage Skidmore on Flickr.