The value of code

Sooner or later, every software engineering organization is faced with the task of trying to evaluate the productivity of their team and the performance of its members. And invariably, the conversation turns into a discussion about whether, or how much, to measure code output as an individual productivity metric. In the best case, this metric could be one dimension, of hopefully several, used to evaluate some classes of engineers — certainly more junior ones. In the worst case, it sets a perverse incentive that tracks negative value to the business. I like to use this analogy: the objective of any state Department of Transportation is to provide a system that allows goods and people to efficiently move from one place to another. Highways cost money to build and maintain, so ideally these goals can be achieved with as few miles of highway as possible. Incentivizing more roadways independently of needs would be a waste of taxpayer funds. Ultimately good software meets its requirements at the lowest overall cost, which usually correlates to the least amount of implementation code necessary. More code means more development, more code review, more human coordination, and more defects. <a href="https://betterprogramming.pub/the-value-of-code-ca2dd223fe63">Website</a>