Live data from Hacker News

The Failed Commodification of Technical Work

ludic.mataroa.blog

11–20 of 210 posts

Re: The Failed Commodification of Technical Work

#11

I think he’s right. The tech industry has been trying to commodify devs for a long time (COBOL, Java). But there’s a sort of essential quality that reasserts itself no matter what you abstract. Despite the seemingly simple requirements paired with high level frameworks, a lot of our software still doesn’t even work well. As the author notes. The only real fix is talented devs that care. You can make a career out of t…

The problem is that beyond the boilerplate we aren't solving commodity problems most of the time. If you've worked in the same field long enough, you'll see that things certainly rhyme, but everyone has slightly different business requirements. At each level of the stack this grows, and so in total there's a ton of non-commodity, bespoke work to do. That's why no two products are exactly alike and we don't just have…

Yep! What the business really needs is something that will do whatever necessary to ensure stuff actually lands. The skills are important for sure, but the responsibility aspect can’t be offloaded to machines well.

And even a lot of our boilerplate removal mechanisms (eg frameworks) are not very good either. They’re just slightly less worse than before.

Re: The Failed Commodification of Technical Work

#12
Reminds me of some of my startup skeleton stories....

A founder so dumb he cannot understand the basics of one app equals one domain...wanted to fill each domain he owned with a part of a major app and then sell each domain and not understanding that would destroy the full app if we could ever break the one app one domain equation in the first place!

Re: The Failed Commodification of Technical Work

#13
About 10 years ago a few friends of mine (mechanical engineers) were surprised that I was studying software development. They said something along the lines of “is there much left to do? we can just use existing systems to do everything we need right?”

The misconception is that building systems to tackle new problems are easy and thus have been “commodified” meaning nobody needs to write code anymore.

The reality is that building software is rarely as easy as configuring a UI. You end up needing text which represents logical rules and flows, you need version control see how the system changes, rollbacks… which means you need programmers

Coding doesn’t disappear, it just moves up the levels of abstractions

Re: The Failed Commodification of Technical Work

#14

Earlier quoted context omitted.

The problem is that beyond the boilerplate we aren't solving commodity problems most of the time. If you've worked in the same field long enough, you'll see that things certainly rhyme, but everyone has slightly different business requirements. At each level of the stack this grows, and so in total there's a ton of non-commodity, bespoke work to do. That's why no two products are exactly alike and we don't just have…

Yep! What the business really needs is something that will do whatever necessary to ensure stuff actually lands. The skills are important for sure, but the responsibility aspect can’t be offloaded to machines well. And even a lot of our boilerplate removal mechanisms (eg frameworks) are not very good either. They’re just slightly less worse than before.

Yes, or better to see these products as time to market reducers.

There's plenty of times I have the option of writing my own code or using some good-enough framework that gets me started, and then add my own customizations over time.

Re: The Failed Commodification of Technical Work

#15
I once worked for a company that ran on the Phoenix Project ideas, treating devs as mechanical cogs in a factory; last time I've heard about them they were shutting down their main subsidiary and laying off most of the staff (already cherry picked from all around the world to minimize costs by automated tests more difficult than interviews at Google) while the leadershi* that led to that kept their positions intact.

Re: The Failed Commodification of Technical Work

#16

I think he’s right. The tech industry has been trying to commodify devs for a long time (COBOL, Java). But there’s a sort of essential quality that reasserts itself no matter what you abstract. Despite the seemingly simple requirements paired with high level frameworks, a lot of our software still doesn’t even work well. As the author notes. The only real fix is talented devs that care. You can make a career out of t…

The problem is that beyond the boilerplate we aren't solving commodity problems most of the time. If you've worked in the same field long enough, you'll see that things certainly rhyme, but everyone has slightly different business requirements. At each level of the stack this grows, and so in total there's a ton of non-commodity, bespoke work to do. That's why no two products are exactly alike and we don't just have…

Unless you're SAP, you always need to customise whatever you build for every customer.

You can have reusable components, but a full one size fits all solution is really hard.

Re: The Failed Commodification of Technical Work

#17
post #3

I think - and it's only a think - that the author has ignored that a large part of what used to be called technical work is now commodified. I remember when a mail merge literally meant printing out lots of address labels and then manually sticking them onto a letter & envelope. Word 2.0 (?) solved that problem for the 1990s and MailChimp has commodified it for the 21st century. Double-entry book-keeping was technica…

Nah, WordPerfect and wordstar had mail merge way before word did.

Re: The Failed Commodification of Technical Work

#18
I agree that the full commodification of technical work is a bad idea and will, hopefully, continue to fail.

However, having read the Phoenix Project twice and hating most of Scrum, I disagree that’s what the Phoenix Project is advocating for.

My main takeaways from the PP are:

1. Have clear systems in place to carry out and manage your repeatable work, automate where possible

2. Minimise the time work is in progress for so people aren’t bogged down with a million tasks

3. Share information widely and have multiple members of the team able to carry out the same task

4. Make sure the work being done is what the business actually needs doing

5. Reduce noise and unplanned work so staff can get on with the higher value work they actually enjoy rather than wading through a quagmire of disorganised chaos

The point of PP isn’t to turn people into interchangeable automatons - it is to put a system in place to allow people the headspace and time to do the really valuable work that can’t be automated or systematised.

I’ve run a factory and been a dev so I see it from both sides and making devs production factory workers isn’t sensible but likewise where work looks like factory work (known work, repeatable steps etc) it should be treated in a similar way.

Re: The Failed Commodification of Technical Work

#19
It requires an extreme level of selective amnesia to make McDonald's the operations standard for anyone. Try "the ice cream machine is broken today" on your next I.T. contract and see how far that gets you.

But to the author's point, I remember checking out a book from 1980 on software engineering from a highly well-known author (I forget who). I was shocked to read the author state unsarcastically that software development labor would be fully itemized in a standard catalogue like auto mechanic by the year 2000.

Re: The Failed Commodification of Technical Work

#20
I was really confused by the title, because doesn't "commodify" mean "to make saleable", like commercialize? Hasn't tech made billions?

I think the author is talking about "commoditization", eg genericizing tech work so that any replaceable employee can do it.

From https://en.wikipedia.org/wiki/Commoditization:

> This is not to be confused with commodification, which is the concept of objects or services being assigned an exchange value which they did not previously possess by their being produced and presented for sale, as opposed to personal use. One way to summarize the difference is that commoditization is about proprietary things becoming generic, whereas commodification is about nonsaleable things becoming saleable. In social sciences, particularly anthropology, the term is used interchangeably with commodification to describe the process of making commodities out of anything that was not available for trade previously.

Am I being pedantic? I thought the two had different meanings?

Edit: Ah, but wait... from Wiktionary instead: https://en.wiktionary.org/wiki/commodification

> Sometimes used interchangeably with commodification

Guess it's just a common mixup.

Post reply on HN