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

Developers are attached to tools because tools encode trust

stackoverflow.blog

Post reply on HN
Print view View original

81–90 of 148 posts

Re: Developers are attached to tools because tools encode trust

#81

Post by kelnos »

hilariously wrote: post #69
ozim wrote: 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?

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 ship something that requires a team of consultants six months to set up before anyone can do anything useful with it. Of course no one wants that. (Well, except for the highly-paid consultants.)

Re: Developers are attached to tools because tools encode trust

#82

Post by kelnos »

saimiam wrote: post #78
hilariously wrote: post #69

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?

Just up thread from your comment, someone commented in a positive way on the infinite customisability of vi. So which is preferable - customisability or very limited feature set?

I think the problem with the vi/vim example is that it's very much not for everyone. I use it, and have used it for 25-odd years, but I'm not an expert at it by any means (because I haven't taken the time to try to be), and occasionally have to look up how to do something. But I've customized it to my heart's content, and feel very productive in it.

But I would not expect a large percentage of developers to want to do that. I've used IDEs as well, and they're mostly fine, and work really well for lots of people. Many IDEs are pretty damn customizeable too, though most people may not change many settings.

Re: Developers are attached to tools because tools encode trust

#83

Post by kelnos »

ToValueFunfetti wrote: post #63
musicale wrote: post #53

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.

I feel like everyone is forgetting Windows 2000, which IMO is the best Windows that MS ever released. The main problem with it was hardware support, since people were hesitant to move away from the 95/98/ME line, and hardware manufacturers were still playing catch-up, as most didn't support NT 3/4 at the time and didn't see a need, as it was largely a server/business OS. But otherwise it was rock solid, fast, and a breath of fresh air.

I did try XP here and there, but was instantly turned off by the cartoonish default theme (yes, I know you could change it). It was buggier than Win2k, and I didn't have the patience to wait around until they fixed it. I was told later on by people in the know that Service Pack 3 was the bees knees, but by then I'd moved on to Linux full-time (with some jaunts into OS X) and felt no need to come back.

Re: Developers are attached to tools because tools encode trust

#84

Post by kelnos »

denkmoon wrote: post #70
MiddleEndian wrote: post #38

This article is a bit rambly so I'll just focus on some things from the beginning: >If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in. This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates. To use one product as an example: When Windows ME and Windows Vista came out, people hated them even…

What's really freakin cool about AI development is other people can check rules into the repo which change the shape of my tools :)

That sounds incredibly annoying to me. Not cool at all. (I would assume you're being sarcastic except for the smiley at the end of your comment.)

The thing about it, though, is that LLMs aren't "your" tools. They're someone else's tools, and you are at the whims of day-to-day changes to them.

Re: Developers are attached to tools because tools encode trust

#85

Post by cosmic_cheese »

MiddleEndian wrote: post #38

This article is a bit rambly so I'll just focus on some things from the beginning: >If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in. This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates. To use one product as an example: When Windows ME and Windows Vista came out, people hated them even…

A big driver of automatic updates in the late 00s and early 10s were people who never updated their OS or browser and were getting compromised left and right. As I recall, one of the earliest widespread users automatic updates was Google with Chrome, which they did because otherwise there was no way to respond to severe 0days and such before huge swathes of users got hit.

So I think there's a place for automatic updates, but the feature should be restricted to security fixes only. Using it to foist ill-conceived changes on users is just abuse.

Re: Developers are attached to tools because tools encode trust

#87

Post by BobbyTables2 »

kelnos wrote: post #80
BobbyTables2 wrote: post #72

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…

I suspect they were thrilled at the prospect of a better made product (not encumbered by historical baggage) that cost less, had a lower friction sales process, made by a company actively trying to win them over.

Re: Developers are attached to tools because tools encode trust

#89

Post by kelnos »

matheusmoreira wrote: post #66
slopinthebag wrote: post #57

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.

A month or so ago I asked Claude about using open-weight models through another provider (after describing my usage patterns), and, amusingly, it told me that I could probably save money ditching my Claude Max 5x sub and switching to something like Fireworks, using GLM 5.2, even if I'd be paying API rates.

I still haven't gotten around to trying it, though, so I don't know what the reality is. And new open-weight models have been released since then that I'd want to evaluate...

Re: Developers are attached to tools because tools encode trust

#90

Post by mendapi »

kelnos wrote: post #80
BobbyTables2 wrote: post #72

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…

[flagged]
Post reply on HN