I spent a good portion of this fall working on a Pluralsight course. It was originally going to be ready earlier, but it’s a lot harder to get a course recorded in a hotel room than it is in my comfy office at home. Nevertheless, I finished it up some weeks back, and it was just released on New Years Eve, 2014.
Earlier this fall, I wrote a post called “Have a Cigar.” In it, I described how I thought we as developers had essentially opted out of controlling our own destiny by adopting the attitude, “I’m a programmer and I don’t care about that business stuff.” Sometime later, I read this post by Michael O. Church and realized there was a nice tie-in with autonomy as well. Programmers feel they have more “geek cred” by eschewing “business matters,” but they also know that they’ll have autonomy when picking an RDBMS in a way that they won’t when discussing what the tools and software budget should be. It’s a completely understandable sentiment.
But unfortunately, the road to controlling our own career destinies travels through “the business.” If we want to lead existing organizations or found new ones, we can’t operate as if we were in some kind of technical think tank. We need to learn to solve different kinds of problems, and in order to do so, we need to play on the home field of the MBAs, project managers, CPAs, and C-levels. And to do that, we need to be able to communicate effectively in their language about concepts in our field.
It was toward this end that I made this Pluralsight course, entitled, “Making the Business Case for Best Practices.” I wanted to start a conversation and provide some tools to people in our line of work that are looking to help people understand why they’re doing what they’re doing. I wanted to give you a way to say, “We don’t just do practice X because it’s ‘the right thing.’ It also helps us make money.”
One thing I’m asked pretty frequently is “how can I convince my manager/the CTO/the project manager/etc. that we should do TDD/continuous integration/code review/pair programming/etc.?” Usually, they’ll say something like, “I know it’s the right way to do it, but how do I make them see that?” My response is generally something like, “How do you know it’s the right way to do it? Does it help your company make or save money?”
Often people are surprised by this response, especially because I’m such a proponent of many of these practices. But the reason that I’m a proponent of them is because they’ve helped me and companies I’ve worked with to meet their goals with the aid of software. In other words, TDD isn’t the right thing to do because it is a superior approach, but rather it’s the right thing to do if it helps generate revenue or reduce expenses for the company commissioning the software.
It’s important to understand that because it’s important to understand that software is a tool and not an end goal. If you’re a developer or working as a PM/line manager for a software group, it’s easy to view the software as the be-all, end-all. But in reality, you’re writing software to help do something more basic — automate an expensive, error-prone process, help customers communicate, run some kind of hardware that end-users use, etc. And so the only thing that really matters when you’re discussing how to write that software (TDD or not, pair programming or not, etc) is whether the practice will help the software’s stakeholders achieve their goals and/or save money in the process.
Once you’ve come to understand what truly matters when discussing how to approach writing software, you’re in a much better position to make your case to the people that control the purse strings. Imagine that you’re trying to make the case that your group should use static analysis and the crusty old architect with 25 years of seniority is stymying you. His argument is probably something like, “blah, blah, 25 years, blah, blah, tried it before, blah, blah, can’t work, blah, blah, pointless, blah, blah kids these days.” But his argument is likely to carry the day due to his tenure if you argue back with “blah, blah, right thing to do, blah, blah, saw at a conference, blah, blah, Uncle Bob, blah, blah, my grad school text book.”
But now, for a minute, imagine that you’re in the CTO’s office with the architect and he’s just made his tiresome case. Instead of making a similar one, however, you plug in your laptop and start a slideshow where the first slide says, “Static Analysis is going to save you $13,000 per year in your budget.” I bet you he snaps to attention and watches carefully as you lay out your case in the subsequent slides.
I wrote this course to help you do just that — to help you make the case for practices that you want to adopt not because they’re “best” but because they’re profitable. I’ve been using this approach for some time now, and I’ve had a great deal of success convincing the people that needed convincing that my approach was sound. I’m hoping that, with the aid of this course, you’ll have luck doing the same.
I couldn’t be more serious about the need for technical people to reclaim “the business” instead of shying away from it. So I encourage you to take some time, learn the language of business and learn where and how software practices fit in to improving the bottom line. Your career will be better for it, and so will your endeavors.
