Lean Architecture II: Agile Feature Architecture

A system not simple enough to understand can't work

In the 1960s, a programmer could translate requirements more or less directly into code that could be reviewed, verified, and approved in a desk check by a colleague knowledgeable in the field. As Trygve Reenskaug (inventor of Model-View-Controller) notes, we lost this ability in the 1980s. Why? Because of object-oriented programming. Objects have many advantages as discussed in Module 2, but they lose the ability to reason about what the system does by looking at the code. This means that desk checks have less value today than they did in the FORTRAN days and that we have resorted to testing for quality assurance. Yet testing cannot reason about the absence of bugs in code; it can detect only their presence. We need to do better.

Further, Agile has taken us away from requirements to User Stories that are a promise for a future discussion between a programmer and a customer. The tester never isn't mentioned in this perspective, and the fact that we now rely so heavily on testing for quality should be reason to worry. The fact that most Agile techniques put test writing in the hands of developers is even more reason to worry, and numerous formal studies have shown that TDD does not and cannot live up to its claims of supporting the architectural desiderata of decoupled and cohesive objects.

In this course, we look at the process constructs for managing requirements in the software design and coding phase. Given that you have a base architecture or any base platform of pre-existing code, where do user scenarios fit? They are not objects; yet, in a good OO world, they are not functions. And they must be managed in a way that sustains a good interface, going beyond the Agile value of "working software" to "usable software." Lightweight Use Cases as advocated by Alistair Cockburn, co-signer of the Agile Manifesto, come to bear as a major enabler in customer collaboration and as a way to deal with change and to raise the chances of delivering working software. Again, minimizing the number of methodological artifacts and maximizing the expression of design concerns directly in code, these techniques contribute to high feature velocity. Using techniques developed by Trygve Reenskaug and popularized by the course's instructor, this course shows how to retain the structure of requirements directly in object-oriented code. The approach depends on a four-pronged approach to design that uses not only classes and objects, but also roles (and their implementation as interfaces), as well as context definitions that map roles onto objects at the beginning of every Use Case.