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.