- We Need It Now!
- The Principles Behind This Book
- Why Is Together Exciting Technology?
- Process, Process, All the Way
- What's Next?
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Principles Behind This Book
There are four foundational ideas that we return to several times in the following chapters and which we believe are essential to an efficient and quality-focused development process – whatever tools are chosen to support that process. They are:
Maintaining just one single-source model
Conforming to a minimum meta-model
Evolving through a perturbation change model
Continuously measuring of quality
A single-source model is one which, however many different editing tools are used, keeps its information in one place. This means when the information is changed in one view it is immediately transformed in every other view. Of course Together is famous for its treatment of source code files in this way, and we discuss this aspect of the environment in the next section. But there are many other tools, albeit less comprehensive than Together that take a similar approach. We expect there to be more in the future because this is too powerful an idea not to be adopted by competitors. Not only should the model be single-source, this first principle states that we should maintain just one such model. It is tempting to simply continue practices such as the use of separate logical and physical (or analysis and implementation) models that were introduced when single-source technology was not available. We believe this is missing an immense opportunity. Now we can support analysis-level and implementation-level views of the same one model and as a consequence introduce changes more quickly and much more reliably. We also discuss this aspect in more detail in the next section.
A metamodel is simply the structure of the language used for modeling. As we are using the Unified Modeling Language (UML), its metamodel is our starting point. But UML is a very comprehensive and complex language. In order to work efficiently we need to focus primarily on the bare essentials—the minimum metamodel—that can provide the basis for coherent and consistent development. The elements that we emphasize in this minimum metamodel are requirements, tests, design, and implementation. Simply stated: Each requirement accepted into a build must have a fair set of tests that pass and a design; the design should specify how objects in the system interact with messages to fulfill the requirement, and these objects and messages should be instantiations of implemented classes and operations; each class and operation (whether referenced by a design or not) should have a fair set of tests that pass. The minimum metamodel is explained in more detail later in this chapter.
At one time the prevailing view of how to develop large software systems was the waterfall model with its separate phases, each containing very different types of activities from requirement specification to deployment. The perturbation change model is different, in that its starting point is not a blank canvas but a complete and consistent system. The equilibrium of this consistency is disturbed by the desire for improvement (introducing a new requirement, say) and then the system must be brought back to the complete and consistent state by undertaking some development. Taking small steps—perturbations as we refer to them—results in a process that is evolutionary (moving from one stable state to the next) and iterative (repeating similar types of activity timebox by timebox).
Finally to make iterative evolutionary lifecycles work we must move the measurement of quality from specific points in the lifecycle such as critical design reviews and integration test phases to be an almost continuous activity from the earliest stages of the project onwards. The mechanisms for continuously measuring quality that we discuss in this book are tests, metrics, audits, document generation, and inspection.