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

161–170 of 210 posts

Re: The Failed Commodification of Technical Work

#161

Post by msla »

mikewarot wrote: post #158
apsurd wrote: post #145

Earlier quoted context omitted.

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 t…

> Windows apps from the 1990s still work, because they are distributed as binaries.

Only if you have the right libraries, and runtimes, and OS interfaces, and even if you have all that, oh no, it's a MIPS binary and you don't live in 1996!

Any proprietary API exists precisely as long as the owner says it does. Open standards don't suffer from that malady.

Re: The Failed Commodification of Technical Work

#162

Post by rawgabbit »

What the author failed to mention is that the software industry itself is also responsible for this state of affairs. I am talking about the consultants and the salesmen of enterprise software. In many cases, they convince CEOs that they simply need to sign a contract and all their problems will be solved. They don't care to explain the high rate of failure of software implementations or how much manpower is needed on an ongoing basis to maintain the shitty software.

CEOs think they are buying an appliance. e.g., I buy a coffee maker, I pour water into it, I put in the coffee pod, I press the button, and coffee comes out. In the best scenario (from a CEO perspective), they are getting an assembly line someone else put together for them. e.g., the CEO hires a general contractor who lines up all the subcontractors, installs the different pieces of equipment including the "glue" that connects them, and will maintain equipment going forward. The CEO simply needs to pay for the capital expense and provide the operators for the assembly line. In the typical scenario (bad from a CEO perspective and bad for the software industry), what the CEO gets is a stack of re-purposed software modules that have been pressed together in a slip-shod fashion that works when it wants to and fails without a trace as no logging exists. The CEO has to hire IT developers just to get the thing to run. And he will now look for his next job because the board of directors told him, you failed.

Re: The Failed Commodification of Technical Work

#163

Post by JackMorgan »

manvillej wrote: post #154

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 add…

I agree whole-heartedly!

I am sometimes called upon to audit codebases for acquisitions. I've spent enough time in the strategic accounting world to realize that we almost have no concrete units of measurement to talk about software. Lines of code is as meaningful as the count of boards in a house. In a house, we can at least get total square feet, number of legally defined bedrooms and bathrooms, lot size, etc. In software, we've got almost nothing.

I've seen tiny codebases that can CRUD hundreds of different records, and I've seen multi-million line codebases that can barely handle saving a dozen different records. Consider all the ways data flows in and out of a system: asynchronous processes, batch processing, auditing, third party integrations, permissioning, reporting, and legacy system integrations. Each of these change the value and technical debt of a system.

I suspect we will have an increasing need to perform an accurate audit of a codebase. And provide the value, depreciation, and debt of a system in dollars. I would love to see a standardized metric for accounting for assets and liabilities.

Re: The Failed Commodification of Technical Work

#165

Post by josephg »

Throw10987 wrote: post #155
apsurd wrote: post #145

Earlier quoted context omitted.

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…

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

I remember using lotus domino at one of my first jobs. There were all sorts of things I hated about it. But you could have a database - like the company’s mail database. And define views on that database (eg looking at your inbox, or a single email). And the views would replicate to a copy of that database living on all of your users’ computers. And so would the data they needed access to. It was so great - like, instead of making a website, you just defined the view based on the data itself and the data replicated behind the scenes without you needing to write any code to make that happen. (At least that’s how I understood it. I was pretty junior at the time.)

Programming for the web feels terrible in comparison. Every feature needs manual changes to the database. And the backend APIs. And the browser code. And and and. It’s a bad joke.

Commodification has a problem that for awkward teenagers to make the same fries every day, we have to ossify the process of making fries. But making good software needs us to work at both the level of this specific feature and the level of wanting more velocity for the 10 other similar features we’re implementing. Balancing those needs is hard! And most people seem content to give up on making the tooling better, and end up using whatever libraries to build web apps. And the tools we have are worse in oh so many ways compared to lotus domino decades ago.

I wonder what the original lotus notes designers think of web development. I think they’d hold it in very low regard.

Re: The Failed Commodification of Technical Work

#166

Post by marcosdumay »

specialist wrote: post #139
marcosdumay wrote: post #97

Earlier quoted context omitted.

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

Agreed. When devs, QA, and other doers have a direct line to customers, there's no problem. In my personal experience. That arrangement has been rare. More common is gatekeeping and incompetence. (Which may be the same thing.) -- I've never figured out how to do "agile" QA/QC/Test. I'd don't even know what it'd look like. And, yes, my prior experiences and expectations may be keeping from seeing the new paradigm. Whi…

Well, with Scrum or whatever usually passes as agile, I have no idea either. And I imagine people can't really answer your question, because almost nobody practices the stuff on the manifesto. The motto would be certainly be to bring the customer around to specify your tests, but the actual procedure is a bit hard to imagine the details.

Anyawy, my comment was just to point that it's not exactly the manifesto stopping you.

Re: The Failed Commodification of Technical Work

#167

Post by marcosdumay »

Pet_Ant wrote: post #48
simonbarker87 wrote: post #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…

> hating most of Scrum I'll just say that if you look at Scrum itself there is really nothing objectionable to it. https://scrumguides.org/scrum-guide.html It's the other shit people pack on top of calling it Scrum that usually sucks ass. I've found the best way to fight back against shitty-Scrum is not to fight it, but actually feign puritanical allegiance to the actual doctrine, it's much less repulsive. I makes yo…

You mean dividing features into fixed-size timeboxes without even bothering to fully define them isn't objectionable?

Re: The Failed Commodification of Technical Work

#168

Post by athrowaway3z »

(Enterprise) Java grew a lot because the non-technical message managers got was something more like: An engineer can produce objects, and we can swap out objects and their factories. That way we might one day in the future decide we want a faster object or choose a cheaper object.

In the decades since, the 'progress' we've made can be summed up as dropping the J in JVM.

Re: The Failed Commodification of Technical Work

#169

Post by Simon_ORourke »

gustavus wrote: post #135
Simon_ORourke wrote: post #134

Doing some project lit. review a few years back, I came upon the area of component-based software engineering (CBSE), where the idea was to mirror the same kind of manufacturing approach as in electronics. You'd write a software component to do one thing, and have well defined inputs and outputs, and you could then "simply" compose complex systems by chaining lots of these software components together. Nice idea by m…

Congratulations you've reinvented the concept of a library.

Funnily enough, that's where that particular write-up ended up in.

Re: The Failed Commodification of Technical Work

#170

Post by entrepy123 »

mikewarot wrote: post #158
apsurd wrote: post #145

Earlier quoted context omitted.

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 t…

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

I'd love to hear more about this perspective or any links to get more of it.

I did a (very) little hobby VB6 and loved it. Never made switch to .NET at that time (I was young, it was a hobby).

Having recently worked through part of a .NET book, I was pretty impressed by how far MS took it (although it seems extremely mind-numbing). Obviously it took a long time and had false starts, but MS stuck with it. On a personal level, I am very opposed to the entire model in an ideological sense, but it does seem to make a lot of business sense for MS, and it seems to cover a lot of cases for a lot of businesses.

So, was Microsoft's insanity with .NET just the obsession part, or doing things poorly for a while, until eventually getting it "righter", or is the insanity still pretty apparent?

I really would love to learn more about the historical-technical aspects of this specific comment quote, from VB6 to modern day, because it fits my experience perfectly, but I've had second thoughts about the position more recently. The more the specifics the better.

Post reply on HN