DaedTech

Stories about Software

By

How My New Pluralsight Course Can Help You

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?”

FriendlyBoss

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.

  Subscribe  
newest oldest most voted
Notify of
Matt
Guest

Love it, Eric. Spot on – can’t wait to check it out!

Erik Dietrich
Guest

Glad to hear it, and thanks for checking it out!

Minnesota Steve
Guest

This is excellent. Unfortunately most places I have ended up with, we’re still arguing about most basic things. Justifying automated builds, or even unit testing. And it’s not justifying to business, but rather fellow developers. It’s really remarkable, unfortunately.

Erik Dietrich
Guest

Definitely a scenario I’ve seen, and one where “good for the business” still tends to make an effective trump card (at least among those who care). It’s hard to counter “good for the business” with “I don’t feel like learning new things.” 🙂

Philip C. Presley
Guest

Can’t wait to get started on this course.

Erik Dietrich
Guest

Excellent — hope you enjoy!

John Pazniokas
Guest

Perfect timing, for those of us with a “Career” subheading in our New Year’s resolutions… looking forward to it.

Erik Dietrich
Guest

Definitely has some tips and tricks I’ve picked up along the way that have helped me move my own career along, so here’s hoping it helps you too.

Timothy Boyce
Guest

I agree with this, in theory. The problem I always have is coming up with the “hard” numbers. And then management often wants to track the results as well. How do I compare something I did do, to the alternative that I didn’t do? That kind of fuzzy math hurts my head. Maybe the course has some answers.. guess I will have to watch it.

Erik Dietrich
Guest
I should probably add a draft to expand more on this, but briefly, I took ideas for how to approach some of these discussions from Freakonomics. In essence, you’re not going to be able to do two identical projects using identical people following two different approaches, so you need to come up with reasonable proxies for measuring and document your assumptions. You can compare defects tied to 2 areas of the code base developed in different styles, normailze for usage, and then make the case that area A has roughly 50% fewer defects than area B. Things like that. Another… Read more »
Tim Barcz
Guest

Eric, this is a really good post. Thank you for sharing it and the Pluralsifht course (on my Watch list). I have a similar talk “The Business of Software” which aims to address many of the same issues and specifically why your CEO/VP/Exec may understand technology better than you do (save money or make money).

I’m curious What your thoughts are on the current movement of “No Estimates” around software?

Erik Dietrich
Guest
I like the premise! Do you have a link to your slide deck or anything like that? I actually just started reading this post: http://neilkillick.com/2013/01/31/noestimates-part-1-doing-scrum-without-estimates/ in the last week (bookmarked, need to finish). I only understand the “No Estimates” movement in the vaguest terms, and I want to make sure that I actually understand what people are proposing before I comment on it. I tend to agree with the premise “we’re really, really bad at estimating man hours, so we should figure out a better way,” but I don’t want to put words in anyone’s mouth. I have stubbed out… Read more »
Tim Barcz
Guest

Erik….here’s an upcoming talk at That Conference if you’re in the area: https://www.thatconference.com/sessions/session/6976

Erik Dietrich
Guest

I think I’m going to try to make it this year. Wisconsin Dells is like a 3 hour drive for me, so that removes most excuses beyond going non-billable for a few days. Looks like a cool talk, and I’ll definitely come if I’m at the conference (bummer that it’s at the same time as Cory House and Brian Lagunas, whose talks I also like).

Tim Barcz
Guest

Also – there has to be at some level an amount of trust such that every developer is not questioning their boss, marketing or even their peer. There seems to be a huge amount of inefficiency if everyone has to know everything (or get *their* questions about the business answered)

Erik Dietrich
Guest
Agreed, and that’s something I’ve thought about frequently over the course of time, particularly lately as I’ve been helping teams move toward self-organization. In the industry, developers are so used to having orders dictated at them that they don’t think to ask questions they should ask. But it’s not a trivial problem to avoid swinging too far in the other direction and re-hashing/re-inventing everything every time there’s a new team member. Off the top, I think that having mildly uncomfortable goals that make the team reach and grow is a big help with this. If the team is focused on… Read more »