4 ms·

Of the metrics listed, the only one I will say never to use is lines of code. As a very wise manager told me, "Code is a liability. Functionality and business v

Of the metrics listed, the only one I will say never to use is lines of code. As a very wise manager told me, "Code is a liability. Functionality and business value are assets." Measuring developer productivity by looking at how many lines of code they've written is like measuring the health of a business by how much money it's spending. If you can delete code and retain the same level of functionality (for example, because you found a library that will automate much of the task), then that's a huge win. Every piece of code that the team writes is one more thing that has to be unit tested, integration tested, documented, and maintained in the face of future changes. If they can offload that work to a library, or find a way to accomplish the same task by using existing code or by reconfiguring the application, that's almost always preferable to writing new code to accomplish a particular business need. Of course, one can go too far in the other direction. It's easy to fetishize using external libraries for everything (like we see so often in the JS ecosystem). But that's where I would argue that the analogy of treating code like money shines. Sometimes it is worth spending money to have something custom made for your business, rather than buying an off-the-shelf component. Similarly, sometimes it is worth writing code to do something custom, rather than integrating a third party library, or reconfiguring an existing application. But that choice should be consciously made. Rewarding developers for lines of code written moves that choice out of the realm of conscious decision-making and into the realm of reflex. They get paid for more lines of code, so they're always going to reach for the solution that results in more lines of code, regardless of whether that code is necessary or appropriate.

jeanlaf 8y ago
Completely agree! Love the quote "Code is a liability. Functionality and business value are assets."
- scarejunba 8y ago
  The Goal has a bunch of insights translatable to software engineering. This is one of them.
  - dwd 8y ago
    Very much so, and an easy read. Unfortunately so much development is "build it and they will come" rather than analysing and improving a system or solving a specific issue - which may or may not involve coding.
- C1sc0cat 8y ago
  Well some times a lot of effort is expended on "functionality" when its not a good use of time. I worked at one company where a level 2 Engineer was bucking for promotion and spent almost a year (wall time) and ten plus man years redeveloping a system in Oracle that was functionality but added no real value.
  - quanticle 8y ago
    That reinforces my point. This developer didn't add any functionality. Functionality implies value. It implies that the software is functional towards a business goal. So, in my view, this developer added a bunch of code without generating any new functionality, increasing your liabilities while leaving your assets the same. And yes, I've seen this same behavior as well, at other large firms. The best way to get a promotion is often to launch something, so people launch, and don't worry about whether the thing they've launched adds any new functionality, or is yet another reimplementation of an existing framework that will make some junior developer miserable.
TheCoelacanth 8y ago
It is reasonable to use as an indicator of scenarios where you should pay closer attention. If someone produces an unusually high amount of code, that might indicate that they are producing a lot of functionality, but it might also indicate that they are churning out mounds of crappy boilerplate that should be abstracted better. If someone is producing an unusually small amount of code, that might indicate that they are very unproductive, but it might also indicate that they are very efficient and are finding simpler ways to express functionality. All of these things are things that you want to be aware of. The mistake is treating metrics like this as something that is correlated directly with performance instead of just tools to help you understand the bigger picture.
eksemplar 8y ago
I agree that lines of code is a terrible measurement of productivity. I don’t agree that short is always better. Sometimes it’s better to write the code so that it’s easier to understand than to use smart tricks to make it short, because the next person looking at the code might not be on to your tricks. You can argue both ways on this of course, but I prefer clean and easily understandable because I’ve seen what happens when you don’t do that and a junior programmer has to fix something 15 years later. I also disagree that libraries are better. You seem wary of JS, and that’s good, but no libraries are magical and none of them can be trusted to do something for you, unless you look under the hood. Especially not open source libraries. If you don’t know what is going on inside the libraries you use, then you’re heading for a world of pain. Of course some libraries are better than others, but using them blindly is wrong. And if you have to read up on them, then they aren’t really quick fixes. We had a developer who used a library to handle decimals. We have our own library for this, that we’ve build because almost none of the open source libraries for decimals are very good at handling memory allocation and floats and computers aren’t 0.00000000000 they are 0.00000001436 etc. But our developer didn’t know we had our own library for this, so he used a public one. One that uses around 10 other libraries, one of which didn’t handle memory allocation the way you’d want. So suddenly our decimals were wrong, but the computer didn’t know they were wrong, because technically the library worked it just wasn’t specific enough. And it cost us a lot of money to clean things up afterwards. This is the extreme example, but it’s never been more relevant than it is today. Especially not in a world where less and less programmers seem to actually know how computers or even compilers work.
- jgtrosh 8y ago
  I assume that's “especially not-open-source libraries” and not “especially not open-source libraries”
  - eksemplar 8y ago
    No, I meant to say that open source libraries are especially dangerous. I get why you may object, but open source libraries have failed us a lot and by contract the .net framework library hasn't. There are a lot of great open source libraries, that are both well documented and maintained, but there are a lot more that aren't.
rejschaap 8y ago
> As a very wise manager told me, "Code is a liability. Functionality and business value are assets." I'm not sure he is drawing the line in the right place. Business value requires functionality which requires code. Business value would be an asset for obvious reasons. Functionality and code would be liabilities. Functionality and code that doesn't provide business value is waste. You want to minimize both functionality and code. Maybe it is just the analogy breaking down though.
- quanticle 8y ago
  Business value requires functionality which requires code. I don't think business value necessarily requires functionality. Business value is generated by code operating inside a specific business process. Only part of that process is software; the rest of it exists in the minds and the actions of the people interacting with the software. In some cases, it's easier to change the business process than it is to change the software.
ignoramous 8y ago
> As a very wise manager told me, "Code is a liability. Functionality and business value are assets. Obligatory: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

jeanlaf 8y ago

Completely agree! Love the quote "Code is a liability. Functionality and business value are assets."

scarejunba 8y ago
The Goal has a bunch of insights translatable to software engineering. This is one of them.
- dwd 8y ago
  Very much so, and an easy read. Unfortunately so much development is "build it and they will come" rather than analysing and improving a system or solving a specific issue - which may or may not involve coding.
C1sc0cat 8y ago
Well some times a lot of effort is expended on "functionality" when its not a good use of time. I worked at one company where a level 2 Engineer was bucking for promotion and spent almost a year (wall time) and ten plus man years redeveloping a system in Oracle that was functionality but added no real value.
- quanticle 8y ago
  That reinforces my point. This developer didn't add any functionality. Functionality implies value. It implies that the software is functional towards a business goal. So, in my view, this developer added a bunch of code without generating any new functionality, increasing your liabilities while leaving your assets the same. And yes, I've seen this same behavior as well, at other large firms. The best way to get a promotion is often to launch something, so people launch, and don't worry about whether the thing they've launched adds any new functionality, or is yet another reimplementation of an existing framework that will make some junior developer miserable.

TheCoelacanth 8y ago

It is reasonable to use as an indicator of scenarios where you should pay closer attention. If someone produces an unusually high amount of code, that might indicate that they are producing a lot of functionality, but it might also indicate that they are churning out mounds of crappy boilerplate that should be abstracted better. If someone is producing an unusually small amount of code, that might indicate that they are very unproductive, but it might also indicate that they are very efficient and are finding simpler ways to express functionality. All of these things are things that you want to be aware of. The mistake is treating metrics like this as something that is correlated directly with performance instead of just tools to help you understand the bigger picture.

eksemplar 8y ago

I agree that lines of code is a terrible measurement of productivity. I don’t agree that short is always better. Sometimes it’s better to write the code so that it’s easier to understand than to use smart tricks to make it short, because the next person looking at the code might not be on to your tricks. You can argue both ways on this of course, but I prefer clean and easily understandable because I’ve seen what happens when you don’t do that and a junior programmer has to fix something 15 years later. I also disagree that libraries are better. You seem wary of JS, and that’s good, but no libraries are magical and none of them can be trusted to do something for you, unless you look under the hood. Especially not open source libraries. If you don’t know what is going on inside the libraries you use, then you’re heading for a world of pain. Of course some libraries are better than others, but using them blindly is wrong. And if you have to read up on them, then they aren’t really quick fixes. We had a developer who used a library to handle decimals. We have our own library for this, that we’ve build because almost none of the open source libraries for decimals are very good at handling memory allocation and floats and computers aren’t 0.00000000000 they are 0.00000001436 etc. But our developer didn’t know we had our own library for this, so he used a public one. One that uses around 10 other libraries, one of which didn’t handle memory allocation the way you’d want. So suddenly our decimals were wrong, but the computer didn’t know they were wrong, because technically the library worked it just wasn’t specific enough. And it cost us a lot of money to clean things up afterwards. This is the extreme example, but it’s never been more relevant than it is today. Especially not in a world where less and less programmers seem to actually know how computers or even compilers work.

jgtrosh 8y ago
I assume that's “especially not-open-source libraries” and not “especially not open-source libraries”
- eksemplar 8y ago
  No, I meant to say that open source libraries are especially dangerous. I get why you may object, but open source libraries have failed us a lot and by contract the .net framework library hasn't. There are a lot of great open source libraries, that are both well documented and maintained, but there are a lot more that aren't.

rejschaap 8y ago

> As a very wise manager told me, "Code is a liability. Functionality and business value are assets." I'm not sure he is drawing the line in the right place. Business value requires functionality which requires code. Business value would be an asset for obvious reasons. Functionality and code would be liabilities. Functionality and code that doesn't provide business value is waste. You want to minimize both functionality and code. Maybe it is just the analogy breaking down though.

quanticle 8y ago
Business value requires functionality which requires code. I don't think business value necessarily requires functionality. Business value is generated by code operating inside a specific business process. Only part of that process is software; the rest of it exists in the minds and the actions of the people interacting with the software. In some cases, it's easier to change the business process than it is to change the software.

ignoramous 8y ago

> As a very wise manager told me, "Code is a liability. Functionality and business value are assets. Obligatory: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...