Live data from Hacker News

Developers are attached to tools because tools encode trust

stackoverflow.blog

111–120 of 149 posts

Re: Developers are attached to tools because tools encode trust

#111
post #61

Earlier quoted context omitted.

That's not just developers as you noted. It is "velocity fallacy" — product people want "all the features ASAP or right away". Until users with their managers come with pitchforks and torches. I worked on such internal project where we as developers were able to deliver new features and new version every 2 weeks (which is not a pinnacle of the game of course) and were thinking if we can move to daily delivery. Becaus…

This is exactly what I said to the last company (which is basically shutting down now lol) management - "infinite customizeability" means "zero percent understandability" for a typical suite of software. I literally was told not to narrow down the features too much or the product would be too constrained... well then wtf does it actually _do_ for anyone?

OTOH, there's spreadsheets. The abstraction is just so great that users can and do use them for anything.

The problem seems to be that there's not many such great abstractions to be found.

Re: Developers are attached to tools because tools encode trust

#112
post #81

Earlier quoted context omitted.

I don't think infinite customizeability is a problem. Poor default configurations are the problem when you build in the ability to customize. The idea is that the user should be able to be productive more or less immediately after installing the software, and then incrementally customize it as they discover they have different needs than the defaults give them. A lot of developers/companies forget the first part, and…

What mythical software is this? The only infinitely customizable software I can think of is emacs, and that takes an enormous amount of effort to become proficient.

Spreadsheet software, like Excel.

Re: Developers are attached to tools because tools encode trust

#114
post #80

Earlier quoted context omitted.

> Customers...never wanted to update, due to risk of changes [...] We’d get escalations on things that were fixed years ago [...] as upstart competitors stole [our] market share. This is so weird to me, though. Your customers had two choices: 1. Stay with your software and upgrade to the latest version, where the bugs they were hitting were fixed, and risk some amount of retraining due to UI/UX changes. 2. Switch to…

You are assuming the changes would all be positive, minus some UI hassle. I have seen plenty of products where vital workflows were scrapped entirely or made significantly more clunky. Modern software is quicksand. Maybe an update improves things, but users have all experienced working software made worse.

Yup. Powerful features are removed to "streamline experience". Sometimes in bulk, because product migrated from e.g. bespoke native app to multiplatform webshit in an embedded browser, which automatically halved the performance and removed most ergonomics.

And then new features are released as MVPs - meaning, they do the absolute minimum to check the box (almost a literal box: close the feature ticket internally), and inefficiently so. Whether it'll be iterated on afterwards, depends. Pretty unlikely in the immediate term. They need to "collect usage data to know what to do" first, which means it gets deprioritized relative to moar features.

But that's fine for me. As long as copy-paste works, I can make do with other software, perhaps competing software, or worst case, have Claude find and use some powerful-but-janky OSS CLI tool to do the stuff for me.

I'm less angry at it than I used to. Mostly because I don't have time to be annoyed anymore, but it's true that I've learned to like updates from few companies. That's because after years - years - I've noticed things gradually improving on average. True of Android & Samsung OneUI, except when it's not. True of UniFi stuff. If I see some new feature behaving badly, I now mostly trust they'll eventually fix it. It'll take a year or three, they'll overhaul it entirely twice, and I may need to buy a new phone to get it, but it will happen one day. But most software doesn't even clear that bar.

Re: Developers are attached to tools because tools encode trust

#115
post #81

Earlier quoted context omitted.

This is exactly what I said to the last company (which is basically shutting down now lol) management - "infinite customizeability" means "zero percent understandability" for a typical suite of software. I literally was told not to narrow down the features too much or the product would be too constrained... well then wtf does it actually _do_ for anyone?

I don't think infinite customizeability is a problem. Poor default configurations are the problem when you build in the ability to customize. The idea is that the user should be able to be productive more or less immediately after installing the software, and then incrementally customize it as they discover they have different needs than the defaults give them. A lot of developers/companies forget the first part, and…

Sensible defaults and/or a basic wizard to choose templated configs or assist with customising the few things that have to be.

Re: Developers are attached to tools because tools encode trust

#116
post #80

Earlier quoted context omitted.

I’ve seen this too and it’s darkly humorous. We published 1-2 releases of our component each month. Eventually another (internal) team would pick it up along with others, test, and release the combined set maybe 1-2 times a year. Customers being extremely risk adverse never wanted to update, due to risk of changes combined with the interruption, even though we were fixing serious bugs left and right from the earlier…

> Customers...never wanted to update, due to risk of changes [...] We’d get escalations on things that were fixed years ago [...] as upstart competitors stole [our] market share. This is so weird to me, though. Your customers had two choices: 1. Stay with your software and upgrade to the latest version, where the bugs they were hitting were fixed, and risk some amount of retraining due to UI/UX changes. 2. Switch to…

Yes, they go with #2 because they are really p***.

As anecdote of one, I was once part of a project to port a .NET Framework to Java, because the customer was really annoyed with the rewrite, as the application relied heavily on the .NET Features that never made the cut to modern .NET.

Another two .NET heavy weights in .NET CMS space, Sitecore and Optimizely, nowadays rely on JS/TS frameworks for their extensibility SDKs on the SaaS products for headless deployment, only the classical (older) PaaS still support .NET as extension language.

Re: Developers are attached to tools because tools encode trust

#117

Earlier quoted context omitted.

> When Windows ME and Windows Vista came out, people hated them even more than they usually hated Windows, so they did not use them. Microsoft was forced to respond by making a not-quite-as-bad OS in Windows XP This timeline doesn't seem to make sense, as Windows XP came out in 2001, and Windows Vista in 2006-2007. Maybe you are referring to Service Pack 3 in 2008?

Reactions to Windows ME forced MS to respond with XP; reactions to Vista forced them to respond with 7. They're being stated in parallel rather than chronologically.

Nope, XP was the introduction of Windows NT linage into mainstream computing, ME was basically 98 with a few goodies to keep selling newer 9x versions in the meantime.

Re: Developers are attached to tools because tools encode trust

#119

There's this great blog post by Joel Spolsky from 2000 [1], where he essentially argues that controlling your environment makes you happy. He writes about his summer job in a bakery and how the dough mixers would be so unpredictable and how frustrating that was. I think AI agents are quite similar to a lot of folks, they change significantly with each major model update and even every day as the vendor tweaks the sys…

This is, I think, a big part of why I wouldn't want to remove myself from the loop.

Re: Developers are attached to tools because tools encode trust

#120

Earlier quoted context omitted.

Crazy amount of effort when you can just use a different harness and a better and cheaper model.

"Cheaper" compared to API prices, right? I've run the numbers and the frontier subscriptions are still the best option. 100% usage every week is a truly absurd amount of value. Unfortunately the subscriptions can't be used outside the official harnesses.

Trying to force myself to find ways to extract full value out of such a subscription sounds very unpleasant.
Post reply on HN