| This book might make Microsoft sound bad.
At least that's one of the concerns I had about telling so many Microsoft war stories. I considered softening and smoothing over some of the stories, or leaving them out altogether, but apart from changing people's names, I decided to keep this book and its examples grounded in reality so that it would be as useful and practical as possible. Besides, I think people realize that Microsoft wouldn't have reached its position of prominence in the software industry if the company were full of bozos. It isn't.
Most of the incidents I describe come from my experiences in retraining Microsoft teams whose projects were already in some sort of trouble: the projects were long overdue, or the quality of the code was not up to the company's standards, or the programmers were working crazy hours and still not making any headway...
While working with these teams, I discovered that they were all making the same fundamental errors and that they were perpetually repeating those errors. Not only that, once I'd gotten attuned to the mistakes those teams were making, I saw that even teams on successful projects were making those same fundamental errors—they just made the mistakes less often or had instituted countermeasures to overcome the effects of those mistakes.
Inspiring leaders look at the world in a funny way. The company building could be burning to the ground, and instead of panicking about the lost jobs, the inspiring leader takes one look at the flames and breaks out the hot dogs and marshmallows. When everybody around them is pessimistic, such leaders inspire confidence even though there may be every reason to be pessimistic. They're an optimistic bunch, tending to interpret events in a positive light. With that perspective, inspiring leaders tend to view failures not as failures but merely as learning experiences that will help them surmount the next obstacles that come along. And because inspiring leaders tend not to experience a sense of failure, they're willing to try the outlandish ideas that can lead to major breakthroughs. If an outlandish idea flops, the inspiring leader doesn't see the episode as a failure but merely as more information. Such leadership has little to do with experience. It's a combination of strong desire, an unusual way of looking at the world and its opportunities, and such a clear vision and the ability to communicate that vision that others are inspired to work with the leader to make that vision come true.
In Debugging the Development Process, I focus on the techniques and strategies that programmers can use to get quality products out the door with a minimum of wasted effort. In the first three chapters, I talk about a number of basic concepts and strategies that a team should act on if they want to release products without working twelve hours a day, seven days a week. The final five chapters build on the earlier chapters, focusing singly on overblown corporate processes, the ins and outs of scheduling, programmer training, attitudes, and long hours.
Writing Solid Code and Debugging the Development Process are companion books. You'll find that the ideas in the two books interact with one another to a certain extent. When ideas in the two books overlap, you'll find that Writing Solid Code tends to be more focused on the code itself. In one instance I excerpt part of a section from Writing Solid Code in this book because I think that the point it makes is even more critical to the smooth running of a project than it is to writing bug-free code. |
