Complexity Made Simple

We present a simple conceptual model of what constitutes complexity and simplicity in design engineering. At the core of the model are the three concepts of 1) scale (how many things are there), 2) diversity (how many different kinds of things are there), and 3) connectivity (how many relationships are there between things). The model distinguishes essential from accidental complexity (i.e., the complexity that we, engineers, add while designing), and intrinsic versus perceived complexity. The model also articulates the complexity of the thing (or system) we design or observe versus the complexity of the community around the system: its users, designers, manufacturers, sellers, other systems, etc. This model is then used to articulate a set of heuristics to address complexity: reduce, hide, shrink, organize, explain, expose.. Finally we open the toolkits of engineers in various disciplines to identify strategies, methods, or tools that they can use to address complexity: design principles, guidelines, design methods, patterns, tactics, frameworks, etc. Approaches such as modeling, abstraction, partitioning can then be described in terms of our key concepts and heuristics; e.g., “abstraction reduces perceived complexity”. This conceptual model helps engineering students to better reflect on their practices of design, and how these practices vary across disciplines. It also provides a more systematic approach to answering the never ending question: “how can you make this simpler?”

[1]  Cynthia F. Kurtz,et al.  The new dynamics of strategy: sense-making in a complex and complicated world , 2003, IEEE Engineering Management Review.

[2]  Philippe Kruchten,et al.  Experience teaching software project management in both industrial and academic settings , 2011, 2011 24th IEEE-CS Conference on Software Engineering Education and Training (CSEE&T).

[3]  Donald A. Sch The reflective practitioner: how professionals think in action , 1983 .

[4]  HERBERT A. SIMON,et al.  The Architecture of Complexity , 1991 .

[5]  John A. McDermid Complexity: concept, causes and control , 2000, Proceedings Sixth IEEE International Conference on Engineering of Complex Computer Systems. ICECCS 2000.

[6]  Grady Booch,et al.  Object-Oriented Analysis and Design with Applications , 1990 .

[7]  Audris Mockus,et al.  Formulation and preliminary test of an empirical theory of coordination in software engineering , 2003, ESEC/FSE-11.

[8]  Max Jacobson,et al.  A Pattern Language: Towns, Buildings, Construction , 1981 .

[9]  John Maeda,et al.  The laws of simplicity , 2006, Design, technology, business, life.

[10]  R. Kazman,et al.  Design approaches for taming complexity , 2012, 2012 IEEE International Systems Conference SysCon 2012.

[11]  Philippe Kruchten,et al.  The Frog and the Octopus—Experience Teaching Software Project Management , 2011 .

[12]  Grady Booch,et al.  Object-oriented analysis and design with applications (2nd ed.) , 1993 .

[13]  D. L. Parnas,et al.  On the criteria to be used in decomposing systems into modules , 1972, Software Pioneers.

[14]  Philippe Kruchten,et al.  New Venture Design – Interdisciplinary Capstone Projects at UBC , 2011 .

[15]  D. Schoen,et al.  The Reflective Practitioner: How Professionals Think in Action , 1985 .

[16]  Jan Bosch,et al.  From software product lines to software ecosystems , 2009, SPLC.

[17]  Herbert A. Simon,et al.  The Sciences of the Artificial , 1970 .

[18]  Paul Clements,et al.  Software architecture in practice , 1999, SEI series in software engineering.

[19]  Murray Silverstein,et al.  A Pattern Language , 1977 .

[20]  Walker Royce,et al.  Software Project Management: A Unified Framework , 1998 .

[21]  H. Simon,et al.  The sciences of the artificial (3rd ed.) , 1996 .