Why Doesn't Software Show Up in Productivity?

Productivity, especially in relevant areas like administration, stagnated despite computers hitting every desk. I read the Cowen book (Complacent Class) at the same time I was reader Graeber's "Bullshit Jobs." Heterodox writers from both sides of the spectrum. Same observation.

On the face of it, it doesn't make sense. How could, for example, a local college's administration not have become more efficient because of computers?

A factory's productivity, which has legible inputs and outputs is really different to something which doesn't.

Software is management technology, perhaps, but only in cases that management technology is pretty efficient already. Modern warehouses, ports and stuff are more productive because of software. But, they we already pretty efficient. They already had pretty well formalized, legible processes.

That said, software is also a tool. Say your job is to receive applications, payments or such. You process them. File. Respond. Software is undeniably a good tool for such things. We can't abstract that away by looking at the top level trends. It is a productivity tool for administrative tasks. Top line trends don't suggest a productivity gain, but I'm not willing to conclude that software is not an administrative tool.

On the face of it, banks, universities, government departments, the legal sector, accounting, perhaps the whole finance sector are bigger today, not smaller. They have computers now, which are productivity tools. WTF is going on?

Do we have more justice, better records? What is "productivity" anyway, outside of legible productivity like a factory's?

Non-problem: Writing code. This is the easy part. COBOL took typists, gave them a week of courses, which made them successful basic coders. Low code helps the most basic junior but slows down the average coder by forcing everything trough drag and drop.

Problem: Reading code. Most low code platforms I've seen show you only a small part of the code, needing a lot of clicking around in a GUI to make sure you found it all. It either transform it in a mess of arrows and boxes or spread it out so wide you spend more time scrolling than reading. I've found myself reading the XML dumps of our current tool just to spare me some time.

Problem: One size fits all. You can't polish or finetune the standard components. What you see is what you get. This guarantees you both a minimum and a maximum level of quality. Yes, there are escape hatches. No, they won't help you. You will make parts of your program unstable or less user friendly because your low-code vendor didn't foresee all of your needs.

Problem: Versioning. Boxes and arrows don't merge well. There is generally only a small team working on 1 piece of code. You can't scale it past 3-4 people. Also, emergency fixes in prod don't easily propagate back to dev, especially in a high-stress situations. You'll have to do it manually. This almost guarantees regression bugs.

Problem: Searching code. If you have enough code, the day comes where you'll need to find all references to something. I've grepped code bases of >10 000 000 lines. Can't do it in more than the most limited way with low code.

Problem: knowledge exchange. Something like stack exchange works because you can type text. Print screen is the only option available in most low code tools.

As the saying goes, the core of ICT is not programming but Information and Communication. If you want to make programmers obsolete, you need tools that help you organize information and ease communication.

Low code is simply the wrong way to look at the problem. it ends up throwing tons of man-hours at a problem. In the long term, it creates more programmer jobs, not less.

I think the woodworkers dilemma is a thing from the dev perspective. But, that still doesn't deal with the software users' side. Why does a modern company need more people in accounting, HR, even management? Shouldn't the ability to email everyone, digitized forms and such make fewer people necessary to do the same job?

If Mcdonalds invents a new sandwich maker that requires half as many cooks per burger...

I view it from my perspective as a hobbyist. I enjoy being in the shop working -- and I enjoy making stuff like my work bench, my saw tables and dust shields, my French cleat shelves, etc. I don't really expect to save money (if I do the numbers) so much as I expect to get more out of the process (skills, tools, etc.) than what I get buying something off the shelf.

And yes - a professional most likely values their productive time over time spent making jigs, etc. so they will often allocate capital wisely to save time!