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
- 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.
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?
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...)