Book Review

Escaping the Build Trap by Melissa Perri

If you find either of these books interesting and wish to acquire them, please use an independent bookstore. My favorite:

https://www.thethinkingspot.us

I belong to a book club where most of the participants are active software development professionals. This book is the current reading and practice selection. I believe that part of my target audience for Feral Cogitation includes practicing software development professionals who, I hope, will find my observations and comments (sometimes criticisms) of current practices and ideas to be of use.

I need to preface the review with some history.

When I began my professional software career, in 1968, my job title was, roughly, programmer. But I was required to spend a lot of time learning banking; including quarterly training courses in all aspects of banking. I was, essentially, a banker who knew how to code. The applications I developed were discrete and focused. I could code, test, and deploy an application, by myself, in one-to-three weeks. I could, immediately, see the value of my work in terms of increased revenue, profits, or work-flow/job-satisfaction.

Also in 1968, Software Engineering was defined and promoted as an academic discipline. At first, the domain, almost always a business, mattered. The first text books, for example, would devote the initial two-three chapters to studying, modeling, and decomposing, the domain; conducting interviews to identify user needs or desires, and identifying the business value of any proposed solution so that an optimal solution could be selected and implemented.

By the mid-1970s, Software Engineering abandoned to domain entirely. Developers had to know nothing about the business, nothing about people or their concerns. The business was supposed to provide developers with complete, unambiguous, and concise “specifications” or “requirements” and developer would simply, “build to spec.”

In 1968, the bank paid a little over one-million dollars for the Burroughs mainframe with 256K memory, four reel-to-reel, tape drives, a line printer, and a ‘reader-sorter’ that input data from MICR codes at the bottom of paper checks and deposit slips. It also paid, roughly, one-hundred-thousand dollars a year for maintenance, including a hardware engineer who spent two days a week on-site to trouble shoot and maintain the hardware.

The cost of applications, the software, was nearly insignificant. Three weeks wages for one programmer.

Again, by the mid-1970s, the cost of software was increasing exponentially; ten to one-hundred times the acquisition and maintenance costs of the hardware, combined.

Business Management panicked.

First reaction: consolidate all the work being done into a single project (e.g., an inventory control system, an accounting system, a sales support system). Then budget for, usually, one such system per department per five-year interval.

Second reaction: blindly adopt methods and principles from other types of engineering, like bridge building, along with a production-based approach borrowed from Henry Ford. Impose rigid management focused on making a plan and ‘fixing’ any deviations from that plan. The only thing that mattered, “on-time and within budget.”

The results of these decisions and reactions was disastrous; the oft-cited fifty-percent abandoned projects; one and two-hundred percent cost and time over runs, maybe ten-percent of delivered systems were delivered “full-featured” and “working.”

No concern for the systems being useful, useable, or providing any business value.

Thus, the context to which Melissa Perri, in Escaping the Build Trap, responds.

Marquetly, the fictional company used to illustrate the approach of the book, as described in Chapter One, is precisely what one would expect—chaotic and failing—to result from the decisions made fifty years ago. Lacking any understanding of the domain of education or of educators, Marquetly is driven by the demands of investors (30% growth rate) and idiosyncratic interests of directors (mobile strategy).

“You’re stuck in the Build Trap. To get out, you need to change the way you approach software development, both as a company and as a leader. You have to become product-led. That involves shifting the entire mentality of the organization from delivering to achieving outcomes. You will have to change your structure, your strategy, and not only the way your work but also the policies and rewards governing it.

Are you ready for this amount of change? It won’t be easy, but it’s 100% possible.”

Clearly a daunting task.

The book then proceeds to ‘outline with examples’ how to escape the build trap. [my comments]

1. I. Differentiate between

   a. Project—amalgam of requirements, [roughly] waterfall managed

   b. Product—“vehicles of value”, meet customer need(s) [author cites Excel, Tinder, baby food, and the iPhone as products, but, at that scale, it is super easy to fall into a minor-project mentality and practice. I would prefer ‘apps’ (or the kind of applications I wrote in 1968) as products. Or, perhaps a single XP user story. Something that a single team might build and deliver in a couple of weeks.]

   c. Service—human time dependent [a lot of companies are fooling themselves that AI’s will provide an unlimited supply of human-equivalent service providers]

2. II. Define the ideal product manager

   a. Role

   i. Understands company vision

   ii. Interacts well and listens to customers—defines ‘need’

   iii. Elicits ideas from marketing and design as to possible products

   iv. Collaborates with team to defined possible implementation of those products

   v. [functions as an XP coach, protecting team from management, acquiring resources for team, helps team develop self-government and self-organization]

   b. Responsible for Strategy

   i. Outlines and provides a framework that integrates vision and high-level goals and connects them to the value-producing product portfolio. Not a plan! Multi-year perspective. [Glaring omission, in my opinion, any indication of product managers interacting with the C-suite or participating in Board meetings.]

   c. Coordinate Process (Product Kata)

   i. Understand direction – vision, strategy, product initiative

   ii. Analyze current state

   iii. Set next goal

   iv. Product Process

   1. Problem exploration

   2. Solution exploration

   3. Solution optimization

   d. [Except for its embodiment of responsibility in a single individual, the product manager, this Kata recapitulates what XP argued for: capture a ‘story’ with the customer, think a little (with customer and team), explore a little, design a little, code a little, test a little, deploy a little, repeat.]

3. III. The Product-oriented company

   a. Chief Product Officer

   b. VP of Product

   c. Director of Product

   d. Senior Product Manager

   e. Product Manager—multiple

   f. Asst. Product manager—multiple

   g. Product portfolio

4. The outline is fleshed out with some great illustrative stories of companies and decisions that, at least within the context of the story, aligned and illuminated what the author wanted to convey about product-centric organizations and skilled product managers.

I have two significant problems with the book. The first is common to almost any software development “how to” book written in the past two decades. No understanding of the forces and the half-century old decisions that almost force companies into the Build Trap. The brief bits of history that introduced this review are but part of those forces and but two of those decisions.

The change from a standard issue business to a product-oriented business is even more daunting than what is conveyed in the quote from the book, above. You must overcome decades of momentum from engaging in practices that frequently rewarded those companies while challenging some. But the biggest obstacle is the tacit ‘culture’ that exists in the minds of, essentially, everyone in those organizations.

The second problem concerns the individuals, the human beings, in product manager roles at every level. These are extraordinary people: skilled at communicating and listening to customers and discovering their fundamental problems and issues; equally adept at the politics, organizational issues, and finances of the corporation, sufficient to interact effectively with CEOs, the C-suite, and Boards; Team organization and leadership skills; sufficient technical savvy to not be misled by technical “experts.”

Where to these individuals come from?

You can’t educate them. As the author points out, her own education misled her into misunderstanding her role and purpose, making her almost the antithesis of the great product manager she became.

The only way to become “great” is through a years-long process of mentorship and experience—including making and learning from mistakes. The author does not really discuss how she became ‘great’ other than some asides and minor comments. Still, it is obvious that it was, at least, a decade long process.

Suppose hundreds of companies decide, tomorrow, to adopt the ideas set forth in this book—and they should—where are all those skilled and near-great or great product managers going to come from?