What we do all day as software developers just doesn't fit very well into words. We craft patterns of behavior for computers - and these patterns are their own best description. Sure, we can talk about software, and we can certainly itemize the characteristics and capabilities of our code, but these are static views of a dynamic system. We can no more fully comprehend complex software from a set of APIs than we can visualize the grace and power of an Olympic athlete from a list of his or her internal organs.
It often seems better to just read or write the code than try to capture its dynamic aspects with language. Years ago, Unix programmers would be instructed to "Use the Source, Luke" when confronting undocumented or incorrect behavior from the system. The manuals were but a shadow of the truth; reality lay within the code itself. More recently, a whole movement has been born from frustration with useless documentation and related processes. Agile software development is the 21st century's reluctant acceptance of the injunction given to young Skywalker so long ago. But if we cannot say what we have done with any accuracy, we may not really know.
Software development today is like a medieval craft with each product hand-forged using knowledge known only to the guild. This is a torturous situation, because it seems our occupation ought to be akin to engineering - more of a science than an art form. But engineering utilizes mathematics and models to describe systems using a precision and methodology that is lacking in the usual activity of designing and writing software.
This situation is tolerated in the industry because there has never been a very good alternative. The plethora of tools, configuration systems, code generators and frameworks have failed to simplify the task of software creation, not to mention the ability to effectively create an up-front design or useful documentation. Instead, at every step of the evolution of the software industry, the methods used to simplify yesterday's problems only seem to introduce their own new complexity.
The techniques described in this book will help change this industry standard scenario for the better.
But first we must understand the innate structural problems of software in order to truly appreciate the need for the solution. The root cause of these issues is, in fact, the frail nature of the atomic unit of most of modern software projects –the object-oriented class. Because of the inherent weakness of this flawed foundation, all other aspects of developing software become unstable. Cogiton technology differs from other systems in its unique approach to this challenge.
To make an analogy to the physical world, most software projects are scoped for in a manner akin to that of a very bad real estate developer planning a new subdivision. The developer studiously maps out the location for each house, where the streets should go, the placement of the shrubs and the location of the light posts—but neglects to actually design the interior of the houses! Until an architect actually lays out a floor plan for each of those houses and determines the materials that will go into them, there is no way to predict the ultimate cost of the project. No banker would finance any kind of deal based on such flimsy planning, but software projects are launched every day with just as little known about their ultimate requirements as this doomed subdivision.
What is missing in object-oriented development today are techniques that allow us to frame out our classes and to know what the scope and complexity of each will be. Traditionally developed object-oriented software often suffers from four structural weaknesses. At scale, these issues make the code extremely fragile, which makes software development and maintenance unpredictable - and unpredictability is bad for business.
Let us now briefly outline the four key defects of modern, object-oriented software.
