Monday, April 11, 2016

Relearning Design Patterns

In Relearning Design Patterns, Egon Elbre observes that a critical piece of information missing from Design Patterns: Elements of Reusable Object-Oriented Software is a pragmatic outlook on how and when to apply design patterns. Egon points to Christopher Alexander and his idea of pattern languages as a solution.

Pattern languages have the benefit of describing a system of patterns that support each other. It's a nice approach that has the potential to clarify when, and perhaps more importantly, when not to use a design pattern.

For example, the code I work with has a high occurrence the Singleton pattern. No other patterns are made explicit, except possibly Model-View-Controller. My challenge is that our design uses the Singleton to present one of something because there currently is only one of those things. The use of a Singleton introduces constraints that shouldn't be in the design.

If our code base modelled an airplane, it would have a singleton for the engine on a single engine plane, completely ignoring the fact that many planes have more than one engine. The Singleton places an arbitrary constraint on the design where none should exist and this introduces needless complexity into our domain.

In my view, the designers didn't view the domain in terms of appropriate and inappropriate constraints. Our implementation is the poorer for it. If they viewed the domain in terms of a pattern language they may have realized that using a Singleton for a jet engine assumes there will only ever be one engine. They may have recognized that a jet plane has the potential to support multiple engines. Recognizing this would have identified the Singleton as a poor design choice.

A classic case of when all you have is an idiom everything looks like and instance of it. Or perhaps that was a hammer.

In another example, I've recently had the opportunity to build a client-side library for a web application. At one point, I played with the notion that that a Singleton would be appropriate for managing the client session with the server. My initial rationale for this was that I knew the client would be run as a standalone application by a person using it on the command-line.

I ultimately rejected the Singleton because it placed an arbitrary constraint on the client-side library. I recognized that it's presence in the implementation would guarantee I limited the use cases supported by this library.

Tuesday, April 5, 2016

Working Agreements for Agile Teams (Part 3)

Curiously, I'm writing on branching policies again. In Working Agreements for Agile Teams, I discussed the problem with ambiguity. In Working Agreements for Agile Teams (Part 2), I discussed how the best working agreements are principles.

The issue of our prescriptive and ambiguous branching policy was raised and we agreed to rewrite it. This time I proposed
We agree to use topic branches for development.
This led to a discussion on why it's reasonable to disagree with this working agreement. For example, is it necessary to use a topic branch for a one line change? To improve a comment? My answer to these question is that it depends upon the code review.

We have another working agreement in which we agreed to peer review all code prior to merging it to the main line of development.

This led to a discussion on the interaction between working agreements. This discussion reenforced my thinking that good working agreements are principles and that reasonable people can construct arguments on when and when not to apply them.

I place a great deal of emphasis on product quality and what is merged into the main line.  Topic branches are irrelevant to product quality, although they can have an important role in ensuring it. In effect, my reasoning reflects my values regarding product quality and this reasoning motivates my choices.

If working agreements are principles and principles reflect values then what do your working agreements say about your team?