This month, the methodology issue, is a good opportunity to take a look across a whole swathe of my bookshelf and deal with it all at once. The important point to bear in mind is that methodology is about the approach you take to building software. That means how you decide what to build, plan it out, design it, implement it, test it, deploy it, document it, and manage (and even pay for) all of that. The 1990s was the decade when object-oriented techniques hit the mainstream: it was also the time of the methodology wars.
Agile programming is more than user stories on index cards, in the same way that Object-Oriented Programming is more than a language that lets you write self.foo() instead of foo(). In fact, the two are very closely related: Extreme Programming rose out of experiences running projects that used Smalltalk, and many of the Agile Alliance are OOP experts. Much was written about OOP as a methodology, but now when people critique it they are mostly talking about their experiences with a programming tool. Let us recover that understanding of how to build software by thinking in objects.
In 1991, Grady Booch published Object Oriented Design: with Applications. “With applications” because five chapters describe the design and implementation of software using his method, in five different object-oriented languages. By applying object-oriented design, Booch said, “we achieve a greater level of confidence in the correctness of our software through an intelligent separation of its state space. Ultimately, we reduce the risks of developing complex software systems.” Sounds like he is saying it makes it easier to reason about code.
Booch’s method is an iterative, incremental approach to designing software that fits best into a similarly iterative, incremental methodology. It involves identifying the classes and objects at a given level of abstraction, identifying their semantics, identifying the relationships between them, and implementing them. It is iterative in that the design informs the analysis and implementation, the implementation informs the analysis and design, and the analysis informs the design and implementation. It is also iterative in that the analysis, design, and implementation at one level of abstraction influences the work performed at the levels above and below. It is incremental in that there are many ways in which you can deliver the designed and implemented parts of a system without having to deliver the whole system.
A chapter on “pragmatics” links object-oriented design to the methodology in deeper ways. Object-oriented design benefits from object-oriented programming, though you can of course do it in any language. Object-oriented programming benefits from object-oriented tools, though you can of course do it with Notepad and a machine monitor. It also benefits from object-oriented staffing, an object-oriented approach to release management, testing, and all the other things.
And it has drawbacks. Booch is clear about the risks of adopting OOD, particularly in 1991. There were performance problems associated with dynamic method resolution that could have significant drawbacks in deployment (but on the other hand, dynamic method resolution made development much quicker, by letting you modify your program live and only rebuild the modified parts). That is no longer true: the same advances in processing power that enable fancy type systems also make it fairly quick to run message dispatch systems. And those themselves have got faster, through theoretical advances in virtual machines and garbage collection.
But one of the biggest drawbacks was that programmers needed to change mindset. Booch recommended a three-step training scheme:
- Provide formal training to both developers and managers in the elements of the object model.
- Use object-oriented design in a low-risk project first, and allow the team to make mistakes; use these team members to seed other projects and act as mentors for the object-oriented approach.
- Expose the developers and managers to examples of well-structured object-oriented systems.
Has this even happened now? I have had a total of two weeks of formal training in the object model (involving UML, which we will come to later): the first by Sun Microsystems, in 2008, and the second by the University of Oxford, in 2016. I have an impression that this is two weeks of formal training more than many developers receive in any approach to software design (though let us not pretend that useful software does not get written despite this).
Booch’s method is very similar to many other contemporary methods of object-oriented design. In Designing Object-Oriented Software, Rebecca Wirfs-Brock and coauthors describe a comparable design method with comparable benefits and drawbacks. “The object-oriented approach attempts to manage the complexity inherent in real-world problems by abstracting out knowledge, and encapsulating it within objects. Finding or creating these objects is a problem of structuring knowledge and activities.”
Some of the details are different from the Booch method, but the broad strokes are the same. When Booch identified classes, they got entered into a collection of diagrams expressing static and dynamic characteristics of the classes and objects. When Wirfs-Brock identified classes, they got written up on index cards based on Ward Cunningham and Kent Beck’s Class-Responsibility-Collaborator cards. Slightly different diagrams identified relationships between classes.
Alongside all of this, there was a growing realisation that significant benefits in object-oriented processes and their adoption could be realised by combining these “competing” methods, integrating the nuanced differences in each and providing a standard representation that benefited from network effects. This process had started in 1989, when multiple vendors formed the Object Management Group consortium to define a vendor-neutral approach to distributed objects.
When it comes to object-oriented design, people realised that as the field matured, engineers needed a core set of principles, not a specific prescription of activities. The OMG adopted a technique that combined the methods of the Three Amigos: Grady Booch, Jim Rumbaugh (Object Modeling Technique), and Ivar Jacobson (Object-Oriented Software Engineering). OMT, OOSE, and the Booch method came together to form the Unified Modeling Language, UML. The UML tells you what you need to know to design object-oriented software, but does not tell you the exact process to acquire that knowledge. Methodologists can still promote their methodologies, IDE vendors can still sell their IDEs, and now everybody understands what everybody else is talking about.
Of course, the story does not stop there. People have extended the ideas listed above, either to address missing gaps or to stake a claim on virgin territory in the object-oriented frontier. David West’s Object Thinking—which reveals that the object-oriented approach is a philosophy not a design tool—expands the CRC card to a six-sided object cube. Side one is the CRC card. Side two describes the nature of the objects. Side three lists the method contracts (particularly visibility: public, protected, private). Side four describes the information needed by the objects, where they gets that knowledge, and where they keep it. Side five lists all of the messages and method signatures. Side six describes events that the object will need to listen out for.
Another attempt to stick extra dimensions into the object-oriented design language came from the authors of Java Modeling in Color with UML. This adds four colours to the UML, conveniently (and tellingly, when we think about the longevity of the diagrams created) the four pastel colours typically found in a block of sticky notes.
The colours represent archetypes, top-level abstractions that imply broad characteristics of behaviour. These archetypes are:
- Moment-interval (pink)
- Instances or durations in time that are important in the problem, and thus in the software.
- Role (yellow)
- A way in which an actors participates in the system.
- Description (blue)
- A collection of attributes and values that are consistently used in relation to a given object or context.
- Party, Place or Thing (green)
- A real-world person, location, or object (sorry) represented as a software object.
In addition to providing modeling tools beyond the basic UML, the Java Modeling in Color book additionally gifts us a whole new methodology called Feature-Driven Development. You would probably recognise many of the aspects of FDD, even if you would not bundle them under that name. Two-week iterations, focused on client-valued features. Design and build by feature. Replace detailed use case documentation with single-sentence feature and feature set descriptions: though these take a different form from user stories, focusing on domain model concepts rather than stakeholder intents and actions. A feature set may be called “Making a product sale to a customer”, within which one feature is “Calculate the total of a sale”.
But you may not recognise other characteristics of FDD. Develop an overall model and features list before you start (while your engineering department may not know this, your marketing, sales, operations, and executives have actually already done this, and they call it the roadmap). Organise a feature iteration around a chief programmer, but organise the implementation expertise around class owners—reinforcing the point that object-oriented programming is a staffing issue not just a programming language trick. No long-running teams; constitute new feature teams every iteration.
Rebecca Wirfs-Brock suggests that while the object design methodologies of the early 1990s were helpful, they were overly simplistic. By overly relying on identifying concepts in the problem domain to reify in the software, they missed out on important techniques of abstraction that come from looking for concepts that are implied or absent in the problem domain. She points to Domain-Driven Design by Eric Evans as a better, more flexible way to incorporate these ideas and drive a software design. It represents a constructivist philosophy, in which the problem’s structure arises from the ways people communicate about it, rather than the previous positivist philosophy in which the problem is taken as “real” and its properties measurable by experiment.
Ivar Jacobson, one of the Three Amigos of Object-Oriented methodology, went as far as to abandon methodology entirely, as in his book The Essentials of Modern Software Engineering: Free the Practices from the Method Prisons! Jacobson and co-authors say that methodologies are fundamentally flawed, as they are rarely empirically justified and replacing one methodology with another typically jettisons much that is good in addition to much that is bad. They prefer a systems thinking approach, where what we currently do creates software with certain characteristics (maybe late, buggy, and well-documented) and we consider how changes to practices affect the process and characteristics (maybe cutting back on documentation improves lateness, makes bugginess worse, and reduces documentation quality but within acceptable limits).
So, what do we learn from the methodological explosion and continuing evolution of object-oriented design? I will turn the last word to Tom Love, co-founder of object-oriented tools company Stepstone (who guided Objective-C through the early years of its development). In his 1993 book Object Lessons: Lessons Learned in Object-Oriented Software Development Projects, Love looks forward to Software Development in 2002 (a decade after writing, not publication!). He argues that groupware and computer-supported collaborative working would be commonplace by then, “we should find real-time, full-motion video-conferencing facilities in every sizable development facility in five years”. Turns out this actually needed a pandemic to happen, and took way longer.
He predicts that NeXT will need to find a new way to sell their software to succeed at driving object adoption—and indeed they did. He predicts that “Microsoft NT++”, an evolution of their workgroup software, would remain important—and indeed it has. He predicts that there will be greater recognition that software development is a team activity, and of course this has come to pass too. But he also predicts that the microcomputer of the future would be running a variant of OS/2, and that we would have recognised the power of the spreadsheet: the way to solve the software crisis is to make everybody a programmer. Today’s computers have fewer, not more, facilities for user empowerment.
Cover photo by the author.