On Shepherd.com:
- My list of The best books for practical advice on software development.
- My three favorite books I read in 2023.
My books:
Get the brutal truth about coding, testing, and project management—from a Microsoft insider who tells it like it is. I. M. Wright’s deliberately provocative column “Hard Code” has been sparking debate amongst thousands of engineers at Microsoft for years. And now (despite our better instincts), we’re making his opinions available to everyone.
In this collection of over 80 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
- Drive your own successful, satisfying career
- Don’t be a dictator—develop and manage a thriving team!
Companion Web site includes:
- Agile process documents
- Checklists, templates, and other resources
Introduction (from the second edition):
For Bill Bowlus, who said, “Why don’t you write it?”
For my wife, who said, “Sure, I’ll edit 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.
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.
The first 16 columns were published in the Interface internal webzine, with many of the topics assigned to me by the editorial staff, Mark Ashley and Liza White. Doctored photos of the author were created by me and Todd Timmcke, an Interface artist. When the webzine came to an end, I took a break but missed writing.
I started publishing the columns again 14 months later on internal sites with the help of my group’s editing staff: Amy Hamilton (Blair), Dia Reeves, Linda Caputo, Shannon Evans, and Marc Wilson. Last November, I moved all the columns to an internal SharePoint blog.
In the spring of 2007, I was planning to take a sabbatical awarded to me some years before. My manager then, Cedric Coco, gave me permission to work on publishing the “Hard Code” columns as a book during my time off, and Ben Ryan from MS Press got it accepted. The first edition of this book was published later that year.
In addition to the people I’ve already mentioned, for the first edition I’d like to thank the other members of the Interface staff (Susan Fairo, Bruce Fenske, Ann Hoegemeier, John Spilker, and John Swenson), the other people who helped get this book published (Suzanne Sowinska, Alex Blanton, Scott Berkun, Devon Musgrave, and Valerie Woolley), my management chain for supporting the effort (Cedric Coco, Scott Charney, and Jon DeVaan), my current and former team members for reviewing all the columns and suggesting many of the topics (William Adams, Alan Auerbach, Adam Barr, Eric Bush, Scott Cheney, Jennifer Hamilton, Corey Ladas, David Norris, Bernie Thompson, James Waletzky, Don Willits, and Mitch Wyle), and Mike Zintel for being so kind in writing the foreword.
For the second edition, I’d like to highlight the crew of reviewers and long-time readers who keep me from shoving my foot too deeply down my throat each month (Adam Barr, Bill Hanlon, Bulent Elmaci, Clemens Szyperski, Curt Carpenter, David Anson, David Berg, David Norris, Eric Bush, Irada Sadykhova, James Waletzky, J.D. Meier, Jan Nelson, Jennifer Hamilton, Josh Lindquist, Kent Sullivan, Matt Ruhlen, Michael Hunter, Mitchell Wyle, Philip Su, Rahim Sidi, Robert Deupree (Jr.), William Adams, and William Lees); James Waletzky, who wrote two columns for my readers while I was on sabbatical; Adam Barr and Robert Deupree (Jr.), who cajoled me into recording a podcast for my column and helped produce it; Devon Musgrave and Valerie Woolley, who got the second edition published; my managers (Peter Loforte and Curt Steeb) for supporting my efforts; Mitch Lacey for writing the second edition’s foreword; and my wife, Karen, who stepped up to edit my columns when I left my editing staff to join Xbox.com.
Finally, I’d like to thank my transcendent high school English teacher (Alan Shapiro) and my readers who are so generous with their feedback. And most of all, my wife, Karen, and my sons, Alex and Peter, for making everything I do possible.
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” 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!
Agile Project Management with Kanban (Developer Best Practices) 1st Edition
Use Kanban to maximize efficiency, predictability, quality, and value
With Kanban, every minute you spend on a software project can add value for customers. One book can help you achieve this goal: Agile Project Management with Kanban.
Author Eric Brechner pioneered Kanban within the Xbox engineering team at Microsoft. Now he shows you exactly how to make it work for your team.
Think of this book as “Kanban in a box”: open it, read the quickstart guide, and you’re up and running fast. As you gain experience, Brechner reveals powerful techniques for right-sizing teams, estimating, meeting deadlines, deploying components and services, adapting or evolving from Scrum or traditional Waterfall, and more.
For every step of your journey, you’ll find pragmatic advice, useful checklists, and actionable lessons. This truly is “Kanban in a box”: all you need to deliver breakthrough value and quality.
Use Kanban techniques to:
- Start delivering continuous value with your current team and project
- Master five quick steps for completing work backlogs
- Plan and staff new projects more effectively
- Minimize work in progress and quickly adjust to change
- Eliminate artificial meetings and prolonged stabilization
- Improve and enhance customer engagement
- Visualize workflow and fix revealed bottlenecks
- Drive quality upstream
- Integrate Kanban into large projects
- Optimize sustained engineering (contributed by James Waletzky)
- Expand Kanban beyond software development