The allure of mediocrity

In my previous post, I outlined the costs and benefits of making a commitment to well-crafted code.  I lamented how almost no companies are willing to make that commitment, even though the benefits far outweigh the costs.

Or do they?  I'm trying to put on my corporate hat: "profit above all".  It doesn't fit me very well, but here goes...

The costs of being committed to well-crafted code:

• Commitment to hiring "craftsman-level" developers:  There is a time-cost associated with every candidate searched, evaluated, and interviewed.  Finding someone who is "good enough" takes much less time (money) than finding someone "really good".
• Commitment to keeping skilled developers:  This incurs many costs: above-average benefits and above-average salaries.  Investment in infrastructure to support remote-work. Also, it limits my ability to demand 60-hour weeks / weekends (remember, for my salaried employees, I logically only pay for the first 40 hours per week - any work beyond that is free).  Really good developers are more likely to leave under those conditions, as they are less afraid of looking for a new position elsewhere.
  
• Staying away from "bargain" developers:  There's hundreds of development firms (many of them offshore) who can give me developers at an hourly rate that is about 1/4 of what I would pay a full-time employee.  Even if it takes them twice as long to develop and debug the desired functionality, I'm still paying half the cost of my own locally-based development staff.  Their code can't be THAT bad, right?
• Taking the time to think before you code: You have 10+ years of software development experience - you shouldn't have to research things anymore - you should already know the best way to approach every possible problem in every possible system in every programming language for every possible set of requirements.  Thinking costs time/money, but doesn't provide any measurable benefit to the bottom line.
  
• Refactor code which fulfills the system requirements: if it ain't broke, don't fix it.  You should be spending your time developing new features or fixing the bugs our clients are complaining about.
• You must be open to the possibility of sacrificing some functionality in order to meet a deadline: this is a huge cost!  If FeatureXYZ isn't 100% implemented and bug-free in the next version of the software,we won't be able to sell it at all.  If cutting corners will get FeatureXYZ implemented by the deadline, then do it.  We can deal with the fallout from it in a later release.

Many of those costs are invisible or inconsequential from a developer's perspective, but they all impact the company's profitability to some extent.  Perhaps there were spots where I was a little sarcastic or over-simplistic, however, I think the overall assessment is accurate: every one of those is a real cost, and would probably give me pause if it were my responsibility to keep a company's books in the black.

However, from a pure profitability standpoint, costs aren't inherently evil.  If the costs buy us benefits which result in a net profit, I'll happily pay them.  The benefits of a commitment to well-crafted code:

• Gives the developer a sense of accomplishment and pride: seriously?  Go paint happy little trees on your own time, hippie.
• Well-crafted code is more easily understood by other developers ... New employees can be productive sooner: I like it - improved productivity is a real benefit.  How much sooner?  How much more productive?
  
• Well-crafted code generally has fewer bugs.  Bugs which do occur are quicker to repair: I like this one, too - bugs make for unhappy customers; fixed bugs make for happy customers and increased revenue (I never understood how a 10-year-veteran of software development still writes code with bugs, but I've stopped asking since it seems to offend them for some reason).  So how many fewer bugs?  None?  And how much more quickly can you repair them?
  
• Well-crafted code is easier to extend.  Future enhancements can be made more quickly: I'd like this one better if it meant faster development now.  But nevertheless, it's a good benefit.  How much faster?

You can probably see a trend here: many of the benefits of well-crafted code are realized in the future; contrast that with the costs, which are mostly incurred immediately.  The benefits are difficult to quantify (and in some cases difficult to even describe in layman's terms); contrast that with the costs which are more concrete and easier to quantify. 

So from a pure profitability standpoint, we have very real, immediate costs that provide somewhat foggy, future benefits.  Again, if I were in charge of a company's books, I don't think I'd want to make that tradeoff either.

So where does that leave corporations?  A commitment to consistently well-crafted code doesn't seem profitable, but they're not stupid - they know they need SOME degree of code quality and developer expertise.  I assume they'll do the same thing I do when I'm purchasing something: try to find the best bang-for-the-buck.  I'm not going to buy the most well-crafted, reliable, brand-new car on the market, but I'm also not going to buy the bondo-coated, 200,000-mile jalopy.  Similarly, I suspect corporations are looking for a developer who's skilled enough to write "good enough" code, but is unskilled enough to be content doing so.

So where does that leave me?
(to be continued...)