Saturday, December 28, 2019

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

Thursday, December 26, 2019

Reading Log: Righting (sic) Software. Part 1

Hey all. I'm trying something new for a while. I'm going to be reading two books re: software engineering in the next few months. I'm going to write down my thoughts about each part as I read it. This is mostly an exercise to help me solidify understanding of what I'm reading.

As an aside, one of my dreams is to run an online book club about software engineering. It'd be a Twitch stream where we discuss a reading assignment once a week. We'd pick a book together and assign a few chapters. People who read / contribute get special twitch emotes or something.

For what it's worth, it's 4 AM and I'm awake holding my daughter. Who is probably awake because her teeth hurt. There's an outside chance she's just awake to be a jerk. We're watching LBB on Netflix. That stuff is baby crack.

Merry Christmas, btw.

K, part one of Righting Software. Just the intro so far.

~~~
First of all, this dude pulls no punches. He's like "Everybody sucks at software. Except for me. So I guess I'll teach you how to deliver working software on time, on budget, and defect free". This is in stark contrast to my usual philosophy. My current philosophy, informed mostly by Ron Jeffries "The Nature of Software Development", is that everybody sucks terribly at software. So, instead of like, trying to estimate costs better, or plan better, or whatever better, we should just deliver one feature at a time, minimizing complexity and maximizing quality.

Ron's approach reduces the need for up front planning. But it does ignore some realities: Particularly "How are we going to pay for this? How many devs do I need to budget for? When can I tell the boss we'll recoup some of this money?". The "Screw everything we're agile" plan works super well when you have a fixed budget and loose timeline. It has lots of merit. But Juval Lowy (except with two dots over that 'o') points out that reality frequently requires that stuff. So, uh, I guess we're going to plan stuff.

This comes at a good time for me, though. Google is a big company and they expect me to plan. My manager isn't really buying the "it will be done when it's done" approach to my code. He also keeps wanting estimates about when this stuff will be done. Seriously though. I've never successfully estimated anything in my life.

It occurs to me that I have never delivered any meaningful software on time or on budget. I've written some fantastic software. I honestly feel really good about myself as an engineer. My quality is generally really high. My code is legit. I don't feel really bad about missing our "deadlines". Like, they were arbitrary, right? And our great working software continues to win the market. But yeah, my project management has historically sucked.

Juval says that a software architect is responsible for designing two different things. One is the software. That's what you and I always do. This component and this module and that framework etc. This is what I think of when I think about "software architect."

The second thing an architect is responsible for designing is the plan to build the dang thing. Or rather, the project design. "If there's no reasonable way to build it, why design the software part of it?". So apparently projects require design. That's the planning, estimation of costs, etc. I have no idea what this looks like yet. This is a massive change from my current modus operandi.

Basically: I approach life with the base assumption that "planning is futile. We cannot possibly know how long this will take. So we'll completely finish the smallest, most important part you can define. We'll just keep doing that until we run out of budget. I hope that you have something really great at the end :)"

Juval says that's bullcrap and that we should be effectively planning projects. He posits that "applying sound engineering practices from other (real) engineering disciplines" makes this easy. Given that literally all of us suck terribly at this, I'm not yet convinced. But I'm excited to see what his process is.

I'm committed to trying it out. I'll keep writing about it as I read. I've got a new small project starting up at work, and I'm one hundred percent going to run this method on it. I'll practice all the steps and let you know how it goes.

~~~

Good news: My daughter finally decided it was time for bed. That's legit. I'm going to bed too. I'll see y'all soon.

Please drop me a comment if you read this thing. Like, I don't actually expect visitors. But let me know if you're here because that will definitely make me more likely to continue this project.