Reading Log - Righting Software - Apparently Chris Sucks at Design

Gotta write quickly, because it's getting late and I'm going to bed earlier this year.

We're finally to the meat and potatoes of Juval's advice on system design. As a reminder, system design is the design of the software, not the design of the project.

remember, system == the thing you are building, and project == the steps you'll take to build it.

System design comes down to decomposition. Decomposition is when you take one thing and break it down into many smaller things. Why would you want to break a software system into smaller things? Three good reasons:

1. Decreased cognitive load. You can reason about 15 lines of code far better than you can reason about 150 lines of code. You can understand a "module" better than you can understand an entire system. Humans can handle smaller pieces better. It's just the way we are.
   
2. Better testability. You can write software that will exercise your modules and warn you if things aren't working as you expected. This is way easier to do on a "piece" of a system instead of "an entire freakin' system".
   
3. Protection from change. Software keeps changing. Requirements change, customers change, etc. You're going to have to change your software this week. How do you make sure you don't break everything when you make that change? You isolate the thing that changes in its own module. This is the big reason for decomposition. Decomposition, if done correctly, will make maintaining your system easier.

Juval said he was going to tell us the absolutely worst way to decompose a system. Then he proceeded to explain the way I've been designing software for the last five years. So, you know, I've got that going for me.

There are two ways to decompose a system. Functional decomposition and Decomposition by Volatility. 

Functional decomposition is when you separate the capabilities of your system into their own modules. If your software can slice potatoes, dice potatoes, and bake potatoes, you would end up with a sliceModule, diceModule, and a bakeModule. 

The problem here is that when anything changes in your software, there's a high probability that the change has to take place in all three of those modules. Example: When we built the system we were expecting peeled potatoes from the supplier. Now a customer has said we have to support dirty potatoes fresh from the farm. We change the software to accommodate it. Now sliceModule, diceModule, and bakeModule ALL need to modified. This sucks badly compared to...

Decomposition by volatility. Decomposing stuff by volatility sounds fancy but isn't. It means that you separate modules based on things that could reasonably change. Let's work on the potato factory, and hopefully this gets a little more clear. (aside: this was not the example in the book. I'm making this up as I go).

Our potato system needs to produce sliced and/or diced and/or baked potatoes. Is it reasonable that customers might expect or need a different way of preparing potatoes in the future? Are we going to boil potatoes? Are we going to, err, cut potatoes in half instead of dicing them? We see that these are likely things that will change in the future. We don't want to program anything that's outside of the requirements right now, but we do want to leave a seam so we can change it in the future. The way we leave that seam is by pulling "preparationMethod" into its own concept and "cookingMethod" into its own concept. We have a module that allows us to "prepare" a potato the way we want, and a separate module that allow us to "cook" the potato the way we want. "PreparationModule" is going to let us slice potatoes, dice potatoes, cut potatoes in half, etc. etc. The way that other modules communicate with preparationModule makes us not give a crap about how they were prepared. We just know we're getting prepared potatoes out of the deal.

Gonna have a cookingModule. Gonna have a "getMeThePotatoes" module, because the way we get potatoes is going to change over time. 

His idea is that we find out what might change. We group things that change for the same reason together in a module. Things that change for different reasons go in different modules. The dream is that a reasonable change that the system has to undergo will only affect one module. Like, that's the dream. But if we can isolate changes into one module that has a well-defined interface to the other modules? Well that's just gravy.

~~~~

Quick gratitude journal because E is waiting for me to go cuddle him (it's 12:30 AM, btw)

• I'm grateful for fast food. It is available and I am blessed to be able to afford it way more often than is healthy. I know my kids will eat it. I know it will be reliably tasty. And I know it comes with diet coke, which brings me happiness. When life gets tough (and it often does), I can count on McDonald's to offer fries that will satisfy my children, diet coke that will calm my nerves, and a McDouble without pickles that will make my wife love me again.
  
  Today I went to three different fast food places. We stopped at Freddy's because Torchy's had a very long line. The burger was not lovely, but the fries were great and they had good fry sauce, which is hard to find in Texas. We needed a treat, so we stopped at DQ and got some blizzards. My kids were very cute and ate lots of our shakes like the little pigeons they are. After an unexpected Wal-Mart run, me and the babies got McDonalds, as they had been asleep when we picked up Freddys. We intended to save them some fries from Freddy's, but that proved a fool's errand. So we got a 10 piece McNugget and a Big Mac for five dollars. I love that mix n' match deal they throw up during off-hours.
  
• I'm grateful for my wife being supportive and kind even when things don't work out. As long as she is well-fed she is very kind and patient with me.
  
• I'm grateful for my cute kids. I read T a book tonight (Elephant and Piggie: There's a Bird on Your Head). She did so good with it. I've really struggled to read books with her in the past, but she ate this one up. She laughed and pointed and talked and all those good things. We bought the book from a cute local bookstore this past... err, I have no idea what day of the week it was. There have been like ten Saturdays since Christmas, so, yeah, it was one of those. 

Speaking of cute kids, I gotta go cuddle that little muffin. Thanks for reading. gl hf.