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

91–100 of 210 posts

Re: The Failed Commodification of Technical Work

#91

Post by TeMPOraL »

booleandilemma wrote: post #10
steveBK123 wrote: post #9

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…

The problem is that beyond the boilerplate we aren't solving commodity problems most of the time. The only people that see it is a problem are the ones that wish programmers were commoditized. Your complexity is my salary.

> Your complexity is my salary.

Then your salary paid out of broken window fallacy.

But that's fine. All the nice, humane things happen where the market optimized things a little bit, but not too much.

Re: The Failed Commodification of Technical Work

#92

Post by x86x87 »

genghisjahn wrote: post #45
happymellon wrote: post #44

Earlier quoted context omitted.

All of those things have value if they are allowed to provide value. None provide value if management do not allow it to have value. > t-shirt sizes The whole point of planning poker is for people to guesstimate how much they think a task will take, and the poi t of doing it in a group is to allow the team to discuss the things they may not have thought about. > 2 hour sprint reviews I would agree that 2 hours is vas…

Planing poker is the one ceremony that I find consistently helpful. Listening to different devs discuss why they think something is 13 points or 3 points is helpful to the whole team. You could change the names of all the parts of the meeting, but having the discussion about differing opinions on complexity is so helpful.

In theory yes. Back on earth: I can argue that each task is 13 points. Usually this goes to being a pissing contest. The person that is deeply familiar with what needs to happen and has written this down (assuming written down not a one line to fix somthing) to be "estimated" probably is in the best position to acually do it/fix it. Also it's an insidious way to get the drones to fight each other trying to one up and show how smart they are. The person assigned to fixing it should estimate it (ie I have completely silenced "10x" developers by just telling them to just pick it up and do it if it's so easy).

Re: The Failed Commodification of Technical Work

#93

Post by Retric »

kspacewalk2 wrote: post #76
rswail wrote: post #38

Programming is still a craft, not engineering, or manufacturing. A software house should work like bespoke tailoring, or fine cabinetry, or glass blowing. There's still no better training for programming than the equivalent of master/journeyman/apprentice. Apologies for the gender specific terms, but they are specific to how tradespeople operated from medieval times. The worst thing to ever happen to the practice of…

None of what you're saying is an absolute truth. It applies in many environments, and in many others there is definitely space for commodification and MBA-style management gimmicks. It all depends on scale, technical complexity & maturity of the product, centrality of the software in question to the core product, etc.

Hardly, you’re confusing risk for commodification.

It’s possible for an an incompetent plumber to fix your plumbing problems by accident, expertise is about consistency. The dirty little secret is MBA led projects constantly fail in a truly spectacular fashion.

Re: The Failed Commodification of Technical Work

#94

Post by x86x87 »

underlipton wrote: post #61
rswail wrote: post #38

Programming is still a craft, not engineering, or manufacturing. A software house should work like bespoke tailoring, or fine cabinetry, or glass blowing. There's still no better training for programming than the equivalent of master/journeyman/apprentice. Apologies for the gender specific terms, but they are specific to how tradespeople operated from medieval times. The worst thing to ever happen to the practice of…

>There's still no better training for programming than the equivalent of master/journeyman/apprentice. This is inseparable from the fact that programming is still a domain dominated by white males from upper middle-class families (and immigrants from countries with functional, non-boondoggle professional training and/or demoscene). DEI as a rainbow-wash goes away when organic mentorship of black kids and young women…

I'm not following what your point is. Would there be a way to make everyone expendable faster is it wasn't just white entitled dudes?

Re: The Failed Commodification of Technical Work

#95

Post by pclmulqdq »

rswail wrote: post #38

Programming is still a craft, not engineering, or manufacturing. A software house should work like bespoke tailoring, or fine cabinetry, or glass blowing. There's still no better training for programming than the equivalent of master/journeyman/apprentice. Apologies for the gender specific terms, but they are specific to how tradespeople operated from medieval times. The worst thing to ever happen to the practice of…

Engineering is also a craft, but we have figured out how to manage it. The same will happen to programming (if it hasn't already). This happens to all crafts, from weaving to nuclear engineering.

Re: The Failed Commodification of Technical Work

#96

Post by borlanco »

rswail wrote: post #38

Programming is still a craft, not engineering, or manufacturing. A software house should work like bespoke tailoring, or fine cabinetry, or glass blowing. There's still no better training for programming than the equivalent of master/journeyman/apprentice. Apologies for the gender specific terms, but they are specific to how tradespeople operated from medieval times. The worst thing to ever happen to the practice of…

> 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 their output is always simpler and of lower quality.

In "The Rise of Worse is Better" [0], an engineer (from MIT) debates with a craftsman (from Berkeley). The Berkeley guy cheerfully admits he is disregarding an engineering principle (correctness), and that's why "the MIT guy did not like this solution because it was not the right thing".

[0] The Rise of Worse is Better https://dreamsongs.com/RiseOfWorseIsBetter.html

Re: The Failed Commodification of Technical Work

#97

Post by marcosdumay »

specialist wrote: post #58
artyom wrote: post #40

Earlier quoted context omitted.

Respectfully disagree. Meaningful answers from raw data is hard, but the hardest part was always making business people to _ask the right question_. Take as an example a typical business question: "which countries are our users from?" But do they mean the country the user declared in the registration form? Or country they're currently accessing your service from? Or the one from their payment method? Or the one where…

> ask the right question Exactly right. As a UI developer, I guess I had always assumed having close contact with end users and domain experts. Nothing I could articulate. It's just how things were done. Then I served in a QA Manager role for a while. Naive me started out focusing on the QC & Test parts. Eventually I figured out most of the value add comes from the Quality Assurance parts. Formalizing some of the stu…

> The Agile Manifesto cult swept aside all that silly formalism. "Too heavy!"

The Agile Manifesto puts close contact with the end users and domain experts as a fundamental principle (actually two principles, out of four). I do think you have the wrong culprit on your mind.

Re: The Failed Commodification of Technical Work

#98

Post by FrustratedMonky »

kspacewalk2 wrote: post #76
rswail wrote: post #38

Programming is still a craft, not engineering, or manufacturing. A software house should work like bespoke tailoring, or fine cabinetry, or glass blowing. There's still no better training for programming than the equivalent of master/journeyman/apprentice. Apologies for the gender specific terms, but they are specific to how tradespeople operated from medieval times. The worst thing to ever happen to the practice of…

None of what you're saying is an absolute truth. It applies in many environments, and in many others there is definitely space for commodification and MBA-style management gimmicks. It all depends on scale, technical complexity & maturity of the product, centrality of the software in question to the core product, etc.

Exactly

Like, there are mass produced furniture shops. (Say, building chat bot clones, or flappy bird clones). The basic layout/shape/function, is known and being tweaked.

Then there is the custom built furniture. I need an 18th century armoire. The 'Bespoke', a custom application for some odd business need, or solving a new problem.

We do often discuss these by squishing 'Software Engineering' into a single bucket and it leads to many arguments around really different things.

Re: The Failed Commodification of Technical Work

#99

Post by noarchy »

genghisjahn wrote: post #45
happymellon wrote: post #44

Earlier quoted context omitted.

All of those things have value if they are allowed to provide value. None provide value if management do not allow it to have value. > t-shirt sizes The whole point of planning poker is for people to guesstimate how much they think a task will take, and the poi t of doing it in a group is to allow the team to discuss the things they may not have thought about. > 2 hour sprint reviews I would agree that 2 hours is vas…

Planing poker is the one ceremony that I find consistently helpful. Listening to different devs discuss why they think something is 13 points or 3 points is helpful to the whole team. You could change the names of all the parts of the meeting, but having the discussion about differing opinions on complexity is so helpful.

Planning poker is only useful in the context of who may be doing the work, and even then I'm not sure how useful it really is. What is an 8 to one dev may be a 5 to another, as one may have a better grasp of the problem space than the other. In short, one shouldn't assume equality across the team for ability to do given task.

Re: The Failed Commodification of Technical Work

#100

Post by swatcoder »

rswail wrote: post #38

Programming is still a craft, not engineering, or manufacturing. A software house should work like bespoke tailoring, or fine cabinetry, or glass blowing. There's still no better training for programming than the equivalent of master/journeyman/apprentice. Apologies for the gender specific terms, but they are specific to how tradespeople operated from medieval times. The worst thing to ever happen to the practice of…

I approach the work like this and appreciate others who do, but it doesn't scale. It's engaging and fun and can produce more elegant, attentive, humanized work. But larger technology organizations (or organizations pursuing larger projects) need to draw on engineering and factory models to meet their software development needs the same way that IKEA and GM draw on them. Just like in software, there are still countless master woodworkers and master mechanics who bring beautiful attention to their craft, but there is also a scale where that approach is simply not suitable. The different scales coexist and even comingle, and they're all valid.
Post reply on HN