Gedankenexperiment

Albert Einstein famously used thought experiments (Gedankenexperiment) to convey complex and difficult concepts with his peers and colleagues. Gedankenexperiment reduced the mental overhead and laboratory costs and helped the experimenter think through situations that, possibly, exist beyond a physical experiment.

No one disputes an on-going and stressful dynamic exists between middle-management and software developers. This thought experiment explores the possible elimination of one or the other side in the process, and the concomitant lesson we might learn by it.

In all humility, I’d like to suggest a thought experiment in software development. Thought experiments bypass, for simplicity, the specificity of a lab experiment. Stop looking for complete definitions. Thought experiments are sufficient for the topic at hand.

Introduction:

No one disputes an on-going and stressful dynamic exists between middle-management and software developers. This thought experiment explores the possible elimination of one or the other side in the process, and the concomitant lesson we might learn by it.

Consider only the titles of those in the experiment and the outcome of software development based on an identical request delivered to both. Only Software Developer and Middle Manager participate. (Google is allowed.)

Platform:

The software platform in use is one of common availability with a long-standing following and documentation. While not specifying the brand name or the language, examples could be Java, C++, C#, or even JavaScript. A stipulation exists that both the developers and the managers have worked in the platform in the past.

Equipment:

Two rooms have ten stations in each. Each station has everything necessary for ideal software development. Let your imagination run wild.

Personnel:

Ten middle managers with experience in managing products or programs are assigned to one room.

Ten software developers with experience in developing software and systems are assigned to the other room.

The outcome requires no amount of imagination.

No communication exists between the two rooms.

For discussion purposes, each group in the two rooms will be called a “team.”

Procedure:

Each team receives an identical set of software requirements. Each team can use up to ten days to design, write, test, and deliver their software.

After Ten Days:

Each team emerges from the two rooms: the software developers and the middle managers. One representative from each team presents their software application.

The outcome requires no amount of imagination. The software developers present a working application. Some facets may have rough edges, but the application, as it stands, works and roughly fulfills the original requirements.

The middle managers likely present documents; hand-wave about disagreements; talk about how they exercised team-building; but the likelihood of any software delivery ranges into the absurd.

Conclusion:

Left to themselves, the software developers completed a complex, rigorous, and time-limited challenge and delivered software. The middle-managers deflected the clear instructions into something they understood, but failed to deliver software.

Discussion:

Some might argue that this thought experiment is unfair to managers. Perhaps. But I would argue that placing middle managers with no software development experience into highly technical conditions is unfair to the middle managers.

Why do organizations and enterprises put the weaker member in front of the stronger member with regards to software development?

Clearly, software developers will go much further working independently, than almost any other group, given the conditions of this thought experiment.

Questions Raised:

  • Why do organizations and enterprises put the weaker member in front of the stronger member with regards to software development?
  • Does middle management belong in the software development team?
  • What implications does this have on scrum?

Now, get out of my thought experiment.