Did any of the principles Martin states stand out?

Classes should be small, with narrow and well-defined responsibilities. I think this is one of the most critical things you can do to avoid spaghetti code. There’s one specific bit of advice here that I think is useful:

“We should also be able to write a brief description of the class in about 25 words, without using the words ‘if’, ‘and’, ‘or’, or ‘but’.”

I often find myself doing this in code with JavaDoc. It might be redundant, but stating outright a simple and concise description of the class can be useful for straightening out in your own head what you’re doing. It can also be useful for maintainers to help avoid scope creep, assuming that they’ll read the JavaDoc. I used to write pretty comprehensive documentation of this type, but I’ve found it less likely to be properly maintained and far less likely to be read.

However, I am not a big fan of the definition of Single Responsibility Principle.

“The Single Responsibility Principle (SRP) states that a class or module should have one, and only one, reason to change.”

The words “reason” and “change” are just too vague and non-specific here. I suspect the aim is to be more specific about what we mean by “responsibility”, but in my mind it just clouds things. Let’s think about bugfixes, documentation, refactoring. Are these reasons for change, or do such things not count as change? Which of these are part of the responsibility of the class? I agree strongly with the SRP, but not with the definition given; I think it makes it harder to internalise the concept.

I found the discussion of Cohesion to be strange. I think that Martin is right about the idea of classes being cohesive, in particular with this comment:

“When cohesion is high, it means that the methods and variables of the class are co-dependent and hang together as a logical whole.”

I’m just not sure how this is separate from the SRP, unless the intention here is to present this as a simple analysis method to help identify SRP violations. That seems to be what happens in the example given, as Martin identifies groups of variables and splits them off into their own classes with their own responsibilities.

“Many of us think we’re done when the program works”. How to combat this attitude?

The Agile Manifesto⁴, which Bob Martin was an original signatory, states the following:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

It also states:

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

So my counterpoint would be: are we sure that this is a problematic attitude? In SCRUM⁵, Sutherland talks about a contract where if the project was finished early, half of the remaining budget would be returned. Using SCRUM methods and continuous delivery, the project finished several months ahead of schedule. A win-win for everyone, right?

So who wins when developers refine working code in the name of maintenance that may or may not happen? What happened to the YAGNI principle?

I’m being slightly facetious here. If we wrote code this way, with delivery above all else, the result would always be a big mess of hot garbage. There’s a reason that the Agile Manifesto also states that:

“Continuous attention to technical excellence and good design enhances agility.”

I think that developers should be trying to write good code from the start, and I agree with the quote above, that we should strive for “technical excellence” and “good design”. However, I would not overthink what Martin says about not being “done when the program works”. I would especially avoid thinking that code should be continually refined after it works in the name of future maintenance. There’s a balance to be had here, and context will matter a lot.

What ideas do you have for approaching maintenance of complex code systems?

Despite what I said above about the definition of cohesion, I think the following advice is critical.

“When classes lose cohesion, split them!”

This is something I regularly do, both of my own volition (to improve code quality) and because it has to be done in the name of further maintenance. Splitting up classes, isolating responsibilities etc. I find it is often necessary when maintaining complex systems.

Ideally, the end goal of such things is to get rid of the “complex” part of the system. If everything is neatly compartmentalised with well-defined boundaries, then each part is a system that has ‘clean’ inputs and outputs. Then you hopefully have a lot of smaller, non-complex systems. You can look at each one in isolation, add tests, documentation, etc.

If such a thing does not exist, one of the first things I try to do is to see if it can be brought into being. In my experience, investing time to break up the code using SOLID principles⁶ pays off.

Are there any tradeoffs that stand out to you when it comes to designing systems for change?

I think it’s impossible to have a meaningful discussion about this based on this specific section of Chapter 10. Designing for change is something we have to do at all levels of the code, from our overall architecture down to the access modifiers on our variables. In this section Martin references various SOLID principles⁶ such as the Dependency Inversion Principle and the Open-Closed Principle, but there’s not enough exploration of those here to work with.

From my own experience (and from other books on this subject) there is really only one real pitfall in designing systems for change. Maybe it takes a little longer, but it’ll pay dividends almost immediately so that doesn’t matter. It might mean writing more, smaller classes; but we’ve already seen discussed at length the benefits this brings. So what is the pitfall? Martin describes it perfectly in Clean Architecture:⁷

“So there you have it. O Software Architect, you must see the future. You must guess—intelligently.”

The problem is predicting what might change. Sometimes you can do this so efficiently that you can hide a predictable future development behind a switch, and look like a rockstar when you save the day. Other times you might waste days developing an abstract system resilient to almost any change, only for it to be dropped entirely (never mind not being changed!). Figuring out what might change and why is a skill like any other.

When you’re developing new things do you separate design/construction?

I often do, but it usually isn’t a formal process. Some doodles in a notebook, or even just spending time thinking about it. I can spend months thinking about my plan for large-scale work, with the output being relatively minimal tickets with notes on them. Perhaps this isn’t ideal, but in my experience you need a plan for the high-level stuff. The lower-level stuff can be developed by applying standard design patterns and so on.

I have recently been learning more about Domain-Driven Design (DDD) approaches, and I think there’s a lot of merit to this approach. In particular the idea that there is no such thing as “no design”. Such a thing just means designing “on the fly” which could lead to wasted effort. Various DDD pillars are referenced in this chapter, such as the Domain-Specific Language.

Do you have any recommendations for tools which aid in development?

It’s taken me a long time to get my head around DDD, but that’s been one of the biggest aids to development. Perhaps it is not a “tool” in the traditional sense, but it’s helped me to reorient how I approach development in a way that’s made me a lot more productive. Martin’s Clean Architecture⁷ has also helped.

Do you think the broader approaches outlined can be applied to smaller-scale tasks (such as bugfixes and features)?

This chapter discusses various high-level concepts and architectural approaches which should be applied to larger, cohesive pieces of work (such as within a library or module). I think it’s hard to apply any of the methodologies discussed here on a small scale, especially if doing so violates conventions/styles in other code.

“Modularity and separation of concerns make decentralized management and decision making possible. In a sufficiently large system, whether it is a city or a software project, no one person can make all the decisions.”

Modularity and separation of concerns is something done at a higher level, so it needs to be approached at a high level, not as a part of routine development work.

The only thing that I think can really be applied to small-scale development work is the application of a Domain-Specific Language (DSL). Development and maintenance of the DSL is an ongoing task that involves many (or all) of the stakeholders for a project. So I don’t think it can arrise out of small bits of work, but it can be applied and perhaps maintained in an ad-hoc basis alongside smaller bits of work.