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

Computers Reduce Efficiency: Case Studies of the Solow Paradox (2023)

scottlocklin.wordpress.com

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Computers Reduce Efficiency: Case Studies of the Solow Paradox (2023)

#81

Post by flavaz »

pnut wrote: post #46
flavaz wrote: post #7

A classic example of this would be how some roles require endless spreadsheets, or individual updates to a CRM tool like Pipedrive. CRM tools add a lot of overhead to what should be a simple process- letting your manager know what you’re up to.

I'm not a CRM end user, but I'd be very grateful for such a tool if I had to suddenly cover for a coworker, or inherit an existing business relationship. What is the alternative, each person individually cobbles together some godawful workflow management system? With no centralised repository of information? Totally unsustainable, and not at all related to keeping your manager informed.

I think there is a tendency to overcomplicate things, and human nature is such that most of the time colleagues don’t bother to update records properly. That’s the real-world experience CRM salespeople won’t tell you.

What also happens is that we have all these CRM tools in parallel with these “godawful workflow management” systems.

Theoretically there is a productivity gain, sure, but senior executives don’t make use of these tools, they hire a PA. The implementation of these CRM systems is usually done really really badly.

A good superset dashboard on the other hand- then we’re cooking with gas

Re: Computers Reduce Efficiency: Case Studies of the Solow Paradox (2023)

#83

Post by Gibbon1 »

7thaccount wrote: post #71
virtue3 wrote: post #17

I think this article is drastically downplaying how dramatically more complicated designs and things are now than they were before. I don't believe it's computers that are to blame; I believe it's complexity nightmare problem. We have much tighter tolerances for everything now; everything "does more" and relies on my components. Back when we used pen and paper to create military vehicles it was mostly JUST about perf…

Agreed. Complexity could ultimately be our downfall. Everything is drastically more complicated than before and the margins for safety are getting more and more reduced. Take my own industry of electricity markets for example. It used to be you had large vertically integrated utilities that handled generation of power as well as the transmission of it to the residential grid (distribution). They would run the grid an…

Reminds me before the 2008 financial crisis you used to hear finance types and economists crowing about financial innovation. After that they've been more quiet. But they never exactly came out and said what it was. I can tell you it's about efficiently collecting rents. Being able to pick people pocket faster and cheaper so you can pick more pockets. That isn't most people think of when they hear the word innovation.

(Edgy comment over).

(Less edgy comment begins)

The finance share of the US economy went from 4% 50 years to 17% today. It feels likely that there are been zero or less than zero benefit over all from that.

Everyone has a internet connected doorbell now. 50 Yeah ago my parents never locked their front door.

Lots of complexity that seems to provide no overall value.

Re: Computers Reduce Efficiency: Case Studies of the Solow Paradox (2023)

#84

Post by pas »

datadrivenangel wrote: post #66
pas wrote: post #61

Earlier quoted context omitted.

The problem is that we are flooded with low-quality tools. In general it is almost universally true of software nowadays. (Because change/progress leapfrogged any kind of teleological end-to-end design OR it's simply unmaintained, for example see any US government IT system. Or the ubiquitous extremely fragile corporate synthetic snowflake software that only runs on Windows XP SP1 + that 3 particular patches with tha…

Ideally you computerize away the process as much as possible. A common failure mode of digital transformation processes is taking the old people process and computerizing it without revisiting the underlying process.

Other important thing is that paper was able to handle "all the exceptions", notes on margins, corrections, other paper clipped to it, whatever. Sure it was ugly, but it was in-band.

If there's no way to do this in a new system, then it means there will be a parallel semi-official informal shadow of it scattered around in out-of-band channels (emails, phone, paper!), and that leads to more complexity, which kills efficiency.

Re: Computers Reduce Efficiency: Case Studies of the Solow Paradox (2023)

#85

Post by pas »

littlestymaar wrote: post #63
pas wrote: post #61

Earlier quoted context omitted.

The problem is that we are flooded with low-quality tools. In general it is almost universally true of software nowadays. (Because change/progress leapfrogged any kind of teleological end-to-end design OR it's simply unmaintained, for example see any US government IT system. Or the ubiquitous extremely fragile corporate synthetic snowflake software that only runs on Windows XP SP1 + that 3 particular patches with tha…

I think the main reason why we're flooded with low quality tool is due to the fact that with software you just copy-paste your prototype to production: unlike real world system where you build a prototype to show stuff and then have to industrialize it to get to production, for software this expensive (and crucial for quality) step is skipped entirely, and we are all stuck using prototypes… This and seeing “code writ…

Yep, the elimination of in-house expertise was ridiculously short-sighted (which is an extremely charitable and euphemistic version of breach of fiduciary duties).

Re: Computers Reduce Efficiency: Case Studies of the Solow Paradox (2023)

#86

Post by p_l »

mrob wrote: post #44
p_l wrote: post #36

Earlier quoted context omitted.

The amount of pixels that had to be rendered and pushed, as well as certain lower security in windows 2000, meant that just the pushing of pixels was simpler compared to today. Windows 11 graphic path even for same application code as on windows 2000 is way more complex, and arguably most of that complexity is warranted and needed . Otherwise you get unfortunate side effects like simple text editor using surprisingly…

The main benefit of 4K displays is sharper vector fonts. It's very important to imitate the exact shapes of print fonts, so despite sharp fonts already being available for decades in bitmap form, we've got to push those pixels. Likewise, it's very important to know the exact Z-order of the window stack at all times, despite only interacting with one at a time. This means it's absolutely necessary to render translucen…

While I'm similarly bitter at how things have gone effectively worse, the actual driver path, assuming same user-space code, involved a significant increase in complexity for good reasons.

Back in Windows NT 4.0 - 5.3 days, GDI would draw direct to VRAM. Fast, simple, but prone to rendering glitches that left corrupted screen unless something would redraw the area.

The amount of pixels was way lower - and we already were using a lot of vector fonts at the time anyway. With higher resolutions, even when you scale by integer value, you need a way faster blitter, and new caching and rendering methods. While GDI had reasonably good hooks for caching, they don't necessarily map well with GPU architecture, and on-GPU blitting is way different than old Windows 2D acceleration architecture that worked fine with GDI - and lower resolutions.

Both for security reasons and to prevent glitches, and honestly to also handle caching & rendering better in modern GPU, you need indirect system between GDI and GPU. Once you have shaders rendering windows contents as texture on triangle strip of 2 triangles, adding blur or transparency was close to zero cost unless you have really resource constrained system (and then you had other issues, really).

And windows had to track exact Z-order since Windows 2.0 introduced overlapping windows, otherwise painter algorithm & gdi caching got confused (it was used to know exactly when to send MSG_PAINT to what window and with what params).

Animations are iffy thing, but usability research suggests that some animations, especially in a world where computers are often very silent and have no indicators (neither HDD sounds nor activity LED, for example), is indeed necessary to help majority of users know when computer is "doing something" or just hung.

As for the last point... I agree 200%.

Re: Computers Reduce Efficiency: Case Studies of the Solow Paradox (2023)

#87

Post by api »

chiggsy wrote: post #78
api wrote: post #53

Earlier quoted context omitted.

The curse of tools applies in computing too. A virtue of languages like Go is that they reduce incidental and gratuitous complexity through the simplicity of the language. A complex language with a powerful type system like Rust or C++ will tempt programmers to use every facet of the language and create baroque overly complex code.

Sounds like an argument for C, honestly. After all, that complexity is either in the language, or solved on a case by case basis. Every patch adds complexity, because it reflects changes in the business environment that presents the problem the code is solving.

C is okay except safety. Look at the CVE lists and they are still full of memory errors and it’s 2024.

The problem isn’t that good programmers can’t write good C code, though anyone can make a mistake. The problem is what happens as code ages, is worked on by other people, gets PRs merged, and so on. Bugs creep in and in an unsafe language nothing catches them.

C also makes string processing hellish, but that could be fixed with libraries and isn’t necessarily the fault of the language.

Re: Computers Reduce Efficiency: Case Studies of the Solow Paradox (2023)

#88

Post by sourcepluck »

cedilla wrote: post #45
sourcepluck wrote: post #15

Earlier quoted context omitted.

Provide a link to Stallman using that term then please? Otherwise, I'm calling nonsense. I'd be 95+% sure you're making that up, or confused in this case.

He's not using "computard" but he loves to undermine his credibility by talking about the "Amazon Swindle" and such.

Ok, so, the thing I was replying to was just someone claiming false things as I imagined. Glad we cleared it up.

Re: Computers Reduce Efficiency: Case Studies of the Solow Paradox (2023)

#89

Post by cedilla »

sourcepluck wrote: post #88
cedilla wrote: post #45

Earlier quoted context omitted.

He's not using "computard" but he loves to undermine his credibility by talking about the "Amazon Swindle" and such.

Ok, so, the thing I was replying to was just someone claiming false things as I imagined. Glad we cleared it up.

No, you just misunderstood what OP meant by "this". They meant using portmanteau neologisms, and you thought they meant that specific portmanteau.

No need to be nasty about it.

Re: Computers Reduce Efficiency: Case Studies of the Solow Paradox (2023)

#90

Post by TazeTSchnitzel »

cedilla wrote: post #89
sourcepluck wrote: post #88

Earlier quoted context omitted.

Ok, so, the thing I was replying to was just someone claiming false things as I imagined. Glad we cleared it up.

No, you just misunderstood what OP meant by "this". They meant using portmanteau neologisms, and you thought they meant that specific portmanteau. No need to be nasty about it.

Yes, I meant his practice of coming up with silly nicknames for things he dislikes, not that he used this one specifically.
Post reply on HN