Wednesday, July 4, 2007

How to Waste a Lot of Money in Software Development

Here’s my top three list of the top ways to throw away your hard-earned cash through software development:

Change Personnel The most expensive thing a company can do is fire or lay-off someone. Whenever a worker leaves a company, all the unique knowledge sitting in that person’s head leaves with them. This is especially true for those fields in which intellectual capital is bought and sold. Software development is nearly entirely a market for intellectual capital. The physical components of software creation and distribution are rather insignificant as a percentage of total economic cost. Intellectual capital is knowledge: knowledge of how to do something, knowledge of why something is done a certain way, knowledge of who wanted what, knowledge of when is the best time to do something, etc. There are two forms in which this knowledge is contained, one is the mind, the other are physical artifacts, like documents. Corporate America is forever running a futile foot-race to transfer that knowledge from the mind to the document, because they know that the mind can leave without notice. This, quite frankly, is a fool’s errand, because the process of converting knowledge into the printed word and picture is just too inefficient to capture more than a small fraction of the total. The process of trying to transfer that knowledge to another mind is probably just as inefficient, so having an employee train his replacement is also a fool’s errand if there is any significant intellectual capital involved.

The longer a person has been at a job or company, the more of this intellectual capital they’ve accumulated. Some of that intellectual capital is transferable, such as knowledge of how to program in C++, and what can be transferred out can probably be transferred in. However, a good deal of the intellectual capital a worker has built up over time is non-transferable. They can’t use it anywhere else, and nobody that is brought into the company will have it. This is the proprietary domain knowledge, the type of stuff usually referred to by “confidentiality agreements”. It is knowledge of the industry, knowledge of the company’s way of doing a specific thing, knowledge of trade secrets, patents, methods, etc.

There are a lot of fools parading themselves around as “management consultants”, claiming that companies should fire those people that are not the best at what they do. For example, they’ll advise companies to make workers interview for their own jobs and fire those that fail the interview. I once worked at a place that, on the advice of such a “consultant”, had fired their entire billing department after making them interview for their own jobs. The monumental stupidity of this advice is self-evident, but the evidence also showed up in the balance sheet, since the company was unable to send out it’s monthly invoices three months in a row after that. People laugh when they see the “two Bob’s” in the movie Office Space, but I have to tell you, that movie is basically a documentary. It really is like that out in the real world. There a lot of really stupid people giving and taking bad advice.

The cost of firing someone is prohibitive even if a company is too cheap to offer severance pay. As someone trained in Economics I have to laugh every time I hear idiot bean counters crowing about how they plan to “cut costs” by laying off workers. Every time a worker leaves a company, the company loses that worker’s non-transferable knowledge, that worker’s productivity, and they have to pay that worker’s vacation pay up front, and that worker’s unemployment compensation for several months. In addition, they have the added cost later of paying that worker’s replacement a salary during the ramp-up period when the new worker is still acquiring enough intellectual capital to be productive. The idiot bean-counters might as well be saying, “We are going to cut costs by sabotaging productivity!”

Rewrite Your Code If you stop and think about it, you’ll have to admit that code is a lot like a worker, in that it contains within it a lot of embedded knowledge, knowledge of how to do something, knowledge of what to do for customers, knowledge of workarounds for bugs in operating systems, tools, etc, and a lot of proprietary domain knowledge as well. Throwing away code is like firing a bunch of workers. You lose a lot of intellectual capital in the process, there is a guaranteed dead time during a learning or reacquisition curve, and it has a lot of financial cost as well. In a highly competitive field with very narrow profit margins, it can be a death-wish.

There is no cheap and easy way to rewrite software. If you are moving to a new language or framework, you will suffer a heavy hit if you simply port the old code to a new syntax, because code that is written over many years is tuned to the framework or language that embodies it. What is a “best practice” for one language or framework may not even be a good idea in another. Tricks and workarounds necessary in one may be totally inappropriate in another. Furthermore, as the art of software development advances, and languages and frameworks grow and appear to take advantage of these advances, the old way of doing things becomes more and more inappropriate for the new paradigms. Furthermore, developers that know and love the new paradigm are seldom happy and productive dealing with the old. Finally, a rewrite is done inevitably at the cost of some new features. The loss of potential sales due to the absence of these features is a very high economic cost. Firms need to get it out of their head that they are going to somehow escape the high cost of a rewrite and the loss of embedded knowledge by leveraging their existing code base by doing a “port”. The ONLY way to avoid the prohibitively high cost of doing a rewrite is to stick with the original code base in the first place.

This is exactly why one of the most used programming languages on this planet, in terms of the monetary value of the transactions that go through its code, is the “dead” language COBOL. A lot of long-running successful firms have massive code bases in COBOL that have been running for decades. Those firms know that if the software works, there is little need to change or replace it. They can think of a lot more uses for their money than fixing what isn’t broke.

Maniacally Minimize Cost The Beatles may have had a point when they said the best things in life are free, but we all have to admit that cheaper is not always better. If the key to happiness was the lowest cost, we’d all be driving Yugo’s and living in trailers. Likewise, in the world of intellectual capital the cheapest workers are seldom the best deal. In fact, those who are very good at their craft will usually know it, and demand at least a decent salary when deciding where to roost. If you limit your positions to below-average salaries you will usually never come across a decent software developer. Given the wide disparity in productivity between the best and worst software developers, this will cause your economic costs of software production to skyrocket. Instead of paying one very good software developer $90000/yr to produce great software, you’ll be offering ten mediocre software developers $60000/yr to produce crap, for a total cost of $600K/yr. You may think you’re saving $30,000 a year per worker but you aren’t. You’re wasting $510,000 a year. But the reason why this waste occurs so much is that this is the difference between what is seen and what is not seen. When someone hires ten mediocrities at $30K/yr less, they SEE savings of $30K/yr, but what they don’t see is that if they had hired one good software developer at $90K/yr, they would not have to hire ten of them, just one. A lot of wasteful off-shoring is done because of this problem.

No comments: