The Problem Preventer

Problem Statement

    I’m thinking about putting ‘Problem Preventer‘ on my resume. Many of the folks I’m talking with in interviews and phone screens don’t seem to get this at all.  I get a lot of questions about problems solved, etc.  I have some good stories and the calls usually go well, but when it comes down to compensation and such, things break down because a lot of companies are looking for warm bodies to sit in chairs and put their fingers on the keyboard and ‘software happens‘. They build software products, but what they built isn’t necessarily a product that will be maintainable and sustain its success. It’s usually short term, tactical success at the cost of long term, strategic success.

    Anyone who’s been in a shop like this (i.e. most of them), knows that this is an ultimately losing proposition. If you’re in problem solving mode, you’re not on top of the game. Hiring more developers — even better ones — is not sustainable. It’s a brute forcing through the problem rather than finding efficient alternatives that don’t require as much work.  Eventually the bailing wire, duct tape, and bubble gum will not be enough to sustain everything and the project will collapse.  Heroes will emerge to save the day, but in a pyrrhic sense.  Eventually even the heroes can’t stem the tide and the failure will be that much more catastrophic. I have seen this time, and time again.  Unfortunately, many folks at the highest level of the organization don’t realize that this is happening. They see that the product shipped, and they don’t have any idea that some on the team nearly killed themselves to make it happen.

Value Proposition

    The value that we provide (and if you’re reading this blog or others like it, you’re already heads above the vast majority of folks in the .NET space) goes beyond our ability to write code fast or solve problems quickly.  While important, these are solving skills that are needed to account for failure earlier up stream in the development process. If you’re in a senior dev or team lead role and you have developers looking up to you, you are in a position to deliver amazing value to your employer because you can help stop the bubble gum tactics and start pouring strategic concrete.  28.3495231 grams of prevention is worth 453.59237 grams of cure, as the saying goes (or something like that).

>>    Rather than hiring 453 mediocre solvers (grams of cure) and giving them mediocre pay (or sending it all offshore), why not hire 28 really good preventers (grams of prevention) and pay them well.  It will be much less costly now, and the savings will grow exponentially as time progresses. 

    Now, I’m not suggesting you fire all your solvers. Obviously, you can’t have a team full of preventers because eventually problems do arise for which no prevention was possible and there will be need for heroic cure tactics. The rest of the time, the solvers are still useful and can be grown into preventers with the right leadership and guidance in place. This is especially important to prevent stratification. By blending a lot of problem preventers with a few problem solvers in order to address changing business needs, you can achieve a nice balance and the homogeny necessary to keep up with changing needs.


    I have talked with several companies and recruiters who are having a hard time finding “good, senior folks” in the .NET space. I’ve been pondering why this is and I believe it’s because the vast majority of .NET developers (myself included) grew up and were sustained in a solver mode and mentality.  The “senior” folks out there, for the most part, are just better and more efficient at solving problems. Their business value and, consequently, salary are capped because there’s only so many problems you can solve and only so fast.  The real speed, productivity, and monetary gains come by preventing problems in the first place.  Unfortunately, this is not as easily quantifiable, so people in our position who fancy themselves as preventers, don’t have an accurate way of justifying higher salary and the outrageous demands of changing the company’s development process to allow for “higher bandwidth and more meaningful communication”, “more trust and respect”, “quality first, last, and always”, and other such radical hippie/Communist nonsense.

    I’ll leave you with a question:  How would someone like me quantify the value of problem prevention?  For example, Sam Solver rewrote the inflexible data access strategy in the current application that saved the company $2 million last year (after the $4 million lost over the previous 2 years). This wasn’t a savings, but a recoup of a third of the money that would’ve been lost. Pablo Preventer, on the other hand, would’ve built the system such that it had a flexible data access strategy and a loosely coupled design that not only didn’t cost the company $4 million in the first place, but allowed 2x the features to be added in the next release and allowed the company to respond to a changing market condition that expanded the company’s revenue by $5 million.  Of course these are contrived numbers and it’s hard to calculate opportunity cost and opportunity gain, but I hope you get the point.

About Chad Myers

Chad Myers is the Director of Development for Dovetail Software, in Austin, TX, where he leads a premiere software team building complex enterprise software products. Chad is a .NET software developer specializing in enterprise software designs and architectures. He has over 12 years of software development experience and a proven track record of Agile, test-driven project leadership using both Microsoft and open source tools. He is a community leader who speaks at the Austin .NET User's Group, the ADNUG Code Camp, and participates in various development communities and open source projects.
This entry was posted in .NET, Mangement, Principles. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • It’d be great to get some answers on this. Its hard enough trying to quantify the value of problem prevention when you are already in the door and providing that value – let alone trying to convince a stranger.
    It seems the only easy answer is to limit your search to those few that already share your views on how software should be developed.

  • @Chad – Maybe it’s just me, but I feel we as a community of developers are focused on educating others with a bottom up approach. I think that helps to promote better engineering practices, but that doesn’t help educate businesses to break out of those mind sets that you mentioned. What companies can we look to as an example of doing things right so we have something to compare against? Somehow we have to come up with metrics on the value of making the right decisions versus the wrong ones. Another part is getting the opportunity to talk to the right people so that we can educate them. We have to talk to the decision makers. I don’t think very many recruiters will get it, but I could be wrong.

  • Steve

    Time and money. Many projects I’m on need to be done asap, every tick tock is money lost until the app is done. Shortcuts happen.

  • @Steve:

    Every project I’ve ever been on (well, except a few side projects) needed to be done ASAP, the same as what you said.

    But it’s not OK to just do whatever it takes to get the job done unless it’s a disposable app that is never used after the deadline (i.e. Conference Registration sites, etc).

    Because as soon as the first deadline comes and goes, the developers breath a sigh of relief and the business users come back and say something to the effect of, “Ok! Great, you guys did a great job and did that in 3 months. Now we need 2x the features in 2 months. Since you guys are so awesome, it won’t be a problem!”

    I’ve also had that happen on all but a few projects.

    So when I hear ‘we have to have this NOW NOW NOW’, I try to direct the conversation to, “What does your schedule look like for the next 18 months? What demos, what conferences, what etc, etc, etc, do you have that we should be aware of for planning”

    If you’re just looking to make it through to the next deadline, you’ve already set yourself up for failure.

    Everyone needs to stop looking directly down and look towards the horizon. It’s hard in a panic situation, but that’s what I mean by problem preventer: It’s up to us to look further out and not just at the next deadline.

    We *must* be thinking big picture and strategically and not just hurrying up the next release because we only harm the business users when we do that. All that money you might have saved this release just cost them 10x on the next release. What have we solved then?

  • I think your error is in trying to pitch your (valid) value proposition to employers whose heads aren’t already there; this seems a waste of your time (explaining to them why someone like yourself is worth what you think you are).

    If they cannot see that already (becuase they already have acknowledged the reality of precisely the value proposition you are espousing) then you need to move on to an employer who does.

    “Hey, I know you were looking to hire X but since I’m not X, let me explain to you why you really need Y.”, is an extremely difficult sale in an interview — its hard enough if you are already an existing hire (presumably with the cred already via proven performance) but its nigh-impossible as an unknown in an interview context.

  • I agree that it is a tough sell, but maybe you can do this:

    Right now I can see you are looking for X. I have more to offer and you may not immediately see that value.
    So here is what I propose we do:
    I will come in and work for you at $$ and once you see that I am a problem preventer (or that I have proven myself) we will discuss bumping it up to $$$. We will do that review within a year of hire. After I have been here six months we will put a date on it and review my progress at that point. Fair enough?

  • @Fervent:

    Good idea! I had an idea somewhat similar to that and floated it around to folks, but the general consensus of people I talked with and look up to was that this is a losing proposition and puts you in a bad spot of having to justify everything you do.

    If you’re (all of us) confident that you can do this and even have a proven track record, there’s no reason to compromise or make deals. We should just come in and say what the truth is and how they can save loads of time and money and increase their quality and lower their change pain and it’s going to only cost them the low, low salary or hourly rate of $XYZ.

    The compromise proposition will be seen as a weakness and lack of confidence in the business folks’ eyes (and rightfully so).

    I think Steve is right. We need to just get the word out, try to establish the facts and proof of what we claim and then only deal with people who are seeking a better way rather than trying to force people who are stuck in their current process

  • True. Compromise is a tough battle I had, in a similar sense, with an employer once. Part of it is also making yourself somewhat indispensable, but in a good way, not in a crappy code writing way.

    I think Steve is right as well, but it may be a long time before there are enough people who need to make money at the end of the day see the benefits (opportunity costs missed) by seeking a better way.

    When dealing with business people, it always needs to be quantified in dollars. So we need to present it to them in this way: Here is what I am asking, here is what I am going to save you at the end of the day.

    A little OT but a lot of good salary negotiation sites say to hold off on salary discussion until you have your potential employer at a point where they feel they need to hire you.

    I have used this tutorial among others for both my wife and I and it has been fantastic and has worked well:

  • Good post, Chad.

    All the best practices and ALT.NET goodness is really a waste of time if you can’t convince the decision makers of its value.