Theory Outline

I’m enjoying a thorough case of Covid brain fog. Every time I sit down to write, nothing comes out. Since I can’t write what I want to write, I’m going to write something worse: an outline.

My outline so far…

It’s not worse in the sense of being useless, it’s just worse than what I want to write. There won’t be enough here to properly explain any of the topics. My hope is that by laying the theory topics out like this I’ll be able to see more clearly what to do next & that you’ll be able to see where I’m going & ask questions.

The theory of software design has a tangled ball of string problem. I learned the material here over the course of 50 years of programming, meandering in and out, picking up a hint here, a concept there. I have a coherent whole in my head, in the sense that I usually have a clear sense of what I want to do next, but that’s not the same as having a coherent whole that I can explain to someone else. I start to pull on one string & realize I need to first explain something else.

And that topic has another prerequisite. And on and on until I just give up on writing because I can’t hold it all in my Covid-addled head at one time.

Here, then, is my latest attempt to linearize the topics comprising my theory of software design.

Topics

1. Structure & behavior changes. Structure & behavior changes are fundamentally different. Treat them separately.

2. Reversibility. The key difference is reversibility. Structure changes are (usually) cheaply reversible. Behavior changes are (usually) not.

3. Power laws & preferential attachment. Central limit theorem doesn’t apply. This is what cost distribution looks like in software. Contagion is why.

4. Coupling. This is how change propagates in software.

5. Coupling with respect to changes. We don’t care about most coupling. We care about the coupling triggered by the behavior changes we actually want to make.

6. Constantine’s Equivalence. cost(software) ~= cost(change) ~= cost(big changes) ~= coupling. So cost(software) ~= coupling. The first purpose of software design is managing the cost of software development.

7. Coupling/decoupling tradeoff. The fundamental tradeoff is between the cost of coupling & the cost of decoupling (wrt the changes we actually discover that we want to make). Drive too far up either curve & the cost escalates.

8. Opportunity cost & cost of delay. Varying cost of delay dramatically changes the shape of the tradeoff.

9. Kingman Formula. As utilization approaches 100%, delay approaches infinity. Combine that with the cost of delay & you see why running hot is so economically expensive.

10. Optionality. Quick intro to options theory & its application to software design. Main point being that options increase in value as uncertainty increase. Embrace change, mf.

11. Cohesion. Coupling can be hard to reduce. Cohesion is almost always easy to increase.

12. Beneficially relating elements. Finally I can define what I mean by design: beneficially relating elements. Define all 3 words and how they go together.

13. Grand & inspiring conclusion. What we’ve talked about. What we’ll talk about next—design as an exercise in the human relationships on a team. Reminder to practice.

Conclusion

As carefully as I’ve thought about all this, I still reordered pretty much all of the topics as I made the above outline. I expect to re-order & re-slice them again as I write. No wonder design is hard.