Back in the 1990s, I was teaching a class at IBM’s wildly successful Cottle Labs in San Jose, CA. It was mid-week, halfway through the class, which had been going really well up to that point, when the students coming back from lunch looked like a train had hit them. Moments before they had just received an email from their manager: they had all been fired.
They were told to finish the class for the rest of the week and then on Friday afternoon to collect their belongings, and find a new position within the company because their project was canceled. Canceled projects were and still are pretty common. According to the Standish Group, 31% of projects were canceled in 1994 and by 2012 that figure shrank to 18%.
All failure is tragic but this was particularly so because it was avoidable. The developers had warned management of the impending collapse but management ignored their warnings. If only their managers understood the situation the way the developers did. But they didn’t.
Over the years I’ve seen something similar play out over and over. The developers have one perspective and management has another. Both groups are caring, responsible people, who want the best for their company, so why don’t they see eye to eye? The way we build software is so alien to people who don’t do it that managers often have a hard time trying to fathom the issues developers face. After that incident, I promised myself I’d try to help the people who manage software developers understand what they’re managing.
But I failed.
For nearly twenty years after that I focused on helping developers deepen their understanding of the virtual domain and I left the non-developers in the dust. I did this partly because I enjoy working with other developers and partly because I needed to deeply understand the nature of software myself.
All that changed for me about two years ago when I started writing my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I wanted to explain the reasoning behind the technical practices of software development so simply that anyone, including non-developers, could understand. At the same time, I realized that many developers, even highly experienced ones, didn’t have a firm grasp of the reasoning behind many of the technical practices, which caused them to not get as much value from them as they should.
As Einstein once said, “If you can’t explain it simply, you don’t understand it well enough.” Software is really not all that difficult, it’s just different. All of the technical practices boil down to common sense. When we can see that “simplicity at the heart of complexity” it gives us insights. These are the kind of insights I share in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.
I started out writing a book for managers to explain why the technical practices of software development are important and found that the content was valuable to many developers as well. I wrote this book to help developers and non-developers get on the same page with the most valuable yet least well-understood technical practices in software development. As far as I know, this is the first book of its kind.
It turns out that only geeks like to read technical manuals. When most executives think about curling up with a good book, Clean Code or Refactoring are probably not the titles that come to mind. People like stories that engage them so I wrote my book drawing heavily on narrative non-fiction. I tell stories, use metaphors, and draw on a wide range of information from a diverse range of areas that I then relate back to software. I wrote it to be interesting and engaging. You can find out more at http://BeyondLegacyCode.com.
Previous Post: « Ideal Days Aren’t Ideal
Next Post: What Mr. Robot Says About Bugs »