6 ms·

> You can, for example, absolutely measure to the dollar the productivity of a plumber and you can easily compare two different plumbers I'm curious about this

> You can, for example, absolutely measure to the dollar the productivity of a plumber and you can easily compare two different plumbers I'm curious about this idea. What if plumber A shows up, quickly fixes something using existing, on-site materials, and ends up charging much less (no parts + 'quick' labor), and then the plumbing breaks again in X months. What if plumber B shows up, takes more time and replaces a part of the plumbing, and ends up charging more (part(s) + more labor) but then the plumbing lasts for Y months, where Y >> X? Which plumber is more productive? How does one convert the productivity to dollars?

fyz 6y ago
Productivity in this case is fairly simple to calculate = Cost/Duration. You can factor in the time (presumably that’s paid for so you should have a real number) and cost of materials (On-site use historical or replacement cost) yourself. Your points holds more generally though, especially when there aren’t clear prices paid.
- tonyedgecombe 6y ago
  That isn't productivity, productivity is value/duration.
  - alephu5 6y ago
    You're absolutely right, but in "Agile" teams this is exactly how they measure productivity: story points (cost)/sprint (duration)
    - etripe 6y ago
      And that is exactly why management shouldn't be looking at or comparing burndown charts. It's too tempting to see IT as a cost centre instead of an enabler.
  - zhte415 6y ago
    Define value. Now that's a rabbit hole. Marxist definition? Ricardian?
jimmytucson 6y ago
Doesn’t happen to the same degree as in software. With plumbing or painting, yes there are good jobs and bad jobs, but if the water gets to where it’s going and there’s no moisture, you’re pretty much done. If the paint is on the wall and not on the ceiling or the trim, and you can’t see roller marks, it’s a good job. With software, there seem to be endless layers of nuance between good or bad, finished or unfinished. Also, it should take X hours to paint a room of Y size with this many windows or doors. There are clearly established timelines for a job and any big deviation from that will get you fired (or not hired again by the same builder). There’s no “due to this manager’s lack of experience with agile, a project that should have taken 2 weeks took 4 and a half months, and the test coverage is poor”.
- atmartins 6y ago
  Doesn’t happen to the same degree as in plumbing. With front end or back end, yes there are good jobs and bad jobs, but if the data gets to where it’s going and there’s no bit rot, you’re pretty much done. If the data is in the db and not on the paper forms, and you can’t see it decrypted at rest, it’s a good job. With plumbing, there seem to be endless layers of nuance between good or bad, finished or unfinished. Also, it should take X hours to code a feature of Y size with this many fields or inputs. There are unclearly established timelines for a job and any big deviation from that will get you fired (or not hired again by the same builder). There’s no “due to this plumber’s lack of sobriety with the world, a project that should have taken 2 weeks took 4 and a half months, and the connections on the joints are poor”.
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
- ponker 6y ago
  It doesn't happen as much in plumbing or painting because these fields have not had rapid change in the last few decades, so common practices have stabilized. Plumbing also has standardized code and inspections which pretty much make sure that everyone is doing the same thing the same way. And still there are differences in quality. Look at what two painters will do to a piece of shitty material like an oil-painted unprimed piece of plywood. One will sand it down to the wood and prime, the other will just slap a coat on top, and you'll have flaking in a few months.
HenryBemis 6y ago
Quality is the conformance to requirements. If you (the client) wanted a quick and cheap solution then A is for you. If you wanted a robust and you are willing to pay the premium to get the B, you're in luck! Mega big banks in the USA suffer from tech debt A LOT. The number one reason for operation disruptions is software errors, and with a large difference to reasons 2-3-4. An additional point could be that large USA banks have a higher (imho) ratio of sociopaths in their ranks. Perhaps the sociopaths lost the ability to whip their minions, and the minions started working under normal/human speeds 40h a week instead of 60-70h per week that is the typical expected work while under the influence of a sociopathic boss. Also lets not forget that JP Morgan CEO is THIS guy: https://www.theguardian.com/us-news/video/2019/apr/11/jp-morgan-ceo-cant-explain-how-one-of-his-low-paid-employees-should-budget-her-salary-video https://www.theguardian.com/us-news/video/2019/apr/11/jp-mor... I think that, although imperfect metric, the bottom line will speak of performance. I take it that there are multiple criteria that affect the bottom line, but the management of JPM cannot be trusted, again, sorry for repeating, is not the most decent in the planet. Edit: apologies for the rant-y beat down of the mega-big US banks, but yeah.. not sorry really.
- xorcist 6y ago
  One thing that has stuck with the after many years of working with IT is that the big projects with resources to spare, the few that really gives you time to do the work properly for once, are often the one that ends up with the most tech debt. It is completely contrary to my own feeling that debt is created by external pressure to deliver too fast. I can see why that would create perverse incentives should a project manager make a similar observation. Great art breaks constraints, but there is this symbiotic relationship where art is nothing without constraints. I'm starting to think there are similarities with other creative endeavours too, which I absolutely consider programming to be. Not sure where I wanted to go with this, just reflecting on your rant with one of my own.
  - Schiendelman 6y ago
    What I’ve found over the last 20 years: Tech debt scales with amount of code written, regardless of other factors. If you write the minimum amount to validate the business need, you have minimum debt. :)
klmadfejno 6y ago
Whichever one earns more dollars is more productive in terms of dollars. If you want to do this right, pick a good metric (plumber dollars is fine), then optimize your workforce for that metric. Do not reward them for that metric or it will be gamed. Consider other metrics that are important (e.g. customer satisfaction) and set constraints on the processes that set a standard that must be met. Not objective, not right 100% of the time, but let's not pretend its impossible to improve processes with some sort of goal in mind.

fyz 6y ago

Productivity in this case is fairly simple to calculate = Cost/Duration. You can factor in the time (presumably that’s paid for so you should have a real number) and cost of materials (On-site use historical or replacement cost) yourself. Your points holds more generally though, especially when there aren’t clear prices paid.

tonyedgecombe 6y ago
That isn't productivity, productivity is value/duration.
- alephu5 6y ago
  You're absolutely right, but in "Agile" teams this is exactly how they measure productivity: story points (cost)/sprint (duration)
  - etripe 6y ago
    And that is exactly why management shouldn't be looking at or comparing burndown charts. It's too tempting to see IT as a cost centre instead of an enabler.
- zhte415 6y ago
  Define value. Now that's a rabbit hole. Marxist definition? Ricardian?

jimmytucson 6y ago

Doesn’t happen to the same degree as in software. With plumbing or painting, yes there are good jobs and bad jobs, but if the water gets to where it’s going and there’s no moisture, you’re pretty much done. If the paint is on the wall and not on the ceiling or the trim, and you can’t see roller marks, it’s a good job. With software, there seem to be endless layers of nuance between good or bad, finished or unfinished. Also, it should take X hours to paint a room of Y size with this many windows or doors. There are clearly established timelines for a job and any big deviation from that will get you fired (or not hired again by the same builder). There’s no “due to this manager’s lack of experience with agile, a project that should have taken 2 weeks took 4 and a half months, and the test coverage is poor”.

atmartins 6y ago
Doesn’t happen to the same degree as in plumbing. With front end or back end, yes there are good jobs and bad jobs, but if the data gets to where it’s going and there’s no bit rot, you’re pretty much done. If the data is in the db and not on the paper forms, and you can’t see it decrypted at rest, it’s a good job. With plumbing, there seem to be endless layers of nuance between good or bad, finished or unfinished. Also, it should take X hours to code a feature of Y size with this many fields or inputs. There are unclearly established timelines for a job and any big deviation from that will get you fired (or not hired again by the same builder). There’s no “due to this plumber’s lack of sobriety with the world, a project that should have taken 2 weeks took 4 and a half months, and the connections on the joints are poor”.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
ponker 6y ago
It doesn't happen as much in plumbing or painting because these fields have not had rapid change in the last few decades, so common practices have stabilized. Plumbing also has standardized code and inspections which pretty much make sure that everyone is doing the same thing the same way. And still there are differences in quality. Look at what two painters will do to a piece of shitty material like an oil-painted unprimed piece of plywood. One will sand it down to the wood and prime, the other will just slap a coat on top, and you'll have flaking in a few months.

HenryBemis 6y ago

Quality is the conformance to requirements. If you (the client) wanted a quick and cheap solution then A is for you. If you wanted a robust and you are willing to pay the premium to get the B, you're in luck! Mega big banks in the USA suffer from tech debt A LOT. The number one reason for operation disruptions is software errors, and with a large difference to reasons 2-3-4. An additional point could be that large USA banks have a higher (imho) ratio of sociopaths in their ranks. Perhaps the sociopaths lost the ability to whip their minions, and the minions started working under normal/human speeds 40h a week instead of 60-70h per week that is the typical expected work while under the influence of a sociopathic boss. Also lets not forget that JP Morgan CEO is THIS guy: https://www.theguardian.com/us-news/video/2019/apr/11/jp-morgan-ceo-cant-explain-how-one-of-his-low-paid-employees-should-budget-her-salary-video https://www.theguardian.com/us-news/video/2019/apr/11/jp-mor... I think that, although imperfect metric, the bottom line will speak of performance. I take it that there are multiple criteria that affect the bottom line, but the management of JPM cannot be trusted, again, sorry for repeating, is not the most decent in the planet. Edit: apologies for the rant-y beat down of the mega-big US banks, but yeah.. not sorry really.

xorcist 6y ago
One thing that has stuck with the after many years of working with IT is that the big projects with resources to spare, the few that really gives you time to do the work properly for once, are often the one that ends up with the most tech debt. It is completely contrary to my own feeling that debt is created by external pressure to deliver too fast. I can see why that would create perverse incentives should a project manager make a similar observation. Great art breaks constraints, but there is this symbiotic relationship where art is nothing without constraints. I'm starting to think there are similarities with other creative endeavours too, which I absolutely consider programming to be. Not sure where I wanted to go with this, just reflecting on your rant with one of my own.
- Schiendelman 6y ago
  What I’ve found over the last 20 years: Tech debt scales with amount of code written, regardless of other factors. If you write the minimum amount to validate the business need, you have minimum debt. :)

klmadfejno 6y ago

Whichever one earns more dollars is more productive in terms of dollars. If you want to do this right, pick a good metric (plumber dollars is fine), then optimize your workforce for that metric. Do not reward them for that metric or it will be gamed. Consider other metrics that are important (e.g. customer satisfaction) and set constraints on the processes that set a standard that must be met. Not objective, not right 100% of the time, but let's not pretend its impossible to improve processes with some sort of goal in mind.