Management and Software Design Principles, Compared

How much can managers of software projects learn from software itself? From actual code? Quite a lot. And not just general principles but also particular, actionable advice.

Conway’s Law reminds us that organizations tend to produce designs that mirror their internal communication structures, but what of a corollary? What if we managed projects with a communication structure that mirrored performant and flexible software design? This post is the first in a series that will explore that idea and its consequences.

For the purposes of this series, we will look to Robert Martin’s SOLID design principles as our guide to ideal software design, starting with the Dependency Inversion Principle.

The Dependency Inversion Principle

The Dependency Inversion Principle (or DIP) states:

• High-level modules should not depend on low-level modules. Both should depend on abstractions.
• Abstractions should not depend on details. Details should depend on abstractions.

This same principle applies to project management.

We will start with a concrete example: Managers often try to compare sprint points across teams. But, instead of getting a useful read on the organization’s overall performance, they cause anxiety and conflict between teams that should be cooperating with or at least ignoring each other. This attempt to increase performance actually reduces it. Why? The manager engaged in the organizational equivalent of an external module directly comparing the private properties of instance variables instead of entrusting their classes with the task. If one did that in object-oriented software, this would violate the object encapsulation and, in turn, the Dependency Inversion Principle.

Our extended metaphor, itemized:

• Instance object -> a team.
• Instance variables -> information that only makes sense within the context of the team, e.g. story point estimates, stand-up schedule, lunch preferences.
• Instance class -> the interface to the team, as embodied in how it communicates with the rest of the organization, including both formal routes (e.g. software releases and project manager meetings) and informal routes (e.g. Slack channels).
• External module -> a manager of multiple teams.

As a Management Issue

Breaking the organizational equivalent of object encapsulation hurts the manager, as well. Doing so burdens them with far too much knowledge of each teams’ inner workings. This makes their own work all that more brittle and cognitively expensive to maintain. The resulting quagmire of minutae makes it impossible to discern the higher-level issues within an organization.

What would an organization that followed sound software design principles in its management practices look like? At this level, managers would focus on the following responsibilities:

• Making sure that communication channels between teams are open and clean (e.g. members of different teams do not have to make back-channel requests of one another to complete their work).
• Verifying that the expectations set for each team are clear (e.g. team members do not have to return to their managers for clarification on tasks after starting them).
• Preventing external blockers (e.g. team members do not have to wait for responses from vendors before continuing their work).

As a Software Issue

Some software equivalents to the issues listed above, respectively:

• Defining interfaces that allow consuming code to make full use of objects that implement them without knowing any specifics of the implementer, and controllers that take responsibility for passing objects to one another so that the objects can remain ignorant of one another’s lifecycles.
• Writing unit tests and features specs before writing implementation code.
• Hiding vendor-specific libraries and APIs behind wrapper code that supports wholesale mocking or replacing of the specific vendor without any of the core business code knowing of the swap.

Solutions

How would management based on software design principles look in the real world? Some examples:

• Taking time out to manually pass messages between teams, making note of the recurring patterns among these communications, and finding ways to redistribute work that minimizes the amount of cross-team communication required.¹
• Treating every instance of developers going back to managers with questions as a failure of the manager to have “finished their homework” before handing the task over, thereby necessitating an update to the manager’s procedures that will prevent such oversights in the future.²
• Working hand-in-hand with lead developers to develop a complete mock of an external service before beginning negotiations with vendors.³

Real-World Example

JIRA, a popular choice of project management software in larger organizations, violates the DIP in its very design. It exposes far too many details of each team’s internal processes (like story points or developer subtasks) to the entire organization, particularly upper management. It purports to facilitate cross-team communication but burdens everyone involved with tracking a cacophony of details. The software binds teams to specific processes without regard to their particular needs. In short, the singular net value of the tool boils down to this:

Any project large enough to warrant JIRA needs to be broken down into smaller, more managerially-isolated projects that are each too small to warrant JIRA.

This problem is hardly unique to JIRA, but that particular software exemplifies it. Other tools, like Trello, purposely refrain from offering detailed reporting because their creators understand that doing so provides only an illusion of control. These alternatives try to avoid violating the DIP.

Going Forward

Over the course of the year, we will explore more of how the SOLID principles can apply to project management. In the meantime, I hope that this first look proves helpful. Feel free to send me your comments and feedback.

Yours in blogging,
JC

---

Footnotes

¹ A common mantra of management is “Don’t make yourself a bottleneck.” However, some bottlenecks are unavoidable and, in those cases, pushing them down the management chain only serves to obscure the constraint without eliminating it. Management needs to own such bottlenecks so that they can prevent the output (e.g. new work requests) from being pushed onto receiving teams before they are ready. That way, the team can focus on delivering the work already in their queue without the cognitive burden of upcoming work.

² Rather than being lazy, as often assumed, individual developers are frequently too removed from the planning process to have known what to have asked for before receiving new work, never mind empowered to prevent incomplete work assignments from being handed down to them.

³ This might seem to delay work, but this would make negotiations that much more efficient and would free developers to focus on vendor-agnostic work during negotiations.