Login
User Name
Password
Existing approaches did not help to solve the "software crisis", i.e. current software still does not meet our exepections and is way to expensive. Unfortunatelly, we became used to reduce our expectations to what seams to be possible. It became difficult to dream about the ideal software. This way of thinking is even part of standard requirement management processes: we talk about "Needs" that are organized. Only what is needed is worth to be processed. "Wishes" are to vague to deal with. ("deal" in the meaning of "handle" as well as in the meaning of "making busines with".)
We all live in the world we created together and go along with conventions that seam to help us in achieving our goals. Just, imagine we could leave these obstacles behind and focus on our original goal again: create amazing software systems with fun for us developers and our customers.
Why some approaches invented to master the development of complex software systems did not really help to do so?
The principles of architecture are based on the assumption that a static object is going to be constructed. The conditions of the environment need to be known and valued. If they are not, buildings most likely crash. If the conditions change significantly, they crash. There are no "versions" of buildings, i.e. the construction does not need to deal with changes to the original idea applied through its existence.
In software development there are no static outcomes. The blueprint is already too complex and issue of constant change, to be a reliable templete for the resulting system. Software are dynamic complex systems - buildings are not. The knowledge about the software system grows and changes with the system, so the human factor needs to be considered. Architecture, though a great tool for creating some of the most wonderful objects create by human beings, simply does not match to software development, and its patterns are not useful to be applied here.
Engineering is the art of composing complex systems from less complex parts. Analytical thinking, "decomposing" the target system, downsizing complexity, these are some principles coming with engineering. They did great service to construct such astonishing objects like cars, airplains, mobile phones. These "tools" of the human mind also helped to create some less desireble systems like atomic bombs or the "well" organized holocoust. (Sorry for these examples. For Germans born after 2nd world war it became national duty to question the principles which allowed such excruciating outcomes). Of course, this wide spectrum of outcomes simply uncovers the power of analytical thinking - we leave it to the philosophers to judge about good or bad. Despite this enormous power, engineering applies well only to systems that can be "constructed", i.e. where parts can be designed and created independent from others. In that sense, systems created by engineering certainly are complex, but they are not dynamic complex systems, where each part may influence other parts. While changes of small parts in a software systems can effect the whole system significantly, we need to identify and deal with all aspects of these parts, not just those aspects that are identified by "small" interfaces, hiding information that seams not to be relevant for the whole.
To create successfully software systems, we need to learn from well working dynamic complex systems. E.g. society, economics, higher organisms, the human brain.
As dictatorial systems proved to fail for connected societies (e.g. states connected to others), deterministic approaches like architecture or engineering proved to fail when it comes to create complex software systems that are connected with human beings.
Holistic Programming applies principles of society, economics, higher organisms, the human brain, to software development.
Contact • Data Privacy