6 ms·

> The goal is for workflows to evolve This exchange is a pretty good summation of one of the biggest purely practical reasons why I'm so obsessive about tools,

> The goal is for workflows to evolve This exchange is a pretty good summation of one of the biggest purely practical reasons why I'm so obsessive about tools, and why I'm so willing to put up with the initial cost of learning systems like Linux and Vim/Emacs. Outside of fundamentally better workflow improvements, most professional fields don't randomly change their tools. If you gave a professional artist a new pencil that had to be gripped differently for no reason, they'd throw it in the trash. But in software, we tolerate buggy tools that change all the time for no discernible reason. We tolerate software that simultaneously targets professionals and casual users, serving both segments poorly. We tolerate software that can't be customized or adapted for specific workflows. It's tough to put into words, but if you watch a musician or a painter interact with their tools, there's a very clear difference that emerges, and over time you start to realize how much better all of their stuff is. In most professional artistic settings, workflow changes only happen because they have a clear benefit -- drawing from your shoulder instead of your wrist, changing your embouchure if you play an instrument. And even in those fields, it's generally accepted that over time people will end up with very specialized setups that are very consistent and refined and that remain constant for years and years. Only in the software industry would someone tell me that my professional tools should change because change is inherently good. Only in commercial software would an elegant, consistent interface like Markdown that allowed me to build up decades of muscle memory until my computer was an extension of my fingers and I didn't need to think about the way I typed -- only in software would that be considered a bad thing.

Swizec 7y ago
> Only in the software industry would someone tell me that my professional tools should change because change is inherently good Translation: "we're paying all these engineers and product managers and they need something to do"
- mlthoughts2018 7y ago
  And they are all scrambling to data mine every arbitrary slice of the data to make it look like the musical chairs of features somehow drove conversion and the lack of bottom line fiscal performance is some other department’s fault for handwavy reasons.
- cookiecaper 7y ago
  This is honestly a major contributor to the badness of software in general. Ideal software would be continually fine-tuned and shrunk -- there'd be no bi-annual massive redesign, no change for change's sake alone. Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points, a well-run project would make something work well and then they'd leave well enough alone, focusing only on bugfixes, performance, and other "boring" projects that don't make for big press releases. Changes to working products should be as surgical and minimal as possible. A good compensation structure that would prioritize stability and consistency would pay an ongoing royalty to the relevant technical people based on the product's performance, uptime, and minimal crash/bug occurrence. "Hours worked" would be minimally relevant. One wonders if so many people would be so desperate to desecrate their production infrastructure if a high-quality work product and compensation were actually correlated. But because we can't break out of the assembly-line 40-hours-per-week mentality, we pay developers as if they're line workers, and there's always got to be something on the line to keep those worker bees buzzing, regardless of the aggregate negative impact of constant uncoordinated meddling in complex systems.
  - Kalium 7y ago
    > Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points This hits painfully home for me. I learned a few weeks ago that some of my coworkers did something akin to this. They were working on what was frankly a mostly-silly project to preserve the relevance of increasingly irrelevant internal tools. Once they had produced something working, they stopped. Then they re-implemented the whole thing in Rust. Which few in the company know or use. There are no clear benefits to this except exciting resume points for the developer in question.
- jodrellblank 7y ago
  In 1995, Niklaus Wirth wrote "A Plea for Lean Software" - abstract "Software's girth has surpassed its functionality [..] The paper discusses some causes of "fat software" and considers the Oberon system whose primary goal was to show that software can be developed with a fraction of the memory capacity and processor power usually required, without sacrificing flexibility, functionality, or user convenience" That was discussed on HN in 2014[1] and right in the top comments is "I think one factor that leads to bloated, ruined software was missed... I don't know how common it is overall, but I have personally seen it ruin several very good products. And that is the simple fact that employers want their employees to remain busy. If a piece of software reaches a point of exceptional quality - the developers working on it still have to fill 40 (likely more) hours a week to appease bosses. And so they do the only thing available - they ruin the product." [1] https://news.ycombinator.com/item?id=8301511 https://news.ycombinator.com/item?id=8301511
- nwallin 7y ago
  The crazy thing to me is that if they rolled out a native desktop app that was maybe a little bit lacking in features and used ~20MB RAM and had this particular misfeature in it and called it beta, people would applaud them for it, especially here on HN. Instead they spent actual time, effort, and money making their product worse. My company has certain deficiencies, but one of our core principals is that we'll never break a workflow, even if the workflow is dumb, even if the "feature" is actually a bug that an enterprising user abused in a way we didn't anticipate. The bad news is that we're saddled with a ton of legacy crap that can't be rewritten. The good news is that we've grown into one of those behemoths that dominates a niche specialized industry and won't be unseated by a product that is only, say, twice as good as ours. It's not as fun as iterating fast and breaking things, but the low stress is nice.
  - journalctl 7y ago
    After this change I really want to develop a native chat application on Windows and OS X. I think it’s almost to the point where someone who did they could make a killing.
ben_jones 7y ago
Your comment is a punch to the gut for me, I've been developing an internal CRM for two years that embodies many of the philosophies you describe. But while it is somewhat depressing, I'm left with questions about how bad it really is. First, is it possible to develop software without inconveniencing business users with temporary (let's assume the ultimate products are better then the linux/vim/emacs they are superseding) regressions and inconveniences? And what is the cost in terms of time to route around such pitfalls? Would we still be able to have startups at all if products required thousands of hours of QA or perfect test suites in order to launch? Second, if we were to set a hard rule 20 years ago that all software was to avoid this phenomenon during its development, what valuable tools and services would never have been developed at all? Would we still have Twitter? Reddit? Steam? Whatsapp? I don't have to dig far into the history of any of those tools to find near revolutions by their userbases over braindead UI or adversarial practices in the name of "vision". I don't know, these are open questions. I just think avoiding all such frustrations you mentioned is wishful thinking and at some point it is just part of the process of experimentation and iteration. Or perhaps this process is entirely different in a small corp. versus a big corp. environment.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
- Kalium 7y ago
  > Would we still have Twitter? Reddit? Steam? Whatsapp? How many of those broke old workflows to introduce new ones with no clear benefits? But that's not the point. We're not talking here about broad services like Reddit, Twitter, or Steam. We're talking about something more akin to a libary. You shouldn't break interfaces in a library without a strong, compelling reason. Do things need to change eventually? Absolutely. Do they need to change today, because someone decided that the old workflows they don't like need to break for everyone? Maybe not. There's perhaps some room between the two. It's been my experience that business software often represents a deep investment in a given workflow. Sometimes to the point where businesses are willing to spend a great deal of money to preserve those workflows and integrate new things into them - MuleSoft springs to mind. Which is not to say that you're wrong. It's absolutely possible to develop new, improved software that's better in critical ways. Sometimes people and businesses are willing to put up with temporary regressions and inconveniences to gain substantial improvements. To use the above comparison, I've seen artists invest the time in learning how to draw all over again in order to jump from paper to digital. What Slack has done is take away what was a perfectly functional workflow for many people. This doesn't look like a temporary regression or inconvenience. This looks like a permanent, hard break without substantial obvious benefits for people who used the old workflow. Communicating with users in a way that telegraphs very clearly that Slack doesn't care at all is just gilding the lily.
swader999 7y ago
Equipment is critical in pro sports, especially the more technical ones too.
- caro_douglos 7y ago
  This feels like someone changed the rules to the pay per view bout but didn’t let the fans know.
spenvo 7y ago
Another thing in Slack that has annoyingly changed (without an option to toggle off) is: its "Drafts" feature - where leaving a channel with an unfinished message means that the channel itself gets moved to the top of the left sidebar. This completely breaks my flow, because 1.) you can no longer use up/down hotkeys to reliably go between specific channels, and 2.) I frequently have to do a double take and ask, "where did that channel go?" - especially if you Star specific DM channels, because those go under the drafts section but above the rest of the channels, meaning the Drafts section is out of view most of the time. Long ago I created a Chrome extension that reordered things nicely, but their CSS changes frequently which made it a maintenance hassle, and I read on HN another dev saying doing so is against their terms of service anyway. Not a fan of that anti-tinkering attitude. SLACK: don't make dramatic changes to a user's workflow without giving a simple toggle to preserve old behavior. I get it, most users probably love this feature. My wife does, for example, and she works at a big organization, which has different needs from my workplace. But even if dramatic changes to product are approved of by 75% of users, every time you do so, you create whiplash for the other 25%, and prevent many from ever loving your product. Rinse and repeat that whiplash too many times and product design rants on HN with 600+ upvotes will be a regular occurrence...
- jmccaf 7y ago
  I use Slack very often, and I also get annoyed that Drafts features often tugs a frequently-used channel to a different spot in sidebar. "Where did that channel go?"
  - ioquatix 7y ago
    +1
- markdog12 7y ago
  First time that happened I had no idea where it went. Still don't and it's happened a few times. They killed my flow. I hate this "feature".
- libraryatnight 7y ago
  I am so glad you said this! It drives me mad. I think of the lists of users/channels in slack alphabetically so even now that I'm aware of the "drafts" change I still go through this shock every.damn.time.
Const-me 7y ago
> like Markdown that allowed me to build up decades of muscle memory Speaking of muscle memory, I still remember these and  — from the time when most web apps understood HTML. Too bad they stopped…
kelseydh 7y ago
If we embraced this philosophy none of us would be typing quickly on touch screen phones. Steve Jobs knew it beat a physical keyboard, and when pressed by people who complained about the new iPhone's touchscreen keyboard, he grinned and said "You'll get used to it." And oh boy, did they ever.
- _wolfie_ 7y ago
  And I still didn't, keep using physical keyboard and believe it's superior. Luckilly there still are phones with full-qwerty keyboards out there.
- otabdeveloper4 7y ago
  > And oh boy, did they ever. No, they didn't. They just stopped typing. Hence, bullshit UI's like Instagram. > Steve Jobs knew it beat a physical keyboard Yes, if by 'beat' you mean 'made it too expensive for general use'. But in general it was a huge blow to usability, productivity and general global intelligence.
- ajscanlan 7y ago
  > And oh boy, did they ever. I cannot wait until the MBP 2025 with the whole keyboard replaced by the touchbar.. Who needs tactile feedback?
- danShumway 7y ago
  But to that point, how many professional transcriptionists or programmers are using a touchscreen keyboard to do professional work now? Have we all switched over to touchscreen keyboards on our laptops yet? Your mistake here is confusing a consumer device with something designed for a professional workflow. Touch screen keyboards are, objectively, not faster to type on than a physical QWERTY keyboard. It's like arguing that because my mom got used to a using a cellphone for photography that physical lenses are obsolete. Again, this is (in my mind) something that mostly only happens in the software industry. A professional racer drives with a manual transmission. When automatic transmissions came out, nobody argued that professional racers were holding back the auto-industry. Meanwhile in the software industry, mention that your workflow benefits from corded headphones, and suddenly you're jeopardizing the future of progress.

Swizec 7y ago

> Only in the software industry would someone tell me that my professional tools should change because change is inherently good Translation: "we're paying all these engineers and product managers and they need something to do"

mlthoughts2018 7y ago
And they are all scrambling to data mine every arbitrary slice of the data to make it look like the musical chairs of features somehow drove conversion and the lack of bottom line fiscal performance is some other department’s fault for handwavy reasons.
cookiecaper 7y ago
This is honestly a major contributor to the badness of software in general. Ideal software would be continually fine-tuned and shrunk -- there'd be no bi-annual massive redesign, no change for change's sake alone. Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points, a well-run project would make something work well and then they'd leave well enough alone, focusing only on bugfixes, performance, and other "boring" projects that don't make for big press releases. Changes to working products should be as surgical and minimal as possible. A good compensation structure that would prioritize stability and consistency would pay an ongoing royalty to the relevant technical people based on the product's performance, uptime, and minimal crash/bug occurrence. "Hours worked" would be minimally relevant. One wonders if so many people would be so desperate to desecrate their production infrastructure if a high-quality work product and compensation were actually correlated. But because we can't break out of the assembly-line 40-hours-per-week mentality, we pay developers as if they're line workers, and there's always got to be something on the line to keep those worker bees buzzing, regardless of the aggregate negative impact of constant uncoordinated meddling in complex systems.
- Kalium 7y ago
  > Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points This hits painfully home for me. I learned a few weeks ago that some of my coworkers did something akin to this. They were working on what was frankly a mostly-silly project to preserve the relevance of increasingly irrelevant internal tools. Once they had produced something working, they stopped. Then they re-implemented the whole thing in Rust. Which few in the company know or use. There are no clear benefits to this except exciting resume points for the developer in question.
jodrellblank 7y ago
In 1995, Niklaus Wirth wrote "A Plea for Lean Software" - abstract "Software's girth has surpassed its functionality [..] The paper discusses some causes of "fat software" and considers the Oberon system whose primary goal was to show that software can be developed with a fraction of the memory capacity and processor power usually required, without sacrificing flexibility, functionality, or user convenience" That was discussed on HN in 2014[1] and right in the top comments is "I think one factor that leads to bloated, ruined software was missed... I don't know how common it is overall, but I have personally seen it ruin several very good products. And that is the simple fact that employers want their employees to remain busy. If a piece of software reaches a point of exceptional quality - the developers working on it still have to fill 40 (likely more) hours a week to appease bosses. And so they do the only thing available - they ruin the product." [1] https://news.ycombinator.com/item?id=8301511 https://news.ycombinator.com/item?id=8301511
nwallin 7y ago
The crazy thing to me is that if they rolled out a native desktop app that was maybe a little bit lacking in features and used ~20MB RAM and had this particular misfeature in it and called it beta, people would applaud them for it, especially here on HN. Instead they spent actual time, effort, and money making their product worse. My company has certain deficiencies, but one of our core principals is that we'll never break a workflow, even if the workflow is dumb, even if the "feature" is actually a bug that an enterprising user abused in a way we didn't anticipate. The bad news is that we're saddled with a ton of legacy crap that can't be rewritten. The good news is that we've grown into one of those behemoths that dominates a niche specialized industry and won't be unseated by a product that is only, say, twice as good as ours. It's not as fun as iterating fast and breaking things, but the low stress is nice.
- journalctl 7y ago
  After this change I really want to develop a native chat application on Windows and OS X. I think it’s almost to the point where someone who did they could make a killing.

ben_jones 7y ago

Your comment is a punch to the gut for me, I've been developing an internal CRM for two years that embodies many of the philosophies you describe. But while it is somewhat depressing, I'm left with questions about how bad it really is. First, is it possible to develop software without inconveniencing business users with temporary (let's assume the ultimate products are better then the linux/vim/emacs they are superseding) regressions and inconveniences? And what is the cost in terms of time to route around such pitfalls? Would we still be able to have startups at all if products required thousands of hours of QA or perfect test suites in order to launch? Second, if we were to set a hard rule 20 years ago that all software was to avoid this phenomenon during its development, what valuable tools and services would never have been developed at all? Would we still have Twitter? Reddit? Steam? Whatsapp? I don't have to dig far into the history of any of those tools to find near revolutions by their userbases over braindead UI or adversarial practices in the name of "vision". I don't know, these are open questions. I just think avoiding all such frustrations you mentioned is wishful thinking and at some point it is just part of the process of experimentation and iteration. Or perhaps this process is entirely different in a small corp. versus a big corp. environment.

deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
Kalium 7y ago
> Would we still have Twitter? Reddit? Steam? Whatsapp? How many of those broke old workflows to introduce new ones with no clear benefits? But that's not the point. We're not talking here about broad services like Reddit, Twitter, or Steam. We're talking about something more akin to a libary. You shouldn't break interfaces in a library without a strong, compelling reason. Do things need to change eventually? Absolutely. Do they need to change today, because someone decided that the old workflows they don't like need to break for everyone? Maybe not. There's perhaps some room between the two. It's been my experience that business software often represents a deep investment in a given workflow. Sometimes to the point where businesses are willing to spend a great deal of money to preserve those workflows and integrate new things into them - MuleSoft springs to mind. Which is not to say that you're wrong. It's absolutely possible to develop new, improved software that's better in critical ways. Sometimes people and businesses are willing to put up with temporary regressions and inconveniences to gain substantial improvements. To use the above comparison, I've seen artists invest the time in learning how to draw all over again in order to jump from paper to digital. What Slack has done is take away what was a perfectly functional workflow for many people. This doesn't look like a temporary regression or inconvenience. This looks like a permanent, hard break without substantial obvious benefits for people who used the old workflow. Communicating with users in a way that telegraphs very clearly that Slack doesn't care at all is just gilding the lily.

swader999 7y ago

Equipment is critical in pro sports, especially the more technical ones too.

caro_douglos 7y ago
This feels like someone changed the rules to the pay per view bout but didn’t let the fans know.

spenvo 7y ago

Another thing in Slack that has annoyingly changed (without an option to toggle off) is: its "Drafts" feature - where leaving a channel with an unfinished message means that the channel itself gets moved to the top of the left sidebar. This completely breaks my flow, because 1.) you can no longer use up/down hotkeys to reliably go between specific channels, and 2.) I frequently have to do a double take and ask, "where did that channel go?" - especially if you Star specific DM channels, because those go under the drafts section but above the rest of the channels, meaning the Drafts section is out of view most of the time. Long ago I created a Chrome extension that reordered things nicely, but their CSS changes frequently which made it a maintenance hassle, and I read on HN another dev saying doing so is against their terms of service anyway. Not a fan of that anti-tinkering attitude. SLACK: don't make dramatic changes to a user's workflow without giving a simple toggle to preserve old behavior. I get it, most users probably love this feature. My wife does, for example, and she works at a big organization, which has different needs from my workplace. But even if dramatic changes to product are approved of by 75% of users, every time you do so, you create whiplash for the other 25%, and prevent many from ever loving your product. Rinse and repeat that whiplash too many times and product design rants on HN with 600+ upvotes will be a regular occurrence...

jmccaf 7y ago
I use Slack very often, and I also get annoyed that Drafts features often tugs a frequently-used channel to a different spot in sidebar. "Where did that channel go?"
- ioquatix 7y ago
  +1
markdog12 7y ago
First time that happened I had no idea where it went. Still don't and it's happened a few times. They killed my flow. I hate this "feature".
libraryatnight 7y ago
I am so glad you said this! It drives me mad. I think of the lists of users/channels in slack alphabetically so even now that I'm aware of the "drafts" change I still go through this shock every.damn.time.

Const-me 7y ago

> like Markdown that allowed me to build up decades of muscle memory Speaking of muscle memory, I still remember these and  — from the time when most web apps understood HTML. Too bad they stopped…

kelseydh 7y ago

If we embraced this philosophy none of us would be typing quickly on touch screen phones. Steve Jobs knew it beat a physical keyboard, and when pressed by people who complained about the new iPhone's touchscreen keyboard, he grinned and said "You'll get used to it." And oh boy, did they ever.

_wolfie_ 7y ago
And I still didn't, keep using physical keyboard and believe it's superior. Luckilly there still are phones with full-qwerty keyboards out there.
otabdeveloper4 7y ago
> And oh boy, did they ever. No, they didn't. They just stopped typing. Hence, bullshit UI's like Instagram. > Steve Jobs knew it beat a physical keyboard Yes, if by 'beat' you mean 'made it too expensive for general use'. But in general it was a huge blow to usability, productivity and general global intelligence.
ajscanlan 7y ago
> And oh boy, did they ever. I cannot wait until the MBP 2025 with the whole keyboard replaced by the touchbar.. Who needs tactile feedback?
danShumway 7y ago
But to that point, how many professional transcriptionists or programmers are using a touchscreen keyboard to do professional work now? Have we all switched over to touchscreen keyboards on our laptops yet? Your mistake here is confusing a consumer device with something designed for a professional workflow. Touch screen keyboards are, objectively, not faster to type on than a physical QWERTY keyboard. It's like arguing that because my mom got used to a using a cellphone for photography that physical lenses are obsolete. Again, this is (in my mind) something that mostly only happens in the software industry. A professional racer drives with a manual transmission. When automatic transmissions came out, nobody argued that professional racers were holding back the auto-industry. Meanwhile in the software industry, mention that your workflow benefits from corded headphones, and suddenly you're jeopardizing the future of progress.