Links - 5th November 2017

Avoid “thin” classes. Ideally, a class should have a very simple interface that hides a lot of functionality and internal complexity; said another way, its ratio of volume/(surface area) should be large. I call such classes “sweet”; in general I use the term “sweet” to refer to software systems that have a high ratio of power/complexity. A thin class is the opposite of this: in the worst case, the interface is just about as complex as the implementation (i.e. I could have rewritten the class in the same time it took me to learn how to use it). The classic example of a thin class is one that implements a linked list. There’s no interesting functionality being hidden here, so there’s almost no advantage in having such a class; it just adds to the system’s complexity.

Think of classes as martyrs. The best classes are those that bring suffering on themselves to make the world a better place for everyone else. It’s okay if a class is complicated internally, as long as it presents a really simple and powerful interface to the rest of the world. Of course, it’s even better if you can figure out how to decompose the class internally so it’s not so complex. But if complexity is inevitable, better to encapsulate it in one class rather than spread the complexity across a large number of callers. Or, said another way, push complexity down, not up.

Many people in the Agile movement preach that teams should have responsibility for the outcomes they produce and the impact of those outcomes. But responsibility starts at the top and is passed down to teams. When IT is managed as a cost center with cost objectives passed down through the hierarchy, it is almost impossible for team members from IT to assume responsibility for the business outcomes of their work. When IT metrics focus on cost control, digital transformations tend to stall.

Every “full stack team” working on a digital problem should have “full stack responsibility” for results, and that responsibility should percolate up to the highest managers of every person on the team. Business results, not cost, should receive the focused attention of every member of the team, and every incentive that matters should be aimed at reinforcing this focus.