This is the first in a series of (hopefully) amusing posts into Robert Martin’s SOLID principles. It’s written as a dialog between Socrates and a student named Loej in the spirit of the dialectic method popularized by Plato. I hope you find this enjoyable.

The other posts in this series can be found below.

• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion

Socrates, who is the narrator of the dialogue.

Loej, who is but novice at the master’s feet.

Socrates: Welcome Loej. Today let us discuss the fundamental concern of software engineering. What is the chief concern of software engineering?

Loej: I know this one. It’s complexity.

Socrates: Indeed! And what is the chief cause of complexity in software development?

Loej: All those squiggles and curly things?

Socrates: Let me ask this another way. What is the one thing that customers always do?

Loej: Oh. They change their minds.

Socrates: Right! And when they change their minds, what do you do?

Loej: Try to talk them out of it.

Socrates: (Chuckles).

Loej: Right. Never works.

Socrates: So customers always change their minds. And what happens when they change their minds?

Loej: Usually we have to go back and make a lot of changes in the code.

Socrates: And what happens when you must change your code?

Loej: It depends on the size of the change, but usually it requires a lot of work just to try and not break anything. We have to tack a lot of stuff on. We have to break other stuff open. One changes usually ripples through a lot of the code. It gets pretty messy.

Socrates: What do you mean by pretty messy?

Loej: More complex.

Socrates: And when you say tack stuff on and things ripple?

Loej: Well, sometimes we have something that depends on something else, and that something depends on something else, and so on. One change might need two more which might cause four more, and so on.

Socrates: So change can lead to a geometric increase in complexity. We agree software engineering’s chief task is managing complexity. And we agree that a major contributor to complexity is change. So then our task must be to manage change in order to manage complexity.

Loej: But is change really the fault of developers? Isn’t this about poorly written specifications, lack of detailed requirements, customer’s needs shifting during the project, etc?

Socrates: Yes all of these things contribute to change, but they in turn are a results of a more fundamental aspect of software engineering. As Steve McConnell puts it software design is a wicked problem.

Loej: What’s a wicked problem?

Socrates: A wicked problem is one that is not fully understood until a solution has been formulated.

Loej: Then it’s impossible to solve!

Socrates: No. It is partially understood leading to partial solutions. Through the process of solving the problem, we gain better understanding of the problem.

Loej: Which then gives us the right solution!

Socrates: Sadly, no. There are no right solutions to wicked problems, only better solutions.

Loej: That’s lame.

Socrates: Indeed. So how do we get really good solutions if we must solve a problem to better understand it?

Loej: I guess we have to solve it many times, possibly over and over until we are done.

Socrates: In other words we must iterate. And what happens in each iteration?

Loej: We have to change the solution.

Socrates: Now we are getting somewhere. So change isn’t ancillary to software engineering is it?

Loej: No, it is a fundamental part of the process.

Socrates: Correct.

Loej: Well what can we do? How do we deal with change when it can be so disruptive?**

Socrates: Ah! Now you are asking the right questions. Ponder what we have discussed and we shall talk again soon about some insight into this question called SOLID.