Reading Log: Righting (sic) Software. Part 2

Holy fetch. Leave it to Nate Cunningham to be lurking on my dead-for-several-years blog and comment within a few days. Truly impressive! Thanks Nate. You're the man.

Here comes part two of the reading log. I'm experimenting with writing these things a few days after I do the reading. This forces me to consult my notes and revisit some of my thoughts. Perhaps it will help with retention.

~~~

Juval is about to sell us his "Method", which is his specific method for planning and designing software projects. I'm naturally wary of anybody selling me a "method" to do anything, especially one that is "Completely unique to me and is guaranteed to bring you riches and success". Feels like something from my spam folder. That being said, everything I've read so far has been good.

He says that Method = System Design (the software...) + Project Design. This is actually sort of a big deal. Only that I've never considered project design to be anywhere near as important as system design. He asserts that we all suck at delivering working software on time because:

• Project design is strictly harder than system design
• We study and practice system design, and none of us have ever read a book about project design

I don't have data about his first assertion, but I can tell you that I'm a grown-man-who-thinks-he's-good-at-this-stuff and I've never even considered project design as being a concept I should try to be good at. I guess this just wasn't something that I thought belonged to my profession. It's like waking up after four years and being like "Oh man, I was supposed to file taxes every year?". 

 A few more nuggets:

• We need to validate the high-level system design early. If we spend three months building something before we figure out that the architecture won't actually work, we're pretty boned. 
• How do we do that? As part of the project design, you should make sure that work is done early that will reveal whether or not this architecture is going to fly. I'm sure he'll talk about this more, but this feels a lot like some of the Agile ideas -- Build a very thin vertical slice to prove it'll work.
• "Designs" are really a filled out decision tree. Specifically, any design is a leaf on a decision tree. See https://en.wikipedia.org/wiki/Decision_tree for the details of that. I had never thought about it this way. This analogy works really well for computer science nerds. We use trees a lot. But we also spend a lot of time simplifying, or pruning, trees. Trees get big fast. But if we know certain decisions don't work, we can prune off the entire subtree that follows that decision. 
• Designing a project or system should be a time-boxed endeavor. Juval basically says "You should design in three to five days. Any more and you'll just be adding unnecessary fluff". 

So, in conclusion: You're going to produce a decision tree for your system design in about four days. And then you're going to spend the next four days producing a decision tree for your project design.