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”.

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”.

With all due respect, you probably know more about software than plumbing, maybe leading you to simplify a bit. Because the same logic could be applied to plumbing, but any plumber might see more variables, the way you do with software.

That is another distinction. All the example jobs do routine, repeatable things. Everything a programmer does is either novel or trivially replicable. There is no equivalent to "painting a room of certain size", to do that you use a copy of already existing painted room.

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.

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.

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-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.

You are conflating very different issues. So yes, it does come across as a rant.

My perspective, as someone who worked for JPMorgan in technology for 8 years, and for several other banks, is that JPMorgan is way above most other banks in the quality of their systems and their dev teams.

Likewise the top management. Jamie Dimon is very impressive. You don't get to stay CEO of a bank with 250,000 employees for more than 20 years without being seriously good at it, very consistently.

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.

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. :)

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.

That isn't productivity, productivity is value/duration.

You're absolutely right, but in "Agile" teams this is exactly how they measure productivity: story points (cost)/sprint (duration)

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.

Define value. Now that's a rabbit hole. Marxist definition? Ricardian?