Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Failed Commodification of Technical Work

ludic.mataroa.blog

Post reply on HN
Print view View original

151–160 of 210 posts

Re: The Failed Commodification of Technical Work

#151

Post by ath3nd »

Pet_Ant wrote: post #101
ebiester wrote: post #66

Earlier quoted context omitted.

The Scrum guide does not capture the culture and ecosystem of scrum that has developed around it. It’s like Node without NPM.

That’s my point. Keep the guide, ditch the ecosystem. You don’t have to use Rails, Boost, Spring, or Scrum-XP-Rational-Waterfall. Sometimes back to the basics of the tool is needed, but don’t throw out the baby with the bath water.

Let's throw the guide as well, cause it's the people reading the guide who made the ecosystem.

If one is faced with a guide that essentially tells them: communicate well, don't be a douche, improve constantly, and do hard and smart work, and they are shocked by the guide's revelations, maybe we went somewhere wrong along the way.

Re: The Failed Commodification of Technical Work

#152

Post by anonymouskimmer »

suoduandao3 wrote: post #25
loloquwowndueo wrote: post #17

Earlier quoted context omitted.

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

I miss WordPerfect. Maybe it was the novelty but it had such enjoyable fonts.

It's still there if you want to buy it. At least in name.

Re: The Failed Commodification of Technical Work

#153

Post by Izkata »

solardev wrote: post #23
mikepurvis wrote: post #21

Earlier quoted context omitted.

I've always heard the term used in the sense that the author is using it. Oil is a commodity because there are many producers of it and it doesn't matter which one you get it from since they're all making the same thing.

Which term? Commodotize? Aren't we in agreement with the author then, that tech work isn't quite the same as oil or burgers (ie it hasn't been commodotized, even though it's been commodifed?) Or are you saying the two words mean the same thing?

Perspective of someone who isn't really in this space: I've always seen them as the same thing, except commodification is talking about the idea in general while commoditization is taking about a specific product.

Re: The Failed Commodification of Technical Work

#154

Post by manvillej »

I think the problem is that the outcomes of technical work is not equivalent to a product with a more static value. Simply put, software is not the same as a burger.

Software development to me is a financial investment strategy. Some risky investments, some safe bonds, some good debt to invest, some bad credit card debt that will be cleared later.

To me, these are the same as a risky overhaul of a critical system adding some automated tests, skipping some type annotations, or launching what was supposed to be a demo/MVP to be first to market.

a piece of software that took months to build could be worthless tomorrow if a competitor comes out with a better solution. There's a time value and strategy to it.

speeding up development with CD lowers the investment cost & time to market of an individual strategy. Automated tests lowers risk. Feature flag & AB testing diversifies the portfolio.

One line of code be the most valuable piece of a product, like Doom's Fast Inverse square root. and millions of lines of code could be worthless.

the value of a software engineer's work is extremely contextual. Two automation can be structurally the same, developed by the same person, written in the same language, take the same amount of time and resources; and still be COMPLETELY different in value.

until IT/software strategies are treated like an investment strategy, companies & leadership will continue to flounder when managing technical teams.

Re: The Failed Commodification of Technical Work

#155

Post by Throw10987 »

apsurd wrote: post #145
mikewarot wrote: post #129

Earlier quoted context omitted.

>If the technological progress had stopped in the 2000s, then all the grunt work (originated in the 90s) would be essentially zero today. If you wanted to have a simple database application in the 1990s, Delphi, VB6 or MS-Access were most of what you needed to get it done. The UI was drag and drop, the database was SQL, but you almost never touched it, mostly it was wiring up events with a few lines of code. The work…

Are all of those proprietary products? I can't speak on your experience, but if linux was created in 1991, seems like in another angle you're bemoaning the rise of OSS and web. I'm just a web developer that learned everything from online resources. So i think we are both biased on different ends on the spectrum.

I think the point is that the Access, Lotus Notes tooling was in largish corporations somewhat ubiquitous.

The experience of this tooling was make a change and it was in production. It was incredibly simple and productive to work with given the needs of the time.

There was also plenty of opportunities to make a mess, but I don't think that has really changed.

Learning was not difficult, you just had to be prepared to spend time and some money on books and courses.

It is not a tooling set you would want to go back to for a bunch of different reasons but it worked well for the time.

Re: The Failed Commodification of Technical Work

#156

Post by borlanco »

dmoy wrote: post #118
borlanco wrote: post #96

Earlier quoted context omitted.

> Programming is still a craft, not engineering, or manufacturing. Programming can be engineering if you know how to do it. Engineering is, in a nutshell, a set of principles you learn and apply, and never deviate from , in work and life . Engineers always deliver the highest quality. Craftspersons do not know these engineering principles, or they disregard them. They invariably deliver faster than engineers, and the…

> Engineers always deliver the highest quality. Engineers deliver a cheaper product that still meets some known set of requirements with whatever safety margin. The quality is as good as the requirements dictate. A big reason why software is largely not engineering is because nobody knows wtf the requirements actually are, and the dependency stack is unknowably large

It's true that engineering principles are not usually applied in the software field, but if quality is the most important requirement, they are indispensable.

Example: https://galois.com/

Example: https://inst.eecs.berkeley.edu/~cs162/sp13/hand-outs/They-Wr...

Re: The Failed Commodification of Technical Work

#157

Post by danielovichdk »

Reading the comments I haven't found any evidence for anything.

And that is the trouble with software in a nutshell.

The assumptions are too many and the subjective opinions too deep.

I rarely submit to assumptions any longer without the other person submitting at least some evidence for their claims.

Experience is important but gathering information on everyone's experience is more important to form some sort of experience based evidence.

I know everything everyone writes is well meant but damn I miss someone wrote a book and made a course on how professionalism shoukd ne based on evidence gathered from our fields experience.

The amount of managers incapable of commitment towards serving towards that are just what fred brooks said it was - they rarely exist.

Re: The Failed Commodification of Technical Work

#158

Post by mikewarot »

apsurd wrote: post #145
mikewarot wrote: post #129

Earlier quoted context omitted.

>If the technological progress had stopped in the 2000s, then all the grunt work (originated in the 90s) would be essentially zero today. If you wanted to have a simple database application in the 1990s, Delphi, VB6 or MS-Access were most of what you needed to get it done. The UI was drag and drop, the database was SQL, but you almost never touched it, mostly it was wiring up events with a few lines of code. The work…

Are all of those proprietary products? I can't speak on your experience, but if linux was created in 1991, seems like in another angle you're bemoaning the rise of OSS and web. I'm just a web developer that learned everything from online resources. So i think we are both biased on different ends on the spectrum.

Open source is great, Lazarus does a pretty good job of replacing Delphi.

Microsoft went insane with .NET so VB6 was killed in the process.

Access automatically handled table relationships, building queries and seeing them as SQL, and the report engine was pretty good. Thanks to ODBC, you could use the same database across all of them, or hook up to a real SQL server when it came time to scale up.

What's missing is the desktop and a stable GUI API these days. Windows apps from the 1990s still work, because they are distributed as binaries. Most source code from back then will not compile now because too many things have changed.

I love Open Source, but it doesn't solve everything.

Re: The Failed Commodification of Technical Work

#159

Post by acuozzo »

peteradio wrote: post #49
tboyd47 wrote: post #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 deve…

> that software development labor would be fully itemized in a standard catalogue like auto mechanic by the year 2000. That's pretty dumb... Software doesn't "break" and if it could be itemized to such a degree it could be made self-healing.

> Software doesn't "break"

It most certainly does because most software is written atop dynamic systems and every possible change cannot be pre-empted.

Extreme example: RAM writes accidentally flipping bits ala RowHammer. Broken, yes, but is it a bug?

Re: The Failed Commodification of Technical Work

#160

Post by bradleyjg »

danielovichdk wrote: post #157

Reading the comments I haven't found any evidence for anything. And that is the trouble with software in a nutshell. The assumptions are too many and the subjective opinions too deep. I rarely submit to assumptions any longer without the other person submitting at least some evidence for their claims. Experience is important but gathering information on everyone's experience is more important to form some sort of exp…

I find that some evidence is worse than useless. There’s always some evidence for anything and now you’ve got people with their deep subjective opinions held unshakably because they are SCIENCE.
Post reply on HN