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


"What we don't like is needless complexity."
Richardson, Ruby, RESTful Web Services, 2000


"Abstraction can reduce complexity by spreading details across a network of components"
Steve McConnell, Code Complete: A Practical Handbook of Software Construction, 2007


"The fundamental task of the software development team is to engineer the illusion of simplicity"
Grady Booch, Object-Oriented Analysis and Design, 2007


"Our failure to master the complexity of software results in projets that are late, over budget, and deficient in their stated requirements."
Grady Booch, Object-Oriented Analysis and Design, 2007


"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


"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


"We break a problem down into smaller and smaller problems until we have reduced the size of the problems to something we can manage,"
Stephen R. Palmer, John M. Felsing, A Practical Guide to Feature-Driven Development , 2002


"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


"Our primary tool for design is abstraction. It allows us to effectively use encapsulation, inheritance, collaboration, and other object-oriented techniques."
Rebecca Wirfs-Brock, Alan McKean, Object Design: Roles, Responsibilities, and Collaborations, 2002


"... the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain is not handled in the design, it won't matter that the infrastructural technology is well conceived. A successful design must systematically deal with this central aspect of the software."
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, 2003


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


Complexity in its many forms is the arch-enemy of software development; the complexity of the problem domain and requirements, of working in teams, of the technologies involved, and so on.


The brains of human beings have a finite capacity. Our minds can only handle so much system complexity at a time. This is certainly true in my case, and unfortunately, the situation is not improving as I get older.

The complexity of even small, modern software applications is simply enormous, and complexity grows non-linearly as the size of a software system increases. In fact, Gerald Weinberg argues that complexity grows, at least as fast as the square of the size of the program. He calls this the size/complexity dynamic of software development.

The complexity of a piece software derives from two different systems or models if you prefer that term:

The Problem domain

The first system is that of the real world problem we are working with. In enterprise systems, this is the concepts within the scope under consideration, their structure or organisation, and the way various people in different roles both inside and outside of the enterprise use them to do business. More generally, software designers refer to this system as the problem domain. Peter Coad defines the problem domain for a piece of software as the field of endeavor under consideration. The more concepts involved, and the more ways they can be combined, structured and used, the more complex the problem domain becomes.

There are a number of different ways to analyse a problem, but object-oriented and component-based approaches have dominated in enterprise software development for approximately the last fifteen years. After all, every team working in .Net, Java, or Cocoa has some sort of object model at the heart of their software, and I have found no better technique than Peter Coad's 'modeling in color' for the initial, object-oriented analysis and design of enterprise software. This is especially true when that analysis further informed by the patterns and strategies Nicola, Mayfield, and Abney's, Streamlined Object Modeling and Eric Evans's Domain-Driven Design.

Read more about analysis and design...

The Technical Architecture

The second system is the technological one used to provide the solution required, the number and nature of the technology components involved. Even as early as the 1970's Fred Brooks argued in his first essay within The Mythical Man-Month that software crafted for a specific individual to use is at least three times simpler than the same software turned into a product so that it is applicable to hundreds, thousands or even millions of people. He also argued that the same software turned into a reusable component of a larger system is roughly three times as complex again.

Tackling Complexity

Today a web-based system designed to serve multiple concurrent users, even if it is only a handful at a time and not the millions required by enterprises like Amazon, eBay, Google, Facebook, Microsoft, IBM, or Apple, etc., has far more technical complexity than an old traditional single-user application of comparable functionality.

The two main techniques we have for handling complexity are:

Decomposition and integration

Decomposition and integration is the breaking down of a problem into smaller and smaller pieces until each piece can be solved easily and then putting these small solutions together to form solutions to the bigger problems until the overall solution is achieved.

Abstraction

Abstraction is the ignoring of details of a problem that are not relevant to what we are currently doing. This makes it easier to work with the details that are. Abstraction enables us to solve a problem in simpler, more general terms first and subsequently address specifics of the problem in detail

Other Complexities

Other equally complex systems are involved in the development of any non-trivial piece of software. These are complex purely because their fundamental components are human beings. They include:

  1. The system of humans, the project team, that are designing and building the system, and the organisation or structure of the project team, the roles and responsibilities, and the ways the team members communicate and interact with each other. Given enough time two friends in their garage could produce very large and complex software systems by solving one small problem after another. Adding more people to the team allows us to solve many of the small problems in parallel and deliver large systems quicker. The more people we add, the more we can do in parallel. However, the catch is the more people we have working in parallel, the more we are likely to bump into communication and coordination problems. If there are significant dependencies between the problems being solved, then we have to work hard at putting the right communication channels in place so everyone has the information they need at the right time. This turns the problem into primarily one of managing communication.

    Read more about communication....

  2. The system of humans, the customer team, that are specifying and sponsoring the construction of the software. Similarly, and sometimes even more so, the various egos and personalities within the customer organisation and the way they work or do not work together forms a system that is complex to navigate and negotiate with.

In fact, the human systems are generally more complex to deal with than the problem domain and technology systems. Hence, Jeff De Luca's first law of information technology: I.T. is 80% psychology and 20% technology.

Follow me on Twitter...