It's a conversation a lot of us have had with our managers, our fellow developers, etc. And it occurs to me that the response is often the same. It comes across differently, but the message is clear. Writing quality software in "the real world" is "too hard." Sure, it's nice for open source projects or academia or anywhere else that money doesn't matter, but in a real business where costs are important it's just not worth all the extra effort vs. just doing some good old rapid application development and whipping up some application to get the job done.
I find that this point of view is based on two core assumptions:
- Bad software costs less than good software.
- Good software is more difficult to write than bad software.
Can anybody in any position of management over a software development team truly claim with a straight face that supporting bad software is in any way cheap? That it can just be written off as a justified cost and pushed aside and forgotten? Teams of highly-paid developers spend a significant portion of their time troubleshooting legacy software that was rapidly whipped up to just get the job done. We as an industry have enough of this old software laying around that we know full well at this point how difficult and, at the bottom line, expensive it is to support.
Now, what's done is done. I understand that. This software has already been written and invested in and it's "business critical" so we need to support it. But it's not like we're done. We're still writing software. We're still creating new features and new applications and new projects. So why is "the way we've always done things" still the status quo? You know how much it's going to cost in the long run, that math has already been done. Hasn't it?
You're either going to pay for it now or pay for it later. Either way, it's going to cost you. But there's a critical difference between "now" and "later" in this case. "Now" is brief. It's measurable. You know when it's over. "Later," on the other hand, is open-ended. You don't know how long "later" is going to last. You don't know how much it's going to cost, other than potentially a lot. Let's express this with a little math...
- 100 * 3 = 300
- 50 * n = 50n
Now the latter assumption is something towards which I can be more sympathetic, mostly because the people who make that assumption don't know any better. If you haven't written both bad software and good software over the years and really grasped an understanding of the two, then I can't really expect you to truly understand the difference. Whether you're a manager who just isn't really into the technical details or an inexperienced developer who hasn't really learned yet, the assumption is the same.
But the thing you need to understand about this assumption is that it's just patently untrue. Writing good software doesn't cost a lot more than writing bad software. It doesn't even cost a little more. Maybe this assumption is based on the generality that in most industries good costs more then bad. Yes, this is true. But it's true for a different reason than you think.
Manufacturing quality goods costs more than manufacturing cheap goods because the manufacturing is mechanical and commoditized. It's an industry of tools, not of people, and better tools cost more. But software isn't manufacturing. It isn't plugging together a series of pre-defined widgets on an assembly line. (Microsoft would have you drinking their Kool-Aid and believing that it's all about the tools, but that's because they happen to sell the tools. But we'll cover that another time.) It's a craft, and it's performed by craftsmen, not assembly line workers.
Does good art cost more than bad art? Sure, the classic good art costs a fortune. But that's because it's rare and can't be truly reproduced. Software doesn't really have that problem. But art being created right now has nothing to do with the financing of the work. Good or bad is a measure of the craftsman, not of the financial backing.
And a good software craftsman can often be found at roughly the same cost as a bad one. This is because that cost is usually based on how long the craftsman has been doing the craft, not how good he or she happens to be at it. We've all met "senior developers" who are only in that position because they happen to have been writing mediocre software for a long time, or because they're over a certain age, or because they've been with that company for a long time in various capacities such that when they got into the software gig they were considered "senior level."
But ask any craftsman in any industry. Ask a seasoned carpenter or electrician or anybody. Not taking into account the tools, is the actual act of doing something well inherently more difficult or, at the bottom line, more expensive than doing it poorly? No, absolutely not. It seems that way to laymen because the professionals "make it look easy." But the fact is that, for those who know what they're doing, it is easy. It actually takes a professional more effort to do something in an amateur way than to just do it the way they know how to do it. It's not right, it's not natural, it forces them to stop and un-think every once in a while.
Do yourself a favor, do your company a favor, do your bottom line a favor and actually care about the software you manage. Your developers care about it, because craftsman like to produce good things. (If they don't care about it then perhaps you should re-think your team.) Produce better software so that, in the long run, your support efforts can be lower and you can have the time and resources to produce even more good software. Your business end users may not know the difference, they may not know you've done anything at all. They shouldn't have to, their software should just work.