Reminds me of the Info-Dialogue-Box I removed from an application last year. This saved perhaps 1 second to click it away each time it was shown. I estimated that it shows up about 3,000 times a month in the company. This means 36,000 times a year, or 180,000 times in 5 years, that is equivalent to 50 hours. -- It took me perhaps 10 minutes to remove it, including tests. With average labour costs of 50 Euros per hours for the users, the company is going to save about 2,500 Euros over a period of 5 years.
Possibly related, the other day I removed a few dozen iOS simulators, but each one triggered a confirmation popup (they stacked, lol). But I noticed that with this version of MacOS, each one animates away, and the animation has to be finished before the next one disappears. Disabling animations / reducing motion makes these dialog appear / disappear animations go away and the interactions a lot snappier.
I wanted to reduce the animation time of switching screens / workspaces as well but reducing motion just changes it from a swipe to a fade animation, which wasn't any better for me.
> A company of 100 engineers should probably have 10-20% of the team allocated to just internal tools and making things go faster.
But beware of Jevons paradox.
Say that eg. a software project has 10 developers, and each build takes ~15 minutes. Most developers would take at least some care to check their patches, understand how they work etc, before submitting. And then discuss follow-on steps with their team over a coffee.
Now imagine near-instant builds. A developer could copy-paste a fix & hit "submit", see "oh that doesn't work, let's try something else", and repeat. You'll agree that probably wouldn't help to improve the codebase quality. It would just increase the # of non-functional patches that can be tested & rejected in a given time span.
One of my first visible actions when working at a new company is to recommend the search software Voidtools Everything, and to set a 30 minute meeting to teach people how to use it.
For the next 6-12 months I get so much positive feedback about all the time that is saved while navigating the network drives.
I joke that the efficiency gains from its introduction organization-wide alone pay my salary!
The conclusion of the article is "yes", because you usually end up saving more time in the long run than you think.
But there's an even better reason. Consistency, encapsulation of process, and a form of self documentation. This is the real goal - the time savings are a bonus.
Reminds me of the Info-Dialogue-Box I removed from an application last year. This saved perhaps 1 second to click it away each time it was shown. I estimated that it shows up about 3,000 times a month in the company. This means 36,000 times a year, or 180,000 times in 5 years, that is equivalent to 50 hours. -- It took me perhaps 10 minutes to remove it, including tests. With average labour costs of 50 Euros per hours for the users, the company is going to save about 2,500 Euros over a period of 5 years.
Possibly related, the other day I removed a few dozen iOS simulators, but each one triggered a confirmation popup (they stacked, lol). But I noticed that with this version of MacOS, each one animates away, and the animation has to be finished before the next one disappears. Disabling animations / reducing motion makes these dialog appear / disappear animations go away and the interactions a lot snappier.
I wanted to reduce the animation time of switching screens / workspaces as well but reducing motion just changes it from a swipe to a fade animation, which wasn't any better for me.
> A company of 100 engineers should probably have 10-20% of the team allocated to just internal tools and making things go faster.
But beware of Jevons paradox.
Say that eg. a software project has 10 developers, and each build takes ~15 minutes. Most developers would take at least some care to check their patches, understand how they work etc, before submitting. And then discuss follow-on steps with their team over a coffee.
Now imagine near-instant builds. A developer could copy-paste a fix & hit "submit", see "oh that doesn't work, let's try something else", and repeat. You'll agree that probably wouldn't help to improve the codebase quality. It would just increase the # of non-functional patches that can be tested & rejected in a given time span.
In other words: be careful what you wish for.
One of my first visible actions when working at a new company is to recommend the search software Voidtools Everything, and to set a 30 minute meeting to teach people how to use it.
For the next 6-12 months I get so much positive feedback about all the time that is saved while navigating the network drives.
I joke that the efficiency gains from its introduction organization-wide alone pay my salary!
Can't be emphasized enough how useful this tool is and how insane it is that it is not native to Windows (even after 40 years).
I wish Everything that head easier search bookmarking and/or tabbed interface.
The conclusion of the article is "yes", because you usually end up saving more time in the long run than you think.
But there's an even better reason. Consistency, encapsulation of process, and a form of self documentation. This is the real goal - the time savings are a bonus.