The Software Complexity Triangle

On recent projects, while drinking the koolaid of delivering simpler, more usable software, I have noticed a Software Complexity Triangle similar to the well known Project Management Triangle. The points on the Software Complexity Triangle are Simplicity, Power, and Design:


On this diagram, Simplicity represents the ease of using a system, both for end users as well as for operational support or back-office staff. Power represents the overall capability and depth of functionality of the system. Design represents the expertise of your software development team, particularly the depth and breadth of their technical skills as well as their knowledge of the problem domain in which they are working.

It is possible to fix in place or optimize for one or two points of the triangle, but the third point must compensate accordingly and cannot be held constant:

• Most development teams can create unpowerful software that is simple to use.
• Most development teams can create powerful software that is difficult to use.
• It takes a highly skilled team to create software that is both powerful and simple to use.
  

The last item is of key interest. As an example, on our primary project it is critical that our software be simple to use, yet the operations it must perform are unavoidably complex. Our design team has spent many long hours searching for the right balance between power and simplicity on various portions of the system. Often, the end result of our requirement and design discussions results in something like this:

Usually (after recovering for an evening or a weekend) we are able to grind through the issue and eventually create a good solution. But it takes considerable time and effort. Other implications when developing a simple+powerful system are:

• Planning: Be prepared to spend a lot more time on requirements, designing, prototyping, and reviewing until the combination is right.
  
• Hiring: Your team must contain a great depth of domain knowledge - it will not be sufficient to attack the problem with technical wizardry only. Working by rote against a typical listing of functional requirements, use cases, etc. will not deliver a solution of any great value. A true understanding of the real business problems and opportunities to which the system will be applied is critical.
  
• Back Office software: "Back end" processing software may need a higher degree of sophistication than the typical mishmash of scripted processing routines.
• User Interface: It takes an open mind and considerable time and attention to detail to look at your system with the eyes of a new user.
  

It many cases it is inappropriate to force simplicity and power into the same system (or portion of a system). A reduction in complexity, or less emphasis on simplicity, may be appropriate. Keep in mind the alternate paths this potentially puts you on:

• Less simplicity results in more user training and documentation. This is not acceptable if your audience is the general public, but may be appropriate if user staff is relatively small.
• Less simplicity may cause the need for a "Man Behind the Curtain" to make the system work. This might be OK for small systems, but typically does not scale well.
• Less power: Be certain that your requirements for high end functionality are really necessary - it is often surprising and rewarding to examine requirements through the lens of ROI, schedule impact, and alternative solutions.