It is hard to believe, but I still hear stories about managers who evaluate programmers by the number of lines of code that they have written. I can relate to the frustrations of (non-technical) managers trying to oversee a bunch of techies, but to stimulate people to create additional costs is just plain stupid. A bit more elaborate technique how to estimate value of code is to track amount of hours that developers spend coding it. The value of the code is then calculated by multiplying the number of coding hours with an average value of a coding hour. The underlying misassumption here is that programmers generate something that has a long term value. I've worked in a company which brought this technique to extreme and managed to increase its book value substantially by diligently bookkeeping every programmer's hour and transforming it into company's capital.
Treating code as an asset is a mistake that seriously distorts company's balance sheet. Code in itself has no value and (usually) cannot be sold to any other company. The code generates value only by supporting business processes which are the real generator of value in a company. I'm arguing that code should not be treated as an asset but as an operating cost, very similar to how human work is accounted for. If the code would be treated as an operating cost, then I'm sure managers would not encourage developers to write more lines of code, but would encourage them instead to develop only what is really needed to support valuable business processes.
Principle of least coding I would not call myself a software engineering veteran. As you read the piece below, you can think of it as a hodgepodge of ideas that have been in my mind for a while, and an attempt to obtain some clarity in the process of scribbling this. Please feel free to leave your thoughts and comments.
- "Business leaders don't need to know how to code, but having an understanding of what is involved is..." (lifeandcode.tumblr.com)
- The Slow Programmer (rodp.wordpress.com)