In this collection of columns, Eric Brechner's alter ego pulls no punches with his candid commentary and best practice solutions to the issues that irk him the most. He dissects the development process, examines tough team issues, and critiques how the software business is run, with the added touch of clever humor and sardonic wit. His ideas aren't always popular (not that he cares), but they do stimulate discussion and imagination needed to drive software excellence.
Get the unvarnished truth on how to:
Improve software quality and value—from design to security
Realistically manage project schedules, risks, and specs
Trim the fat from common development inefficiencies
Apply process improvement methods—without being an inflexible fanatic
Here is the Contents and an excerpt from the book’s Introduction.
Chapter 1 Project Mismanagement Chapter 2 Process Improvement, Sans Magic Chapter 3 Inefficiency Eradicated Chapter 4 Cross Disciplines Chapter 5 Software Quality—More Than a Dream Chapter 6 Software Design If We Have Time Chapter 7 Adventures in Career Development Chapter 8 Personal Bug Fixing Chapter 9 Being a Manager, and Yet Not Evil Incarnate Chapter 10 Microsoft, You Gotta Love It
You’ve picked up a best practices book. It’s going to be dull. It might be interesting, informative, and perhaps even influential, but definitely dry and dull, right? Why?
Best practice books are dull because the “best” practice to use depends on the project, the people involved, their goals, and their preferences. Choosing one as “best” is a matter of opinion. The author must present the practices as choices, analyzing which to use when for what reasons. While this approach is realistic and responsible, it’s boring and unsatisfying. Case studies that remove ambiguity can spice up the text, but the author must still leave choices to the reader or else seem arrogant, dogmatic, and inflexible.
Yet folks love to watch roundtable discussions with arrogant, dogmatic, and inflexible pundits. People love to read the pundits’ opinion pieces and discuss them with friends and coworkers. Why not debate best practices as an opinion column? All you need is someone willing to expose themselves as a close-minded fool.
In April of 2001, after 16 years of working as a professional programmer at places such as Bank Leumi, Jet Propulsion Laboratory, GRAFTEK, Silicon Graphics, and Boeing, and after 6 years as a programmer and manager at Microsoft, I transferred to an internal Microsoft team tasked with spreading best practices across the company. One of the group’s projects was a monthly webzine called Interface. It was interesting and informative, but also dry and dull. I proposed adding an opinion column.
My boss, Bill Bowlus, suggested I write it. I refused. As a middle child, I worked hard at being a mediator, seeing many sides to issues. Being a preachy practice pundit would ruin my reputation and effectiveness. Instead, my idea was to convince an established, narrow-minded engineer to write it, perhaps one of the opinionated development managers I had met in my six years at the company.
Bill pointed out that I had the development experience (22 years), dev manager experience (4 years), writing skills, and enough attitude to do it—I just needed to release my inner dogma. Besides, other dev managers had regular jobs and would be unable to commit to a monthly opinion piece. Bill and I came up with the idea of using a pseudonym, and I. M. Wright’s “Hard Code” column was born.
Since June of 2001, I have written 91 “Hard Code” opinion columns under the name “I. M. Wright, Microsoft development manager at large” for Microsoft developers and their managers. The tagline for the columns is “Brutally honest, no pulled punches.” They are read by thousands of Microsoft engineers and managers each month.
The 91 opinion columns that make up this book were originally written for Microsoft software developers and their managers, though they were drawn from my 32 years of experience in the software industry with six different companies. The editors and I have clarified language and defined terms that are particular to Microsoft to make the writing accessible to all software engineers and engineering managers. The opinions I express in these columns are my own and do not represent those of any of my current or previous employers, including Microsoft. The same is true of my asides and commentary on the columns and this introduction.
I’ve grouped the columns by topic into 10 chapters. The first six chapters dissect the software development process, the next three target people issues, and the last chapter critiques how the software business is run. Tools, techniques, and tips for improvement are spread throughout the book, and a glossary and index appear at the end of the book for your reference. Within each chapter, the columns are ordered by the date they were published internally at Microsoft. The chapters start with a short introduction from me, as me, followed by the columns as originally written by my alter ego, I. M. Wright. Throughout the columns, I’ve inserted “Eric Asides” to explain Microsoft terms, provide updates, or convey additional context.
The editors and I have kept the columns intact, correcting only grammar and internal references. I did change the title of one column to “The toughest job—Poor performers” because people misinterpreted the previous title, “You’re fired.”
Each column starts with a rant, followed by a root-cause analysis of the problem, and ending with suggested improvements. I love word play, alliteration, and pop culture references, so the columns are full of them. In particular, most of the column titles and subheadings are either direct references or takeoffs on lyrics, movie quotes, and famous sayings. Yes, I humor myself, but it’s part of the fun and outright catharsis of writing these columns. Enjoy!