"Agile software development is about iteration not oscillation"
Jim Highsmith (paraphrased), Agile 2009

"Kanban is the science of not trying to do too much at once"
Stephen Palmer, 2012

"The structure of a software system will reflect the communication structure of the team that built it."
R. E. Fairley

"If you can't explain it simply, you don't understand it well enough."
Albert Einstein

"Use models to find out how things work or to find solutions to puzzling dilemmas. Create models to communicate ideas and understand things you can’t see. Recognize models and the countless ways models are used for working, playing, teaching and explaining. Assess models for what they do and don't tell you about the real thing and how useful they are"
Boston Science Museum

"The complexity of software is an essential property, not an accidental one. ... Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size."
Frederick P. Brooks, The Mythical Man-Month, 1995

"Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the program."
Gerald M. Weinberg, Quality Software Management: Volume 1 Systems Thinking, 1992

"As the number of people increases, the ways they can interact tend to multiply faster than you can control them."
Gerald M. Weinberg, Quality Software Management: Volume 1 Systems Thinking, 1992

"chaos often results when a project's complexity is greater than its managers' ability to direct meaningful progress toward a goal."
Ken Schwaber, Agile Project Management with Scrum, 2004

"When people are factored in, nothing is simple. The complexity of individuals and individuals working in teams raises the noise level for all projects."
Ken Schwaber, Mike Beedle, Agile Software Development with Scrum, 2002

"It usually takes more than three weeks to prepare a good impromptu speech."
Mark Twain

"Simplicity is the final achievement. After one has played a vast quantity of notes and more notes, it is simplicity that emerges as the crowning reward of art."
Frederic Chopin

"Man will occasionally stumble over the truth, but most times he will pick himself up and carry on."
Winston Churchill

"We apply the analytic procedure in order to create a conceptual framework within which we can draw conclusions about the means by which a system solves its tasks. Indeed, we do this with the express purpose of establishing a solid foundation from which we can carry out a subsequent synthesis. This synthesis, in turn, acts to verify the conceptual model as an explanation. The process is an iterative one."
Tom Ritchey, Refactoring, 1991,

"I guess that as you go along you try to fill your tool-box, so that when you face these circumstances you have more options to choose from"
Jonny Wilkinson, Tom Fordyce's Blog, 2009

"Speech is conveniently located midway between thought and action, where it often substitutes for both."
John Andrew Holmes

"We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process"
Glenford Myers (via jJeff De Luca)

"Information Technology is 80% psychology and 20% technology "
Jeff De Luca, www.nebulon.com

"Deliver frequent, tangible, working results"
Peter Coad

"Perhaps the worst software technology of all time was the use of physical lines of code [for metrics]. Continued use of this approach, in the author’s opinion, should be considered professional malpractice."
Capers Jones, Applied Software Measurement

One goal for a process designer is to make their process straightforward to learn and remember so that following it becomes habit as quickly as possible.

When we examine two developers writing a software application in their spare time we see little that we would call a formal process. However, when we examine a project with hundreds of developers distributed across multiple locations working to develop a large software system, process often seems to be all we can see.  Both examples do have process, but the first is much simpler and very informal.  It is most likely maintained wholly within the minds and interactions of the two developers who, over time, have learned to communicate very effectively with each other.  In larger projects, the processes tend to be both much more visible and much more formal, although you will still find many small ‘processes’ in a large organization that are hidden, ‘understood’, or part of the tribal knowledge and not recorded anywhere. In fact the processes (not necessarily productive processes) that last the longest are those that become habit; ‘it’s just the way we do things here’. One goal for a process designer is to make their process straightforward to learn and remember so that following it becomes habit as quickly as possible.

So what are the fundamental differences between two developers writing software in a garage and thousand-person, multi-million dollar software development efforts?

Those who work in the real estate industry tell us that the three most important aspects of real estate are location, location and location. The software development process equivalent is communication, communication and communication. Communication is taking place constantly within a software development process at every level.  In fact, no process (work) can occur without it!  In failed projects, communication, or failure of it at some level is usually a major contributor to the project's downfall.

If we consider developers as nodes in a communication network all potentially linked to each other by communications channels, then there is only one channel between our two developers in their garage.

However, as we add more developers, the number of potential communications channels grows geometrically.

Between four developers there are six potential communication links. Between ten there are forty-five potential links and there are 4950 potential communication links between a hundred individuals on a team.

If not managed, there will either be too much time spent communicating and nothing will get done or there will be too little communication and results will not integrate and work together.

As a team grows larger, managing communication becomes increasingly difficult.  


Communication requires language. Within a development team different sub-teams use different languages. Some of these languages are textual, others are graphical and others are more mathematical in nature. There are languages for expressing requirements, defining interfaces, defining database tables, for communicating analysis and design models, for describing algorithms, for describing patterns, and a myriad of different programming languages for communicating instructions to a computer. Much of the work of a development team involves translating from one language into another ...

... and then of course, to add to the mix, there are communication channels and languages required to communicate with customers, users and sponsors of the project.

Each time we translate from one language to another there is a potential to lose information or communicate the wrong information. Errors can occur when converting statements made during verbal interviews to structured requirements and diagrammatic models, adding documentation to the models, developing persistent storage models, and even creating the code. If information is not accurately transferred at each of these ‘interfaces’, we have the potential for building the wrong system. Therefore, we want to keep the number of translations of information to a minimum and to automate as many of the translations as possible to reduce the chance information is not lost.

To further complicate matters, at each step along the way, the people involved in transferring the information may not know what they need to communicate.  For example, the user defining the system may not know what it is that they really need.  They may end up describing task steps or symptoms of a larger problem without actually communicating the needed functionality.  So not only can we make errors in translating the information from one form or medium to another, we may not even be translating the right information! Therefore a good process uses numerous feedback loops to provide validation and verification as often and as early as possible.

Another big problem preventing communication is the fear of being wrong. If a user, manager, analyst, or developer is so scared of being seen to have made a mistake that they withhold information, clear communication is obviously compromised and the error is often compounded over time. It is right that we should have accountability within a project but our software development processes should encourage and support an environment of trust and responsibility rather than one of suspicion and fear of recrimination.

A software development process describes what to communicate, when to communicate, how to communicate and to whom to communicate (most process descriptions will not tell you why; this is normally left for someone to write a book about!).

Follow me on Twitter...