[HN Gopher] Every change breaks someone's workflow (2013)
___________________________________________________________________
Every change breaks someone's workflow (2013)
Author : ColinWright
Score : 88 points
Date : 2024-10-07 15:24 UTC (7 hours ago)
(HTM) web link (xkcd.com)
(TXT) w3m dump (xkcd.com)
| happytoexplain wrote:
| The opposite problem is much more common and shouldn't be
| downplayed: A developer or designer using the "every change
| breaks someone's workflow" exaggeration as an excuse to break a
| workflow.
| maaaaattttt wrote:
| or (worse?) to not change anything; but I think this comes
| usually more from devs (guilty as charged).
| JohnFen wrote:
| This.
|
| The fact that any change to software people are used to using
| will bring pain to the users shouldn't mean that devs
| automatically prefer or avoid breaking workflows. What it
| should do is encourage actually thinking about the cost/benefit
| (to the user) of the change.
|
| Users will accept the pain that change brings if the benefits
| of that change outweigh the cost of it. If the cost/benefit
| ratio isn't favorable to the user, they will, quite
| understandably, resent the change.
| Netch wrote:
| Most cases an initial estimate of change cost is utterly
| overstated because emotional and reluctant to change.
|
| (And, well, this fact is also abused by wreckers who explain
| any reasonable objection with this factor;))
| BiteCode_dev wrote:
| "We don't break userspace"
| jtorkkola wrote:
| Hyrum's Law: "With a sufficient number of users of an API, it
| does not matter what you promise in the contract: all observable
| behaviors of your system will be depended on by somebody."
|
| https://www.hyrumslaw.com/
| bladedtoys wrote:
| For example
| https://unix.stackexchange.com/questions/405783/why-does-man...
| eviks wrote:
| Where is the example of a dependency? The link is about an
| unexpected behavior that broke something, not that someone
| depended on 3 gimmes
| madamelic wrote:
| I once worked at a place where we essentially were unable to
| fix bugs because it was a no-code tool so people would do all
| kinds of wacky things with the system.
|
| The mandate was, as far as I can tell, to enshrine these former
| bugs into actual documented features. I wish I had seen this as
| a warning for how the place was ran but I also needed the
| money.
|
| That was on top of people doing completely stupid things and
| abusing the systems we gave them in exchange for way too little
| money. It got to the point where the company was offering
| dedicated servers as an upsell because there were clients that
| were paying far too little money, in my opinion, for the amount
| of resources they were taking up.
|
| The breaking point came when I got woken up at 3am two nights
| in a row by a client who was very obviously an Indian scam call
| center who was paying us something like $100 / mo to have a
| button that calls an engineer at any time. The problem was they
| had something like 7 layers of recursion through their app and
| each update was causing cascading updates and unsurprisingly
| was taxing the entire server causing updates to be slow and/or
| unreliable.
|
| Maybe I just sucked at it but I told leadership we need to jack
| up prices on that button and kick these pretty obvious scammers
| off the platform. I left a few months later.
| Rendello wrote:
| I was going to make a tongue-in-cheek suggestion about
| randomizing undefined behaviour, but I suppose that's common in
| debugging and even seen in some APIs.
|
| At one time, in Python, dictionary (hashmap) ordering was
| randomized so users wouldn't rely on non-specified ordering
| behaviour. Eventually though, dictionaries were guaranteed
| insertion ordering.
|
| https://www.youtube.com/watch?v=p33CVV29OG8
| jjdgfbnk wrote:
| > LOOK, MY SETUP WORKS FOR ME. JUST ADD AN OPTION TO REENABLE
| SPACEBAR HEATING.
|
| Best part is the condescending and ignorant use of "just" and the
| generally demanding, rather than requesting, tone in the
| incredulous follow up.
| marcosdumay wrote:
| And that's why when you need to change a lot of things in $APP,
| you create a new one called $APP2 or whatever, and keep the old
| one in existence.
|
| At least until everyone adapts. Ask for money if it's too much
| trouble.
| TeeMassive wrote:
| This is why it is important to stratify your API promises.
|
| Git is a good example of this, with "plumbing" commands meant for
| scripts and software and "porcelain" commands meant for a more
| comfortable user experience. Code is rigid while humans are
| flexible.
|
| Only freeze APIs that have been proven in the field to be stable
| and necessary in the field by thousands of people.
| poincaredisk wrote:
| Except git porcelain are already frozen long time ago, codified
| in millions of CI/CD pipelines, and impossible to change. It's
| not a great comparison.
|
| Hell, "apt" explicitly warns you not to use it in scripts, and
| yet everyone does.
| dewey wrote:
| I was just thinking about that today as I was reading through
| some bug reports of the podcast app I'm using (Overcast). Someone
| was happy that a bug got fixed that caused an issue for them,
| they shared a screen recording and you can see that they use what
| looked like 300 playlists with filters to sort their podcasts
| into all kinds of buckets.
|
| The developer of the software commented: "This is the most
| playlists I've ever seen. By far."
| eastbound wrote:
| We've discovered with experience that every app which looks
| like a table and allows free text fields will be repurposed as
| a job applicant tracking tool, with uncontrolled discrimination
| comments.
|
| And this is bad because it's not GDPR-compliant (but
| fortunately, it's not the fault of the software vendor, but of
| the data controller).
| barbegal wrote:
| This is why I don't like semantic versioning. Semantic versioning
| only covers the "public API" but even the smallest "patch" change
| can result in a change in behaviour which has a big impact on the
| users.
| eptcyka wrote:
| I have maybe seen it once when semver was being used.
| poincaredisk wrote:
| This is covered in the spec. "Use your best judgement" is the
| answer. What's the other solution? Just give up and version you
| software sequentially/by timestamp?
| vfclists wrote:
| Linus T. - You don't break user space!!
|
| Kent O. - Yes I do, and "you" should!!
___________________________________________________________________
(page generated 2024-10-07 23:02 UTC)