It's the duty of the architect to solve the problems inherent in essential complexity without introducing accidental complexity. ——Neal Ford
Model-Driven Development with Executable UML：Preface
Logical complexity of software systems is one of the main factors causing problems and errors in their planning, design, development, testing, deployment, maintenance, and use. There is a common understanding that building complex software systems requires careful planning, good architectural design, and well-controlled development processes. Many good books and papers, as well as all software engineering curricula, address this issue and yet, many software projects fail, miss their deadlines, or exceed their budgets. Building or maintaining a complex system (be it software or not) is always connected to a risk of mistakes and missed requirements, because humans (who are supposed to build the system) are intrinsically prone to errors when handling too many details and interrelated components at a time.
However, logical complexity is not completely inherent to software systems. On one hand, there is an inevitable component of complexity that is inherent to the very problem domain a software system deals with. The term essential complexity refers to that part of logical complexity inherent to the problem domain, and not introduced by a solution or the implementation technology used for it. Essential complexity is, thus, the ‘‘natural’’ part of complexity that cannot be removed and will exist in every solution to a problem, simply because a simple solution to the problem does not exist. However, essential complexity stands in contrast to accidental complexity, which arises purely from the implementation technology, tools, and methods applied in a solution. While essential complexity is unavoidable by any approach chosen to solve a problem, accidental complexity is caused by that very approach.
One of the main tasks in software engineering as a discipline is to discover means to minimize accidental complexity. Accidental complexity is to be minimized in any good software architecture, design, and implementation.
Sometimes, accidental complexity can be caused by mistakes such as ineffective planning or project management, or a low priority placed on a project. However, some accidental complexity always occurs as a result of solving any problem. For example, the complexity caused by out-of-memory errors in many programs is an accidental complexity that occurs because someone decided to use a computer to solve the problem [Wiki].
Another significant cause of accidental complexity is a mismatching or immature technology or process selected for the development of a software system. If the available technology (including the language used for software development) requires the developer to write more words or perform more actions to specify a design decision than is really necessary, the artifacts of the development will be accidentally complex. Using an assembly language to implement a non-trivial algorithm, and using a file system interface to build a database application are simple, extreme examples of such mismatching technology. A less obvious example of such accidental complexity is when some code has to be written to specify that a relationship between two objects has to be established when one object is dragged and dropped on the other object. This can be done in an easier and more direct way, by demonstration.
For that reason, raising the level of abstraction of the technology used for development of software systems, and doing so in a way that it better matches the problem domain of those systems, is one of the basic means for guarding against accidental complexity. Raising the level of abstraction is one of the main characteristics of the evolution of software engineering as a discipline. As Bran Selic once said, ‘‘There has been no revolution in software engineering since the invention of a compiler.’’ In other words, once we understood that we did not have to talk to the computer in the language its hardware understands, but rather we can do it in a language that is more suitable for us, and which can be automatically translated into the language of the machine, we made the most significant breakthrough in software engineering. Everything since then has basically been all about raising the level of abstraction of the language used to program machines.
The point of raising the level of abstraction is to achieve better expressiveness. By using a language that better matches the problem you want to solve, you can say more ‘‘facts’’ in fewer ‘‘words.’’ This also means that you can do more with less work. In addition, written words do not have to be the only way to communicate with the machine. Pictures (such as diagrams), motions, and sounds (for example, spoken words) have already been a mode of communication between humans and computer programs, so they can be in software development, too.
