661707cvr.inddWe’re thrilled to announce that the second edition of I. M. Wright’s “Hard Code”: A Decade of Hard-Won Lessons from Microsoft, by Eric Brechner, has been sent to the printer and will be available for purchase next month. (Print ISBN 9780735661707; Page Count 448).

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.

 

Contents at a Glance


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

 

Introduction

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.

 

How This Book Happened


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.

Who Should Read This Book


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.

 

Organization of This Book


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!