Human Nature As Applied to Software Development

Human nature, both at an individual cognitive level and a group social level, strongly influences software development methods.

Human Nature As Applied to Software Development

In his introduction to his  interview with Fred Brooks, John Cook has another great passage.

The shelf life of software development books is typically two or three years, maybe five or ten years for a “classic.” Frederick Brooks, however, wrote a book on software development in 1975 that remains a best-seller: The Mythical Man-Month. His book has remained popular because he wrote about human nature as applied to software development, not the hottest APIs and development fads from the 1970’s.

The implications of human nature in constraining software development, whether at an individual or team level, are probably the least appreciated challenges in doing a software startup, second only to the need to find a paying customer.

As entrepreneurs, we have to change before we can change the world. If we want to take our customers beyond their current limits, we must map and respect our limits and those of their co-founders and team. Plans that don’t recognize reality, in particular acknowledging and respecting our limits as well as leveraging our strengths, don’t come to fruition.

PostScript

“I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.”

Fred Brooks in “The Mythical Man-Month“

I think this is a key challenge at both the individual cognitive level, can I come up with a design I can understand and make sure it’s viable, and then at a group or team level can I communicate it and enable a sense of shared purpose or common mission,

“Most great works of the human mind have been made by one mind, or two working closely. This is true of most of the great engineering feats of the 19th and early 20th centuries. But now, team design has become the modern standard, for good reasons. The danger is the loss of conceptual integrity in the product, a very grave loss indeed. So the challenge is how to achieve conceptual integrity while doing team design, and at the same time to achieve the very real benefits of collaboration.

[…[

“Most great works have been made by one mind. The exceptions have been made by two minds. And two is indeed a magic number for collaborations; marriage was a brilliant invention and has a lot to be said for it.”

Fred Brooks in “The Design of Design” Chapter “Collaboration in Design”

Melvin Conway crafted what is now known as Conway’s Law: the communication patterns and organization of the team designing a system are built into the finished product as strengths and weaknesses. In the same way that we have rules and formulae for how to design with wood, bricks, or steel, Conway’s Law is one example of what’s needed to build an effective organization out of people to enable them to design effective systems.

Related Blog Posts

• Eben Moglen: Steel to Software to Collaboration
• The Future, Arriving Yesterday, Remains In Constant Motion
• Innovation Principles from Ken Iverson’s “Plain Talk”
• A Half-Fast Entrepreneur with Half-Vast Experience
• Fred Brooks’ “No Silver Bullet” Revisited
• Finding And Adding People Successfully to Your Startup Team
• Plus Minus People