Novel Tech Truths by Ron Lichty

stories, yarns and whimsy about making tech work “hum” 

Sometimes it takes fictional narrative (cleverly written to closely resemble the realities within which we all live) to drive home not so much the “how” of new ways of doing things – but the “why.” 

There's been a genre of engineering-lesson novels that share just such important principles and best practices in the guise of fun reads. Many of them are even beach reads. With holiday weekends and vacations coming up, with their promise of rare reading time, here are six fun reads worth taking along…

The Goal (Eliyahu M. Goldratt and Jeff Cox) is the granddaddy of them all - at least of this list. It turns out every manufacturing plant manager has read this book, and a lot of us in software, too. In my case, I had an SVP boss at Schwab who gave all his reports a copy. Despite it’s being a novel, you’ll learn the core principles of lean, starting with the Theory of Constraints.

Goldratt’s main character is the manager of a manufacturing plant with a seriously screwed up process—even as the guy’s marriage is falling apart, mainly for lack of attention, but in part for he and his wife not knowing their goal.

In the course of the story, the manager learns that trimming capacity to market demands actually reduces throughput and increases inventory - because of dependent events and statistical fluctuations. Then on the next day’s boy scout hike, one kid is the bottleneck. To puzzle out solutions to the hike - and the plant - the plant manager gets several scouts to move matches from bowl to bowl, testing fluctuations to see effects. He realizes - aha! - only by increasing throughput through the bottleneck can he increase throughput overall.

Interestingly, as manufacturing-centric as this novel seems to be, it’s hard to have a career in software without Goldratt, The Goal, and the Theory of Constraints coming up in conversation now and again.

The Deadline by Tom Demarco is the granddaddy novel of software. Demarco is the software process guru who wrote Why Does Software Cost So Much?, Waltzing with Bears, Slack, and Peopleware. This one embeds lots of principles of productivity and of teams:
    ▪    Don’t take chances on team jell if you don’t have to: Seek out and use pre-formed teams.
    ▪    Then keep good teams together to help your successors avoid problems of slow-jelling or non-jelling teams.
    ▪    Think of a jelled team - ready and willing to take on a next effort - as one of the project deliverables. 
    ▪    Why does the effect of pressure on programmers max out after only a 6% productivity gain? Demarco’s answer: People under pressure don’t think faster.
    ▪    The only real variable you have to play with to improve productivity is the proportion of work hours that are effective.... You must focus entirely on avoiding wasted time.

The Phoenix Project (Gene Kim, Kevin Behr, and George Spafford) took the decades-old The Goal (which the authors admire) and applied it to DevOps. If your job is keeping systems up and running, you need to understand the difference between planned and unplanned work (aka firefighting) - the latter the most destructive kind of work since it gets in the way of doing planned work - and is avoidable - and must continually be eradicated.

A kanban board helps everyone involved see (and limit) work in progress. And it may help you see your current constraint (aka bottleneck) - which you need to protect by creating "a trusted system to manage the flow of work to the constraint.”

Until you manage the flow of work to the constraint, the constraint is constantly being wasted, is likely drastically underutilized, is almost certainly not being applied to paying down technical debt, and is not contributing fully.

“Any improvement not made at the constraint is just an illusion…. Make sure the constraint is not allowed to waste any time. Ever. It should never be waiting on any other resource for anything, and it should always be working on the highest priority commitment." And be sure you reduce reliance on the constraint for unplanned work.

Then (Step 3 from The Goal) figure out how "to subordinate the constraint" - a la moving Herbie, The Goal’s slowest Boy Scout in the troop, to the front of the line to prevent the rest of the scouts from getting too far ahead. That is, set the tempo of work based on the constraint’s tempo.

You have to split your team’s time, spending cycles not just on features but also on "stability, security, scalability, manageability, operability, continuity." Then leverage your constraint, who very likely knows the most about where your technical debt is and how to build code designed to avoid unplanned work.

Always remember: “Outcomes are what matter - not the process, not controls, or, for that matter, what work you complete."

Predictability by Steve Bockman features, as its main character, a software development manager. In the opening paragraphs, he's walking down the hall when his boss, the VP Engineering, pops out of a meeting with the head of product to ask, "Bob, how long will this new project [that you've never heard of] take? I won't hold you to it." Yeah, right.

OK, there are way more issues than estimation to delivering predictably, but Steve Bockman invented the Team Two-Pass Relative Estimation method that is, for most of us who have used it, a big leap over Planning Poker (which itself is a big leap over what came before). Your biggest challenge, when you finish reading Predictability, will be realizing that its simplicity actually applies to your project. Trust me, it does.

Chapter 12 describes the relative sizing method that's become known as the Bockman Sizing method - the team two-pass relative sizing technique I teach every team I train. Steve also has a 99 cent ebook on Amazon that's just the method, if that’s all you need. But need or not, and whether you do agile or not, you’ll enjoy Predictability!

Outsource or Else (Steve Mezak and Andy Hilliard) takes on outsourcing. Its main character, a startup VP Engineering, is challenged to add massive functionality to his product with little additional funding and just six months until the VCs will shutter his company. Jason has been having no success hiring developers one at a time in Silicon Valley. But a recent spectacular failure has given the alternative, outsourcing, a bad rap. It gives Mezak and Hilliard opportunity to introduce their “7 Keys of Software Outsourcing,” many of which apply not just to outsourced teams but to distributed teams of all kinds.

There’s a secondary story in this novel. The VPE and his wife hire a landscaping company to do their backyard, only to realize that their misfortunes with the project are directly related to having followed none of the 7 steps above (and that the general contractor has failed them for having followed none of the 7 steps in hiring his help.)

Rolling Rocks Downhill (Clarke Ching) will clear up any questions you have about why continuing down the path of practices that repeatedly yield bad quality and missed deadlines is madness - and why the only sensible thing to do is (if somehow you don’t know about them already) to invent agile and lean practices.

Frankly, the first half of the novel is too long. But the rest – once our hero finally realizes he has no choice but to change paths – is superb: highly engaging, and close to the truth of software development and corporate life in almost every way. It will also reassure you that changing paths, even dramatically, can be done in a step-by-step way.

(Worth noting: Goldratt is also a hero of this author's.)
I invite nomination of other engineering-lesson fiction!

Enjoy your summer!