in.finitu.de

One of the most important and most difficult aspects of being pragmatic is that it means that you don’t always do your best work. Now that’s not to say that you don’t give the client an excellent product. This seems contradictory at first, so let me elaborate. Consider two popular car manufacturers: Honda and BMW. Clearly Honda’s offerings are going to be more affordable than BMW’s. Honda is known for good prices and good cars to go with them. BMW is known for more upscale and luxury cars and the prices reflect that as well. Now who makes better cars? Well it depends on what you look for. If I want the most for my money, I’ll buy a Honda any day, it’ll get me from point A to point B and do a pretty good job of it. But, if I want a really nice ride, lots of power and that feel of luxury I’ll get a BMW. Sure, it’s not so cheap but it’s a BMW! So then why doesn’t Honda build its cars like BMW? Because, if it did, its prices would shoot up to match BMW’s as well.

Now a programmer has the same dilemma that both BMW and Honda face. He can write the most perfect, efficient code but he’ll spend a lot of time at it. Or he can make wise decisions on where to save time and make the code a bit less streamlined. On the one hand, he’ll have some of the best code out there, but his cost will be sky-high. On the other, he can still write good code (though not quite as amazing), but keep it a bit more affordable.

Most programmers that I run into, myself included want the luxury of being the BMW type programmer. We want a client to come to us saying "money and time are no object, I want the best!" Unfortunately, few are so lucky as to meet this sort of client. We get the client who wants a Honda from us. They want a good product, that does the job, and does it well, but they don’t need all the bells and whistles, they don’t need maximum efficiency or blazing speed. And most of all, they don’t want to pay the premium price.

Now the problem arises when a BMW programmer ends up with a Honda client, as inevitably happens. Far too often the programmer (or designer) forgets that he’s part of a business and decides that he will go on a crusade for quality. “I’ll offer the absolute best product that I can produce, if it’s the last thing I do!” he says. And sooner or later it will be.

BMW cannot produce cars for the same prices that Honda does, and neither can the BMW programmer. The easy option would be to do what BMW does and just charge more. Unfortunately, most programmers have neither the reputation nor the results to convince their prospective clients to pay the premium. Furthermore, even if they did, there are still going to be clients who just want the Honda. So, realizing that they can’t raise their prices, programmers have to take the alternate approach: pay themselves less. This may be in the form of a lower hourly rate, or just working extra, unbilled hours. Overly optimistic programmers will underbid their clients hoping that the project will have no snags. Less scrupulous ones will underbid fully intending to raise the estimate after they’ve gotten the client in the door.

All of these situations are ultimately damaging for the programmer. Underbidding leads to customer distrust, even if it was accidental. At the best you’ve shown that you have a poor grasp on the scope of the project and on your own skills. At the worst you’ve shown yourself to be dishonest and more concerned with money than with the client.

Well then what if you cap your fee and just work extra hours without billing the client? The client need not know, and you still got the job done well. While this may be necessary at times, to make it everyday practice is quite dangerous. I’ve know people who’ve worked like this and they tend to become embittered. They feel undervalued and underpaid. They are. Sooner or later they will start to hate their job and they’ll quit to find a job where they get paid what their work is worth.

The only way to avoid these pitfalls is to be pragmatic. There may be certain things that you as a programmer care about but that the customer could not care less about. Maybe you want to write the most efficient code, but if the customer doesn’t expect to have much traffic, then it probably doesn’t matter if the code is perfectly efficient. And even then, it may be the case that the extra charges they would have to pay in hosting are still less that what it would cost for you to do the additional optimizations. Maybe you added some slick little feature because you thought it was great, but the client could have cared less.

The problem here is not ultimately one of quality, but of kind. Unless I’m very mistaken, I suspect that Honda engineers pride themselves on quality engineering. But that doesn’t mean it has to be expensive! Honda knows what its customers can afford and does everything it can to offer the best car that fits in that price range. And time and time again, Honda’s cars provide some of the best bang for the buck.

As programmers, we need a paradigm shift. We need to stop trying to build a product that the client can’t pay for and that we can’t reasonably offer. That doesn’t mean that we build junk, just that we try to offer the client the best value for what they can afford. They don’t need AJAX? Don’t give it to them! They don’t need amazingly optimized code? Don’t give it to them! They don’t need a perfectly RESTful app? Don’t give it to them! We aren’t part of a charitable organization, we’re part of a business. And if we aren’t realistic with both ourselves and our clients about what we can offer then we’re doing a disservice to both!

None of this means that we have to resign ourselves to writing boring or mundane code. Writing the best code for the money is a challenge and in some ways a more difficult one than writing code without any cost limits. It requires critical thought about the whole development process. What is and isn’t going to matter to the client? What features can the client reasonably expect for the price they’re paying and what should they expect to forgo? These questions need to be asked and need to be answered. Sometimes this may mean that we write code that is not as good as we are capable of, but we can pride ourselves on coming in under budget and producing some of the best work for what the client paid. And in the meantime we can be glad knowing that we’re getting paid what we’re worth and still giving the client the product they’re looking for.