Weak Links vs Strong Links in Software Engineering Teams

dr.max
dr.max
Jul 28, 2017 · 10 min read

Abstract

Software engineering (SE) is primarily a social endeavor. As such, building great SE teams is not just about getting great engineers and enforcing some agile process, but rather to think of (and apply) fundamental rules and techniques used to help create effective teams. In this essay, I argue that creating great SE teams is a weak link problem, and therefore, improving such teams is best done by fixing the weak links rather than reinforcing the strong.

Motivation

As software continues to be the dominant source of modern economies, there is increasingly a need to augment the number and variety of effective programming teams across the world. While it can be a challenge to find the necessary talent to build local or remote teams, the larger challenge is in how to assemble these teams so that they are effective.

Weak link vs Strong link Theory

Borrowing from team psychology, team building research [1, 2], and behavioral economics [3], we explore the idea of assembling teams using weak link vs strong link trade off. In brief, the weak link vs strong link theory tries to guide team-formation decisions in terms of whether a team will be more efficient by trying to reinforce its weak links vs its strong links or vice versa [4]. The analogy is to think of a team as a chain, or better a mesh, comprised of links. In order to make the chain or mesh stronger, the question is should you reinforce its weak links or its strong links or both and in what proportions?

credit: http://www.helt-consulting.com/wp-content/uploads/2013/12/Strong-Links-in-the-Chain.jpg

The analogy of chains as teams is simply a good visual metaphor as the answer to the above questions is not always weak links as one would, on the surface, assume. The answer lies in better understanding the characteristics of the work (or the game) being done (or played) by the team. A great set of common examples for this idea come up when applied to build sports teams. The answer (weak or strong) entirely depends on the game being played and the rules of that game.

Weak link Teams

credit: http://trulyfallacious.com/wp-content/uploads/2013/08/weak-link.jpg

A classic weak link game is football (or soccer in the USA). In soccer there are 11 players per team, 10 of which have the main purpose of moving the ball past the goal line of the opponent’s team using their feet and heads. The goalie in each team is the exception and typically stays near the goal line and can use any parts of its body to block or capture the ball.

Soccer is typically seen as good example of a weak link game; that is, assuming any given team composition (mix of great, average, and bad players) the team will not typically be improved by strengthening its strong links. In other words, it’s better to improve weak links in a soccer team in order to improve the overall team. So it’s better to get more average players, replacing the bad ones, than just getting one great player.

The intuition to understand that a soccer teams will probably improve faster acquiring many average players than acquiring one Lionel Messi or Cristiano Ronaldo, is that errors in soccer are very costly, and scoring requires almost flawless execution from many players. One bad player (with more likelihood of bad passes) decreases your scoring chances since many passes are usually required to move the ball forward.

Strong link Teams

On the other side of the spectrum, a good strong link example is the game of basketball which is typically played with two teams of five players each. In most situations, replacing a weak link, or average player, with a strong player in a team can have dramatic effect to overall efficiency and productivity of that team. Case and point are all over the NBA with the most famous examples being Lebron James joining the Cavaliers a few years ago and Michael Jordan the Bulls in the late 1980s.

credit: http://wallpapersafari.com/w/LjyUxe/

Sure these two players are transcendent but it’s not hard to look elsewhere in the NBA and see that adding any one “superstar” player to an average, or even bad team, will dramatically improve its fortune. This is the exact opposite with soccer. One way to understand why this is the case is to understand that unlike soccer, basketball is a high-scoring game where teams can survive mistakes by any one of its players, in others words, mistakes are less costly than in soccer.

So in basketball a team of one strong link and many weak links can still be on average successful, whereas in soccer, many weak links spell catastrophe as the strong link player will not be able to make much progress to the goal when the bad players increasingly make mistakes.

Applying the Theory

Malcolm Gladwell’s Revisionist History podcast [4], who inspired this post and the explanations above, discusses how weak link vs strong link theory could also be applied to reforming education in the US. He makes a strong case that additional funding to already well funded institutions of higher knowledge does very little to the progress of American society’s college education needs. His argument, is that adding more strong links to the American educational system will reinforce the problem rather than solve it. Instead, what is needed is funding less well known institutions (e.g., less known colleges and state schools) since they could in turn educate more students and make a bigger dent in the problem of higher education in America.

Surely, like any argument, this one has its limits [5] and has its detractors [6]. However, I happen to agree with Gladwell, but that’s not the interesting point. Rather, in my view it’s that the weak link vs strong link argument is a generic one that can be applied (with various levels of success) to other human teams and groups, especially with the purpose of understanding how to improve the effectiveness of a particular human social activity. With that in mind, the question that comes up to me is: should you build great software engineering teams by improving their weak links or their strong links?

Characteristics of Great SE Teams

The primary objective of any effective software engineering team is to produce quality software that exhibits low defects. Naturally, there are also many other important factors that make a great SE team, e.g., actually implementing the requirements (or goals) of the software and delighting customers. However, since what constitutes “delight” is subjective and out of scope for this post, let me instead address one dimension: quality.

In my view, producing high-quality, low defect code, at scale, means creating an effective team. Let’s focus on that last part. It’s well known that teams can be highly effective when their production is sustainable and that’s achieved partly when the team gels well, has high morale, has social rapport, and communicates effectively. So in that sense, creating an effective SE team means creating teams that have all these great social characteristics [7].

Which brings us to the initial question. Given the task of creating an effective SE team or converting an existing team to one that is more effective: should you try to hire all A+ skilled engineers (with proven skills as mentioned above) or rather a mix of highly-skilled and entry-level engineers? And in what proportions? Furthermore, assuming an existing team, what hiring and modifying strategy should you apply when trying to improve that team?

Why I think SE Teams are Weak link Teams

If one of the primary goal of an SE team is to produce high quality (low defect) software, the first question to ask is what produces defects in software. Again, another difficult question to answer generally, however, my intuition and experience is to suggest that defects are primarily introduced by “weak link engineers” in the team. The cause of that introduction can be lack of skills, miscommunications, misunderstanding, and a variety of other symptoms that eventually results in the defects.

Many of these issues can be resolved by building teams with more experienced and skilled engineers. The question then becomes, given limited economic conditions (limited budget) should you attempt to build or improve a team by hiring one great engineer or many average engineers? In other words, should you add a few strong links or minimize the number of weak links?

In my opinion, due to the intuition that SE teams are more like soccer than basketball, it’s better to minimize the number of weak links rather than adding one strong link. Of course, if economics is not a factor, a team of only strong-links maybe be preferred, but that is likely unrealistic, due to as we mentioned economics and rarity of great SEs. So building an SE team will usually involve trade offs between highly experienced and skilled members with newbies and / or average engineers.

To understand the weak link argument for SE teams is to realize that a defect can be introduced anywhere in the system fairly easily by any one member. And since any software system is composed of interacting components, it does not really matter that the code written by your best engineers has low defect. If that code depends on poorly designed or executed components, the resulting whole is likely to have much more defects or technical debt.

This interdependent and fragile nature of software is what suggests that SE teams are weak link teams. Like soccer, it does not matter how well your superstars performs, one bad pass, the ball is lost, and there goes the play, and with enough such events, eventually the game.

Threats to Validity: Counter-Arguments

Besides the economic reality mentioned above, the threat to validity of this argument stems from the fact that I am considering principally one dimension of SE teams here. If you strengthen your weak links but fail to create a team that gels then you may end up with a worst of situation than you started with. In other words, other social factors come into play when building a team. The point here is to assume all other factors, discussed above, being constant, what decision should one take.

Any team requires good leadership and any team resides within a certain culture that the organization it belongs to has created over time. So effectiveness of any team is also highly dependent on the organizational culture established by the management team. If your team has to operate in a culture that glorifies the “hero programmer” then perhaps the best thing to do is to indeed strengthen the strong links in your SE teams and then fix that cultural root cause issue next.

Finally, like any human team, the resulting effectiveness will depend on the problems they are trying to solve and the criticality and time allowed. Surely, simpler, or well understood problems, require less skills from team members and therefore afford more slack for success.

Conclusion

There is a common saying in Silicon Valley coined by Marc Andreesen that “software is eating the world”. The point being made is that software has become so entrenched into all types of economics activities that all parts of society is increasingly dependent on some type of software artifact.

While the pervasiveness of software everywhere is great for those whose job it is to create software, it’s also increasingly a problem. First, creating great software is hard and finding the talent, with experience, to create non-trivial software is even harder. This is why this post focuses on how to achieve effective software engineering teams.

As I asserted, creating great SE teams is fundamentally solving a social team building problem. Due to the complexity of any non-trivial software, creating a sustainable team requires a mix of talent and a management team that knows how to create that effective mix. Due to economic pressures, creating the perfect team of all A+ engineers is almost never possible. Instead, management must ask how to best use their mix of talent. Hence the question of how to create effective SE teams with a range of talent?

Understanding that SE activities are most effective when what they produce encounters lower defects over time — remember that defects are most expensive once the software is released — the question then becomes how to create effective teams assuming a current mix of talents. I believe that SE is like soccer in that respect, that is, it behaves like a weak link problem.

The goal of a management team should be to minimize weak links within an SE team rather than strengthen strong links. Many approaches are possible, e.g., adopting pair-programming, training (on the job and formal), as well as enforcing rotations and cross-team pairing. This is especially the case as, like soccer, strong links in a SE team are not able to produce high-quality code when any weak link can introduce a bug.

Of course, this essay is based from an intuition, extensive experience, and a logical argument rather than examining and researching current SE teams and analyzing the resulting data. Perhaps this intuition could be proven, or disproven, with subsequent research.

References

  1. https://9clouds.com/blog/weak-link-networks/
  2. https://hockey-graphs.com/2017/03/14/strong-and-weak-links-talent-distribution-within-teams/
  3. Camerer, C. “Behavioral Game Theory: Experiments in Strategic Interaction”, Princeton University Press, 2003
  4. http://revisionisthistory.com/episodes/06-my-little-hundred-million
  5. http://www.luc.edu/media/lucedu/law/centers/childlaw/earlyeducation/2016/McWeeney.pdf
  6. https://uncertaintyblog.com/2016/07/25/other-peoples-philanthropy-why-gladwell-is-wrong-about-higher-ed-giving/
  7. De Marco, T. “Peopleware: Productive Projects and Teams”, Dorset House Publishing Company, Inc.; 2nd edition, 1999.

Acknowledgements

  • Hernan Wilkinson of 10 Pines Software in Buenos Aires, Argentina for excellent feedback and suggestions on the draft manuscript.
  • Dmitriy Kalinin of Pivotal in San Francisco, CA for always challenging my ideas and being a strong link engineer I’d always want in my team.
  • Nima Kaviani of IBM in San Francisco, CA for being the best new engineering partner in the last four years. Your enthusiasm, can do attitude, and brilliant feedback make all I do in the IBM Cloud team better.

dr.max

Written by

dr.max

scientist, engineer, architect; tries to swim, bike, and run; photographer; works at IBM CloudLabs; words are my own

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade