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.
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.
- 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.