Enterprise software is not going to ever be fixed until people start to realize that the people that actually do the work need to be heavily involved in the design process and the developers need to be embedded in the actual underlying job more thoroughly. The idea that some developers and process people can make high quality insurance claims software for instance, without actually knowing who’s to handle an insurance claim is preposterous to me.
I have to use JIRA at work, and it's absolutely awful. Every action takes up to a couple seconds to execute, many tasks have no way to be automated or done in batches, and some seemingly simple actions require jumping through several unintuitive menus to complete.
To me it's clear that the people making this software almost certainly can't be the ones using it, and the people generally choosing and paying for it probably are also not the ones using it heavily day to day. Otherwise there's no way this level of performance would be tolerated.
Definitely going the GitHub route next time time I'm moved onto a new project. The past two have used Jira and Trello and both are just a continuous source of frustration for me.
So I think Trello is great for some things and on a smaller board with a handful of tickets it's one of the better tools around.
There are several 'weak' bits of the UI though, like not being able to open a ticket in its own window, having a clunky search and an excessive amount of horizontal scrolling on larger boards.
I've got to say that this is a problem with relying on the UI itself. When working with a development team I always provide as many options as possible to automate that worklflow.
This might take the form of integrating bitbucket with Jira such that you can assign a commit to a ticket or advance or close a ticket.
A few years ago I was looking at the jira API and managed to dig into the documentation. The result was a small gist which contains some of the harder to figure out actions. Including creating a new ticket.
It can be easy to create tickets in Jira using company-managed projects. The problem is the people who set up Jira see all of these knobs and buttons and feel like they need to use them. Creating tickets in my department require two things: ticket type, summary. We use procedures, not software to enforce the rules.
Once I finish our migration to Jira, other departments will have different screens that require a few more fields like description. My goal is to keep these to an absolute minimum.
Configuring this stuff is a massive pain in the ass but the day to day use is manageable by creating custom boards and saved searches. A some training and documenting for my team takes care of the rest.
For my coworkers, it’s no more painful than the workarounds needed to make a “simpler” system work. GitLab and Github do fuck-all to support our workflow. Jira allows me to tailor it so both my team and management can understand what’s happening.
Ugh, Jira is just the worst. I’ve used a lot of software but Jira’s slowness and lag made it the one I dreaded most. Every - single - thing - needed - three - to - twenty - seconds.
One of my friends works at Atlassian (not on JIRA). Apparently they do use JIRA there. Presumably things which are not performance are prioritised higher.
Agree completely. When you prioritize the requirements of infinite shareholder growth over people who actually make the product and do the processes, you’re not optimizing for the best product or processes.
European countries are at least familiar with the idea of codetermination - having workers vote for board representation. Sweden, the Netherlands, and Germany practice some form of this to different degrees. In the US (and especially in the tech world) we are allergic to the idea that anyone besides the bagholder should have a role in decisionmaking.
Making a new system recently I did exactly this. I basically joined the group as a low-level doc-pushing twerp and worked through everyone's jobs. Then we started sketching out the system, having seen the pinch points and dead ends. Unfortunately, leadership later threw out all our design decisions, because they had a "Perfect Product Architecture" they were trying to enforce at the time.
I agree with this article that the UX of the software I have to use for work is terrible, and it's very frustrating and demotivating. But their proposed solution at the end- internally developed software, seems to be the worst offender. The worst software I have to use tends to be internally developed, poorly documented, supported, and designed copies of widely used software like bug trackers, project management tools, CI systems, etc. The justification for reimplementing these internally is often security, scalability, or integration requirements though, not UX.
I agree while disagreeing, it depends greatly, some anecdata.
In the old days of DOS, circa 1992, I worked in a construction company, a program to make public works accounting was bought (at a very dear price BTW).
It soon became evident that the programmers had (maybe) read a couple of (theoretical/outdated) books on that particular type of accounting whilst they never spoke with an experienced accountant, let alone ever done any accounting themselves.
When the program crashed - actually because of an overflow when we reached on a site works for more than Lire 9,999,999,999 - and some two years of accounting had to be recreated manually (imagine 12-14 people scribbling day and night for one week) because we needed to recreate on paper the progress report to get paid as soon as possible (the software company people were on holidays for the month), we decided to become "independent".
We found a freelance programmer that started working side by side with one of our most expert accountants, and he created (if I recall correctly in three months time or so) a simple/rough program (mind you those were dbase III/Clipper days, no program was actually "refined" from a UX viewpoint) that simply worked.
We kept using it until the late '90's switching to a (hardly better) commercial program in Windows 2000 times.
The original clipper program had its own little quirks and you needed to learn a number of combo-keys to work with it, but once got the hang of it, it was much faster to use than any windows based program.
Same thing happened to me with a hotel managing software, the old software had been originally written by someone who had a cash register maintenance business and actually knew how the actual operations are carried in practice, when it was needed to switch to more modern software (mainly because of some changes in the Laws) I tested some 5-6 of the most common professional (commercial) softwares around, and while 3-4 of them were simply jokes, of the 2 remaining we didn't actually choose the "better" one, but rather the "less worse" one.
And still a number of "common enough" operations are incredibly complicated/take too much time when compared to what the old one could do.
I believe there is nowadays this "detachment" between programmers and actual (expert) users that greatly impairs the usability of software.
> I believe there is nowadays this "detachment" between programmers and actual (expert) users that greatly impairs the usability of software.
I don't think this is new. I think it's a long standing issue and a huge issue. I worked on home appraisal software and I regret not learning more about the job up front. After like 2 years of developing the app and getting approximately nowhere in the market, the software team actually went on an appraisal. It was eye-opening.
I've also seen the "expert in the room" hired twice and neither time worked (small sample size). I think you need more info in the brain of the dev team, and to have solutions bounced off a bunch of users. One expert ends up as kind of a silo.
Sure, there are several issues in the process (hence it is so difficult) the expert(s) must be actually expert (not that easy[1]) and the software house programmer(s) and manager(s) need to be open-minded and willing not to take the (usual) shortcuts.
[1] this is a pet peeve of mine, but at my age I can see the difference between seniority (common enough) and experience (quite rare).
> it was much faster to use than any windows based program.
In retail and later as a software engineer I've seen that expert systems need keyboard shortcuts. Ideally the fewest possible for the hottest paths. Yet for onboarding you need the most obvious and relatable UI. Windows apps can be both if well designed. Console and terminal based apps generally cannot pack as much into the UI and most folks don't know them before joining.
I was so impressed the first time I saw a relative use their government mandated accounting software for DOS. That woman was going through forms faster than me doing mortal kombat 3 combos. Not sure that would be possible these days with remote databases and such.
As I see it, the paradigm that Windows (actually the programmers working on windows programs) broke was the centrality of keyboard.
In windows (or more generally GUI) you usually need to constantly move your hands from keyboard to mouse (to click a button and "go ahead") and then back to keyboard to type soimething, then mouse again, etc.
I believe this is only due because of the choices of the programmers that used some "default" modes.
To give you an example the good ol'Dos program I was talking about used Enter to confirm data typed in a field AND move to next field, to go back to a previous field it was Ctrl+Enter, then you had to press F8 to confirm the whole form and exit to the main menu or F10 to confirm the whole form AND go to the next form of the same type.
When you got to a field like "state" or "country", that need to match an existing database, windows programs mostly have a drop down list (and you need the mouse to open the drop down list and scroll down until you find the one you want), the old program allowed to either enter the two-three letter country id (like IT for Italy, DE for Deutschland, etc.) OR to type the first few letters and then autocomplete with - if I recall correctly - F4.
Dates could be typed without separators, i.e. 22082021 and when you pressed enter the field would be automagically formatted to 22/08/2021, currently in lots of programs (or web sites) you have to click and then a calendar pops up, and you have to click three times for day/month/year, some "smarter" ones have a button for "today" but that, for a field like "date of birth" makes no sense whatever.
This latter is a pet-peeve of mine but 3/4 to 7/8 of all web shops, including those that are clearly national only have a drop down list for countries that invariably starts from Afghanistan, which possibly represents 0,0000000001 % of the orders.
Then you have "tabs", on a huge screen 1024*768 or higher resolution the actual form is a tiny window, and you input name/surname/birthday/address, etc. on it, then you have to switch (why?) to another tab to enter (say) fiscal data and to yet another one to add notes.
Of course there are also better UI's, but the large majority is as I described above.
Taking the time to develop an application that is usable with a kbd/mouse is a tough sell, even when not dealing with mobile apps. Some people want to do it, but does it bring more money? No... so we, don't do it unless someone does it on their own time.
That's interesting. I guess the problem software I'm thinking of is all written by software engineers for software engineers, so the "detachment" issue isn't as severe. There is some, since we work in different parts of the business. The main issues I see are that 1) a small in-house team working on internal tools doesn't have much hope of putting in the time and resources of a whole company developing the same thing for public customers 2) once a company funds an internal tool, there is usually a lot of pressure (or even a mandate) to use it, even if there are better choices 3) the in-house team is also constrained to use our other in-house tools as dependencies, whether they're better or worse than other choices.
I can see the advantage to developing something in-house if there aren't options that meet some special need, I just personally haven't seen it work out much. Maybe because of the size of companies I've worked at. I've definitely written helpful software for myself and my own team.
It might depend on the internal talent, but, ERP vendors are always going to be incentivised to deliver “just good enough” software and then sit back and take in the cash.. so I’d think with an internal team you _may_ have the opportunity to do better
I spent 5 hours doing a 15 minute task this week. The program kept crashing, then you have to wait for five minutes since the program runs a net liscence that needs to time out before you can restart.
I've sometimes wondered why it seems companies aren't measuring time wasted by slow applications.
I can't count the number of times I've called customer service and have to wait 2-3 minutes for the agent to bring up some screen as they apologize and explain "our systems are really slow". It regularly takes up a majority of the call's time.
Back in the early 1900's, time and motion studies [1] in factories were all the rage. And today Amazon certainly optimizes for the actions warehouse employees are required to do.
But when it comes to the actions people do with computers, I've never once seen a company actually measure wasted time waiting on slow applications. It seems like such an obvious thing to try to optimize. And it's not like it requires constant surveillance or anything -- it's just statistical sampling. Watch 10 randomly selected employees for two hours each or something, with their consent.
In many cases "good UX" is impossible to measure in any conventional sense. But when it comes to repeatable enterprise tasks, the time aspect actually can be measured.
Does anybody know why companies don't? It feels like such low-hanging fruit.
> I've called customer service and have to wait 2-3 minutes for the agent to bring up some screen as they apologize and explain "our systems are really slow"
I have a friend who works in a call center. They work 10 hour days with no breaks between calls (the queue is often 40-50 people deep). (They do get the federally-mandated breaks of course.) "Our systems are really slow" is 100% true, but is also probably a welcome break for the agent. So if you are the clever software engineer that goes in and removes the sleep(180s), that's probably great for a few hours until all the call center agents burn out and leave early and use their spare time to start organizing a union. (Of course, if you save 2 minutes a call with software, you can just give people a mandatory 1 minute break between calls and come out ahead -- a true win/win. But that would require that the software team and the call center management team coordinate, and I don't think that's ever happened once in the history of large companies. You'd be the first!)
Perhaps I’m totally going Euro but shouldn’t the MBA in charge at least try to measure employee happiness, churn
and absence to try and measure if the work is fulfilling? I work at a large listed insurer and I know nobody shits on the hard work customer facing colleagues do. It’s hard work, with often old IT and usually customers outside of the fast track that have unique needs. Our senior
management is motivated to help say once a year to keep a feeling for both customer and colleagues etc.
I would split your point in two dimensions: 1. Software should support efficiency and speed. (We often fail at that.) 2. Tough jobs exist and it’s up to the employer to make them worthwhile and at the least prevent burn-out.
I've skimmed a couple of sections. There are a couple which look at workplace issues (career & self-improvement, workfroce management). Nothing jumps out immediately, but there might be some hints.
Note that what you find in articles and practices on the ground ... may differ.
Vendors advertising workforce-related systems and services (especially monitoring, tracking, recruiting, etc.), or legal / compliance organisations, could also give some possible insights.
Overall, it's a low-wage, low-skill, but also low-hazard environment (no dangerous equipment, encounters, etc.). Much of it is outsourced to low-cost regions with many English speakers (Philippines, India, Mexican border towns, Florida, etc.). Alternative employment may be scarce, unemployment high.
Change any of those dimensions and you might see conditions improve.
In contrast, look at AutoCad or Photoshop, and ArcGis. Mega complex ui's, what they do is more like programming than office productivity. So user workflow is going to be more difficult.
I've worked on in a large bank doing sales with slow IT systems, (The Mainframe was awesome quick though, shout out to black screens!). The bank coached staff to use there tools in an order and structure their conversations so they'd have buffer for information and systems to be there when needed.
Warehouse work is very repeatable compared to most work with a computer.
I used to joke "AutoCAD is an 800lb angry gorilla sitting between you and your work."
Then I met a UI researcher, hired by Army Corps of Engr to explain the missing productivity, who went way past time & motion to strategies. The interplay between tools and techniques, influencing how people organize their tasks. Matrices to highlight weird noun (line, circle, text) and verb (copy, move, delete) interactions. In other words, he showed how strategies from manually drafting did not translate to CAD and proposed new strategies (metaphors) and training appropriate for the new medium. Then validated his ideas with usability testing. Brilliant stuff. Like facepalm obvious once you see it.
Crickets.
Both Autodesk and Bentley Systems were hostile to user centric design based on real world data and lived experiences. The geeks and sales pukes who had never designed or drafted knew what designers and drafters needed, so piss off.
Besides, they're printing money, validating their efforts. And you aren't. So piss off.
Belated reply, because I like your posts, and I don't want to be argumentative with you. :)
My mentor at that time was an AutoCAD dealer. He (eventually) explained the value added reseller racket to me. Very similar to franchising.
Autodesk and others sloughed off most marketing, sales, inventory, shipping, and tech support onto their dealers. Their reasoning, IIRC, was that while dev cost 7% of revenue, those other activities cost 30%. Why not get rubes to cover that overhead?
Further, turnover in the dealer channel was about 1/3 per year. A typical dealer would refinance their house (or whatever) for a few $100k. Burn thru it trying to get established. And there'd be 2 more wannabe dealers waiting to replace them.
It was very hard to not sell AutoCAD for a loss.
There were a few tricks to surviving and profiting. Consulting, training, and hardware, of course. The most capable productized their AutoCAD addons. The most successful of those then matured out of dealerships and formed their own VAR rackets.
This was the 1990s. Autodesk is now the Computer Associates of abandonware graphics programs. Some of those legacy apps probably have enterprisey support contracts, so you're probably right about that. At a guess, it's probably part of the subscription models (everyone trying to copy Adobe's success).
Call center metrics are all about average call length. However, the slowness of the software is largely ignored, in my experience. I worked at a call center once where logging in to the network would take approximately fifteen minutes, depending on workstation, before you could actually start working. They just didn't care. At this particular call center, average handle time was expected to be kept under 6 minutes. One day I had a very good average of under 5 minutes per call, and I received a single inbound call that required use of their translation service (which was a number with which you would dial and initiate a three-way call, and that would translate between you and the caller, with all the requisite delay between communications that one would imagine). That call ballooned into a 45-60 minute ordeal that totally screwed my handle time for the day. The shit cherry on top? The next day, I got bitched at because my handle time for the previous day was too high. When I said "well, that one call was a translator and took like an hour" the only response was "your handle time is too high, don't let it happen again". By the time another week had passed, I had already left the position.
Call center jobs are largely exploitative and demeaning. Outsourcing customer service should be illegal, period.
There only two things I remember about my first day at a large telco. The one relevant to this topic was the call centre. I had never seen cubicles in real life before. Looked absolutely horrible even from the outside. What really made an impression on me, though, was the fact that they had this printed owl on the door. Immediately told everything I needed to know about the place
I've become a bit skeptical that the "loading, please wait" delays are real. It seems like they're often used for upselling me to some other product, while I'm just trying to get my current one fixed.
Similar observations could be made about jankiness/glitchiness in software. The amount of time burned on fighting misbehaving software has to astronomical, in some cases eclipsing the productivity brought by the features that dev energy was spent on instead of general stability and quality.
Take Photoshop for instance. Just about anybody who spends even a moderate amount of time in it will tell you that even though it's become more capable in the past 15 years, it's also become a lot more frustrating and bug-ridden. Personally speaking, I would be just as if not more productive using something like Photoshop 7/CS1/CS2 than I would be with Photoshop CC.
I'm reading this comment because I task-switched away from VSCode which is hanging again. Waiting for glitchy software takes you out of the zone and makes it more likely to go to reddit/Twitter/hn and lose a lot more time than the glitch.
In my free time / personal projects, I've slowly been moving towards this mentality as well. Whenever I start some new, long, dreadful task, I always ask myself, "how can I make this as fun as possible", then start creating better and pseudo-GUIs (Trello or Jupyter usually being the first iteration!) to help me get the job done!
A huge factor in moving on from my previous position was that I had to use Salesforce all the time, which has a terribly count clunky and slow UI and half-baked knowledge base and search stuff, ugh.
And also inertia, I found a simple trick that gets me into a quasi-flow state zone, which is telling myself that I will just do it for ten minutes. Then I don't have to analyze and do the inner talking for another ten minutes.
Also, don't try to automate just now, try to do it few times, then write down the steps, and selectively automate them. It's actually a good way to train yourself to live with boredom. We tend to find hyper stimulus, that's how we were wired. And we waste a lot of energy not in doing the chores but worrying about them.
It occurrred to me that someone once said that learning math and other subjects in school is training yourself to do the mental chores. And patience is such a rare thing to have in this constantly attention-grabbing society.
A balance check is important, do give yourself something else to do when you leave the work.
Myself am using a modified version of Pomodoro. With slightly longer work periods but also longer breaks. I tried to hold myself to the official formula but had better results when I adjusted for my current attention span
Internal tools also help get around the "9 babies can't make an engineer in a month" (or whatever it is) problem. Netflix (where I work, listed in the article) is maybe the best example. There's a limit to how many engineers you can have working on Netflix's 1 flagship service (it's a big limit). You can increase that limit by having other engineers come in and build tools for the whole company. I'm also surprised what percentage of engineering teams are directly "developer experience" at big orgs. It's probably < 1% but I think it should be more like 5% (probably an obscenely wrong opinion).
I agree. Developer experience is just user experience for one specific type of user, so we definitely shouldn’t underestimate it.
I’m reminded of an HN discussion from a couple of months ago, where we were talking about writing code for computers to run vs. for developers to read. I did a quick calculation¹ of how much time is wasted by some modern dev tools just by having a few seconds of delay before giving results. Spoiler: It’s crazy how much time we waste that way if millions of developers are using the tool regularly.
If one way to be a 10x developer is to help 9 of your colleagues become 2x developers then someone who creates excellent developer tools might be a 100x developer just within a large organisation, or orders of magnitude more if the tool is released openly. Personally, I’m hoping for someone to write a good, comprehensive standard library for JS/TS data structures and algorithms and convince the major browsers to include it out of the box. I don’t know how to measure the amount of time that could be saved firstly by making it easier for millions of web developers to write good code and secondly by severely cutting back the huge dependency trees that result from the current culture of pulling in tiny dependencies to do tiny jobs all over the place. It must be astronomical.
This is my primary gripe with MS Teams, it might be free with Office 365 or whatever but I’m pretty sure the time lost due to its flakiness and rubbish UX costs more than Slack or similar.
It’s UX is unbearable! Individual functionality is pretty good - teams channels, chat, video, but the UX bringing these things together is total garbage!
Same with Google chat. It is bundled with gsuite so company thinks it is a waste to pay for something property like slack. But Google chat is literally the worst software I've used. Something as simple as search is broken every other week.
Time to boot my laptop and open browser: 5-10 seconds
Time to load and login to slack: 120-180 seconds with about 7 clicks
... sometimes I even have to wait a while for it to catch up with my typing like i'm superman or something. At which point I usually revert to copy and pasting messages from VIM... that's how slow slack is on a 2 year old laptop.
Bad UX absolutely hurts productivity, but the reason I’m not productive is still boredom and short attention span :)
Seriously, when I was more motivated I used to write code in garbage Xcode which was slow and crashed all the time. I just powered through. Now IntelliJ offers crazy code completion and instant refactoring/navigation, but I space out every time I have to wait 5 seconds for the app to build.
I recall another recent story lamenting that software had not produced massive gains in productivity in essentially the 2000s.
Terminal/3270 screens may have been ugly, but they show about the same amount of information as a modern enterprise app does.
The sheer waste of modern CPU speed is why there isn't anything big coming out of the screenpusher labor economics. Why I have screen lag in a modern PC is mystifying. It should basically NEVER happen.
I studied computer science with a minor in psychology. It's long ago, but at that time I some courses on the topic of ergonomic design of UIs. Shortly speaking every UI which stops the user from be interrupted in is workflow by waiting or searching is a microstressing event. (Interruptions are the most important of all stressors when working). Many microstressing events leads to stress and stress leads to bad productivity.
What can I say? The last 10 years UIs went ergonomically from bad to worse.
Loading time of screens are to long nowadays. While loading and rendering the browser typically keeps on moving screen elements around. Each of this movements interrupts the search for the relevant information for the eyes. Each of these movements enforces the eye movements, search for a new object to focus and accomodate its lenses.
Nowadays it is in many application not uncommon to have several of these movements in one loading of a page.(This problem comes is actually somehow connected that HTML is a sessionsless protocoll in connection with modern JS which makes increases loading times. Using microservices quite often lead to bad UI because of the uneven loading times).
Other problems are coming from opting into gimmicks like using "effects" or to scrolling instead of paging. While scrolling and paging is ok of websites (in most cases), in most business application you want to avoid this because it is coming with the same problems as slow loading and moving elements on the screen.
Another set of problems coming form bad choices from UX designers. Look at the example in [1]
- Wasting of precious screen real estate for white space leads to searching for information you need and again: scrolling, eyes movement, accommodation.
- Lack of optical guides like lines. Try to set all cells to white background in excel and start working then you see the effect.
- Lack of contrast: Dark grey text on light grey background (which MS Office does as well in their settings menu [4])
- For design purposes the chosen fonts are much to small to be readable in a convenient way
- Header and actual data (i.e. relevant information) are indistinguishable.
Finding Information in the "basic data" section in [1],[2] is a hide and seek game for the user. Assume you seeing this display 50 times a day during your work. You are guaranteed to come home with a headache
Another example of bad UI are the tiles in W10 start menu [6]. Instead of allowing the eye to scan the entry from top to bottom in one line, the eyes are forced in zig-zag of the tiles and they have transverse a bigger space on the screen because you have much less tiles on the same space as lines is the old menu structure.
Another example what causes stress and frustration with software is when the UI of one software does behave differently the others. Your software should generally be designed as what the user expects. An example of a bad UI for this case is MS-Outlook [3]. Some of the more often used navigation elements (switching between mail and calendar) are moved left bottom corner. This is against user expectation. Microsoft Outlook moves its navigation elements to somewhere where no one else put them. No one would design a car with gas an break pedals exchanged and putting the gear shift in the trunk. Microsoft Outlook does so with its navigation elements.
Another common problem is that to many screens in your application look to much alike. While it is desirable that the screen designs meets expectation, it is important that the user can spot immediately in which screen he is working. When for
Nested menus / hidden functionality is an typical issue in software as well [5]
Flat design is generally a stressor because is lacking optical help.
Google Cloud web UI. Navigating between different products/settings is super slow. I don't understand why it is loading that much. The CLI is good though
It's not just work. Computers have bad UX for everything, and ordinary people don't know that things could be any better. I found this to be an enlightening read: -
Fuck companies that have codebases with long compile times and code in a way that you have to search multiple hoops to get to the actual cod e that matters (modern c++ in case you're wondering)
Iteration times should be one of the major tenets in our programming books other than the stuff they recommend to derisk your software.
Worked on an app for a manufacturing company. Took literally 3 hours to run. Brought it down to under 3 seconds, for the exact same thing. 3 seconds made them very, very, very happy with the UX. At 3 hours run time, it really f-cked up the assembly line, like, a lot.
The speedup happened on the exact same computer - same CPU, same memory, same hard drive. So it had zero to do with hardware, and everything to do with coding. And if you threw faster, better hardware at the problem, it would not change anything for shit.
So never depend on the false hope hardware will solve shitty software design issues. The whole idea that it is cheaper to code fast to get something out fast is bogus. It just takes knowledge on how to do it correctly in the first place. I don't think the coding that I did took any longer than the original coding. The original person just sucked ass.
So, whatever language you code in, you should start watching videos or reading articles on how to maximize your application's speed. It usually is not that difficult, if you spend some time. Most of it you can copy and paste. Do searches on "Top 5 ways to speed up x language". So easy.
That really drilled the lesson home on the importance of the approach to making real fast systems on the design side and not on the hardware side.
Right. I agree. That's why I wrote: " Do searches on "Top 5 ways to speed up x language". So easy."
The thing is that once you learn these techniques, everything that one subsequently writes will automatically incorporate them. Once one knows how, it would be super difficult not to use them on every project. But, yeah, I usually like to read "Top 3 ways of optimizing xyz".
This post was in the back of my mind today when my #1 pet-peeve about Windows reared it's ugly UX right as I was starting to get into a rhythm of productivity.
Focus Stealing
I'm using many apps and portals over the internet on Tuesdays, and I would be so much more productive if I could start something in one app, then leave it to do something else and only return to that app when its done thinking.
If I could run all of my work's accounting apps in Linux, I'd be i3 all day long.
63 comments
[ 0.19 ms ] story [ 739 ms ] threadI have to use JIRA at work, and it's absolutely awful. Every action takes up to a couple seconds to execute, many tasks have no way to be automated or done in batches, and some seemingly simple actions require jumping through several unintuitive menus to complete.
To me it's clear that the people making this software almost certainly can't be the ones using it, and the people generally choosing and paying for it probably are also not the ones using it heavily day to day. Otherwise there's no way this level of performance would be tolerated.
There are several 'weak' bits of the UI though, like not being able to open a ticket in its own window, having a clunky search and an excessive amount of horizontal scrolling on larger boards.
This might take the form of integrating bitbucket with Jira such that you can assign a commit to a ticket or advance or close a ticket.
A few years ago I was looking at the jira API and managed to dig into the documentation. The result was a small gist which contains some of the harder to figure out actions. Including creating a new ticket.
https://gist.github.com/TheMightyLlama/9427202
Once I finish our migration to Jira, other departments will have different screens that require a few more fields like description. My goal is to keep these to an absolute minimum.
Configuring this stuff is a massive pain in the ass but the day to day use is manageable by creating custom boards and saved searches. A some training and documenting for my team takes care of the rest.
For my coworkers, it’s no more painful than the workarounds needed to make a “simpler” system work. GitLab and Github do fuck-all to support our workflow. Jira allows me to tailor it so both my team and management can understand what’s happening.
European countries are at least familiar with the idea of codetermination - having workers vote for board representation. Sweden, the Netherlands, and Germany practice some form of this to different degrees. In the US (and especially in the tech world) we are allergic to the idea that anyone besides the bagholder should have a role in decisionmaking.
In the old days of DOS, circa 1992, I worked in a construction company, a program to make public works accounting was bought (at a very dear price BTW).
It soon became evident that the programmers had (maybe) read a couple of (theoretical/outdated) books on that particular type of accounting whilst they never spoke with an experienced accountant, let alone ever done any accounting themselves.
When the program crashed - actually because of an overflow when we reached on a site works for more than Lire 9,999,999,999 - and some two years of accounting had to be recreated manually (imagine 12-14 people scribbling day and night for one week) because we needed to recreate on paper the progress report to get paid as soon as possible (the software company people were on holidays for the month), we decided to become "independent".
We found a freelance programmer that started working side by side with one of our most expert accountants, and he created (if I recall correctly in three months time or so) a simple/rough program (mind you those were dbase III/Clipper days, no program was actually "refined" from a UX viewpoint) that simply worked.
We kept using it until the late '90's switching to a (hardly better) commercial program in Windows 2000 times.
The original clipper program had its own little quirks and you needed to learn a number of combo-keys to work with it, but once got the hang of it, it was much faster to use than any windows based program.
Same thing happened to me with a hotel managing software, the old software had been originally written by someone who had a cash register maintenance business and actually knew how the actual operations are carried in practice, when it was needed to switch to more modern software (mainly because of some changes in the Laws) I tested some 5-6 of the most common professional (commercial) softwares around, and while 3-4 of them were simply jokes, of the 2 remaining we didn't actually choose the "better" one, but rather the "less worse" one.
And still a number of "common enough" operations are incredibly complicated/take too much time when compared to what the old one could do.
I believe there is nowadays this "detachment" between programmers and actual (expert) users that greatly impairs the usability of software.
I don't think this is new. I think it's a long standing issue and a huge issue. I worked on home appraisal software and I regret not learning more about the job up front. After like 2 years of developing the app and getting approximately nowhere in the market, the software team actually went on an appraisal. It was eye-opening.
I've also seen the "expert in the room" hired twice and neither time worked (small sample size). I think you need more info in the brain of the dev team, and to have solutions bounced off a bunch of users. One expert ends up as kind of a silo.
[1] this is a pet peeve of mine, but at my age I can see the difference between seniority (common enough) and experience (quite rare).
In retail and later as a software engineer I've seen that expert systems need keyboard shortcuts. Ideally the fewest possible for the hottest paths. Yet for onboarding you need the most obvious and relatable UI. Windows apps can be both if well designed. Console and terminal based apps generally cannot pack as much into the UI and most folks don't know them before joining.
In windows (or more generally GUI) you usually need to constantly move your hands from keyboard to mouse (to click a button and "go ahead") and then back to keyboard to type soimething, then mouse again, etc.
I believe this is only due because of the choices of the programmers that used some "default" modes.
To give you an example the good ol'Dos program I was talking about used Enter to confirm data typed in a field AND move to next field, to go back to a previous field it was Ctrl+Enter, then you had to press F8 to confirm the whole form and exit to the main menu or F10 to confirm the whole form AND go to the next form of the same type.
When you got to a field like "state" or "country", that need to match an existing database, windows programs mostly have a drop down list (and you need the mouse to open the drop down list and scroll down until you find the one you want), the old program allowed to either enter the two-three letter country id (like IT for Italy, DE for Deutschland, etc.) OR to type the first few letters and then autocomplete with - if I recall correctly - F4.
Dates could be typed without separators, i.e. 22082021 and when you pressed enter the field would be automagically formatted to 22/08/2021, currently in lots of programs (or web sites) you have to click and then a calendar pops up, and you have to click three times for day/month/year, some "smarter" ones have a button for "today" but that, for a field like "date of birth" makes no sense whatever.
This latter is a pet-peeve of mine but 3/4 to 7/8 of all web shops, including those that are clearly national only have a drop down list for countries that invariably starts from Afghanistan, which possibly represents 0,0000000001 % of the orders.
Then you have "tabs", on a huge screen 1024*768 or higher resolution the actual form is a tiny window, and you input name/surname/birthday/address, etc. on it, then you have to switch (why?) to another tab to enter (say) fiscal data and to yet another one to add notes.
Of course there are also better UI's, but the large majority is as I described above.
I can see the advantage to developing something in-house if there aren't options that meet some special need, I just personally haven't seen it work out much. Maybe because of the size of companies I've worked at. I've definitely written helpful software for myself and my own team.
In the end I found a 40 minute work around.
I can't count the number of times I've called customer service and have to wait 2-3 minutes for the agent to bring up some screen as they apologize and explain "our systems are really slow". It regularly takes up a majority of the call's time.
Back in the early 1900's, time and motion studies [1] in factories were all the rage. And today Amazon certainly optimizes for the actions warehouse employees are required to do.
But when it comes to the actions people do with computers, I've never once seen a company actually measure wasted time waiting on slow applications. It seems like such an obvious thing to try to optimize. And it's not like it requires constant surveillance or anything -- it's just statistical sampling. Watch 10 randomly selected employees for two hours each or something, with their consent.
In many cases "good UX" is impossible to measure in any conventional sense. But when it comes to repeatable enterprise tasks, the time aspect actually can be measured.
Does anybody know why companies don't? It feels like such low-hanging fruit.
[1] https://en.wikipedia.org/wiki/Time_and_motion_study
I have a friend who works in a call center. They work 10 hour days with no breaks between calls (the queue is often 40-50 people deep). (They do get the federally-mandated breaks of course.) "Our systems are really slow" is 100% true, but is also probably a welcome break for the agent. So if you are the clever software engineer that goes in and removes the sleep(180s), that's probably great for a few hours until all the call center agents burn out and leave early and use their spare time to start organizing a union. (Of course, if you save 2 minutes a call with software, you can just give people a mandatory 1 minute break between calls and come out ahead -- a true win/win. But that would require that the software team and the call center management team coordinate, and I don't think that's ever happened once in the history of large companies. You'd be the first!)
I would split your point in two dimensions: 1. Software should support efficiency and speed. (We often fail at that.) 2. Tough jobs exist and it’s up to the employer to make them worthwhile and at the least prevent burn-out.
DDG suggests that this is a leading call centre industry publication. This is their article list:
https://www.connectionsmagazine.com/articles/by-topic/
I've skimmed a couple of sections. There are a couple which look at workplace issues (career & self-improvement, workfroce management). Nothing jumps out immediately, but there might be some hints.
Note that what you find in articles and practices on the ground ... may differ.
Vendors advertising workforce-related systems and services (especially monitoring, tracking, recruiting, etc.), or legal / compliance organisations, could also give some possible insights.
Overall, it's a low-wage, low-skill, but also low-hazard environment (no dangerous equipment, encounters, etc.). Much of it is outsourced to low-cost regions with many English speakers (Philippines, India, Mexican border towns, Florida, etc.). Alternative employment may be scarce, unemployment high.
Change any of those dimensions and you might see conditions improve.
I've worked on in a large bank doing sales with slow IT systems, (The Mainframe was awesome quick though, shout out to black screens!). The bank coached staff to use there tools in an order and structure their conversations so they'd have buffer for information and systems to be there when needed.
Warehouse work is very repeatable compared to most work with a computer.
Then I met a UI researcher, hired by Army Corps of Engr to explain the missing productivity, who went way past time & motion to strategies. The interplay between tools and techniques, influencing how people organize their tasks. Matrices to highlight weird noun (line, circle, text) and verb (copy, move, delete) interactions. In other words, he showed how strategies from manually drafting did not translate to CAD and proposed new strategies (metaphors) and training appropriate for the new medium. Then validated his ideas with usability testing. Brilliant stuff. Like facepalm obvious once you see it.
Crickets.
Both Autodesk and Bentley Systems were hostile to user centric design based on real world data and lived experiences. The geeks and sales pukes who had never designed or drafted knew what designers and drafters needed, so piss off.
Besides, they're printing money, validating their efforts. And you aren't. So piss off.
Lather, rinse, repeat.
That's because customer support is the number #1 variable cost on that kind of software.
If you change anything, you start absorbing customer support calls from your enterprise customers.
This is how I knew that Microsoft doesn't carry support costs for Office and Windows--they rearrange GUIs willingly.
My mentor at that time was an AutoCAD dealer. He (eventually) explained the value added reseller racket to me. Very similar to franchising.
Autodesk and others sloughed off most marketing, sales, inventory, shipping, and tech support onto their dealers. Their reasoning, IIRC, was that while dev cost 7% of revenue, those other activities cost 30%. Why not get rubes to cover that overhead?
Further, turnover in the dealer channel was about 1/3 per year. A typical dealer would refinance their house (or whatever) for a few $100k. Burn thru it trying to get established. And there'd be 2 more wannabe dealers waiting to replace them.
It was very hard to not sell AutoCAD for a loss.
There were a few tricks to surviving and profiting. Consulting, training, and hardware, of course. The most capable productized their AutoCAD addons. The most successful of those then matured out of dealerships and formed their own VAR rackets.
My mentor created Rhino 3D. Most of the tech and code started as AutoCAD addons. Until they had bootstrapped a standalone MVP. https://en.wikipedia.org/wiki/Rhinoceros_3D
--
This was the 1990s. Autodesk is now the Computer Associates of abandonware graphics programs. Some of those legacy apps probably have enterprisey support contracts, so you're probably right about that. At a guess, it's probably part of the subscription models (everyone trying to copy Adobe's success).
Quite alright. I don't mind having to defend my positions--downvoters with no comments, however, piss me off. :)
> The most successful of those then matured out of dealerships and formed their own VAR rackets.
Yeowch. :(
I didn't know that Autodesk sloughed off the tech support. I'm not surprised.
Call center jobs are largely exploitative and demeaning. Outsourcing customer service should be illegal, period.
Take Photoshop for instance. Just about anybody who spends even a moderate amount of time in it will tell you that even though it's become more capable in the past 15 years, it's also become a lot more frustrating and bug-ridden. Personally speaking, I would be just as if not more productive using something like Photoshop 7/CS1/CS2 than I would be with Photoshop CC.
Also, don't try to automate just now, try to do it few times, then write down the steps, and selectively automate them. It's actually a good way to train yourself to live with boredom. We tend to find hyper stimulus, that's how we were wired. And we waste a lot of energy not in doing the chores but worrying about them.
It occurrred to me that someone once said that learning math and other subjects in school is training yourself to do the mental chores. And patience is such a rare thing to have in this constantly attention-grabbing society.
A balance check is important, do give yourself something else to do when you leave the work.
I’m reminded of an HN discussion from a couple of months ago, where we were talking about writing code for computers to run vs. for developers to read. I did a quick calculation¹ of how much time is wasted by some modern dev tools just by having a few seconds of delay before giving results. Spoiler: It’s crazy how much time we waste that way if millions of developers are using the tool regularly.
If one way to be a 10x developer is to help 9 of your colleagues become 2x developers then someone who creates excellent developer tools might be a 100x developer just within a large organisation, or orders of magnitude more if the tool is released openly. Personally, I’m hoping for someone to write a good, comprehensive standard library for JS/TS data structures and algorithms and convince the major browsers to include it out of the box. I don’t know how to measure the amount of time that could be saved firstly by making it easier for millions of web developers to write good code and secondly by severely cutting back the huge dependency trees that result from the current culture of pulling in tiny dependencies to do tiny jobs all over the place. It must be astronomical.
¹ https://news.ycombinator.com/item?id=27420500
Time to load and login to slack: 120-180 seconds with about 7 clicks
... sometimes I even have to wait a while for it to catch up with my typing like i'm superman or something. At which point I usually revert to copy and pasting messages from VIM... that's how slow slack is on a 2 year old laptop.
Seriously, when I was more motivated I used to write code in garbage Xcode which was slow and crashed all the time. I just powered through. Now IntelliJ offers crazy code completion and instant refactoring/navigation, but I space out every time I have to wait 5 seconds for the app to build.
Terminal/3270 screens may have been ugly, but they show about the same amount of information as a modern enterprise app does.
The sheer waste of modern CPU speed is why there isn't anything big coming out of the screenpusher labor economics. Why I have screen lag in a modern PC is mystifying. It should basically NEVER happen.
What can I say? The last 10 years UIs went ergonomically from bad to worse.
Loading time of screens are to long nowadays. While loading and rendering the browser typically keeps on moving screen elements around. Each of this movements interrupts the search for the relevant information for the eyes. Each of these movements enforces the eye movements, search for a new object to focus and accomodate its lenses.
Nowadays it is in many application not uncommon to have several of these movements in one loading of a page.(This problem comes is actually somehow connected that HTML is a sessionsless protocoll in connection with modern JS which makes increases loading times. Using microservices quite often lead to bad UI because of the uneven loading times).
Other problems are coming from opting into gimmicks like using "effects" or to scrolling instead of paging. While scrolling and paging is ok of websites (in most cases), in most business application you want to avoid this because it is coming with the same problems as slow loading and moving elements on the screen.
Another set of problems coming form bad choices from UX designers. Look at the example in [1]
- Wasting of precious screen real estate for white space leads to searching for information you need and again: scrolling, eyes movement, accommodation.
- Lack of optical guides like lines. Try to set all cells to white background in excel and start working then you see the effect.
- Lack of contrast: Dark grey text on light grey background (which MS Office does as well in their settings menu [4])
- For design purposes the chosen fonts are much to small to be readable in a convenient way
- Header and actual data (i.e. relevant information) are indistinguishable.
Finding Information in the "basic data" section in [1],[2] is a hide and seek game for the user. Assume you seeing this display 50 times a day during your work. You are guaranteed to come home with a headache
Another example of bad UI are the tiles in W10 start menu [6]. Instead of allowing the eye to scan the entry from top to bottom in one line, the eyes are forced in zig-zag of the tiles and they have transverse a bigger space on the screen because you have much less tiles on the same space as lines is the old menu structure.
Another example what causes stress and frustration with software is when the UI of one software does behave differently the others. Your software should generally be designed as what the user expects. An example of a bad UI for this case is MS-Outlook [3]. Some of the more often used navigation elements (switching between mail and calendar) are moved left bottom corner. This is against user expectation. Microsoft Outlook moves its navigation elements to somewhere where no one else put them. No one would design a car with gas an break pedals exchanged and putting the gear shift in the trunk. Microsoft Outlook does so with its navigation elements.
Another common problem is that to many screens in your application look to much alike. While it is desirable that the screen designs meets expectation, it is important that the user can spot immediately in which screen he is working. When for
Nested menus / hidden functionality is an typical issue in software as well [5]
Flat design is generally a stressor because is lacking optical help.
Examples of bad UI:
[1] <https://blogs.sap.com/wp-content/uploads/2017/08/Object-Page...>
jesus fucking christ its 2021 its still painful, haha.
https://www.kilobitspersecond.com/2020/09/22/people-expect-t...
Iteration times should be one of the major tenets in our programming books other than the stuff they recommend to derisk your software.
The speedup happened on the exact same computer - same CPU, same memory, same hard drive. So it had zero to do with hardware, and everything to do with coding. And if you threw faster, better hardware at the problem, it would not change anything for shit.
So never depend on the false hope hardware will solve shitty software design issues. The whole idea that it is cheaper to code fast to get something out fast is bogus. It just takes knowledge on how to do it correctly in the first place. I don't think the coding that I did took any longer than the original coding. The original person just sucked ass.
So, whatever language you code in, you should start watching videos or reading articles on how to maximize your application's speed. It usually is not that difficult, if you spend some time. Most of it you can copy and paste. Do searches on "Top 5 ways to speed up x language". So easy.
That really drilled the lesson home on the importance of the approach to making real fast systems on the design side and not on the hardware side.
There's a lot of low-hanging fruit when it comes to performance and quite often it seems to be left in the tree...
The thing is that once you learn these techniques, everything that one subsequently writes will automatically incorporate them. Once one knows how, it would be super difficult not to use them on every project. But, yeah, I usually like to read "Top 3 ways of optimizing xyz".
Focus Stealing
I'm using many apps and portals over the internet on Tuesdays, and I would be so much more productive if I could start something in one app, then leave it to do something else and only return to that app when its done thinking.
If I could run all of my work's accounting apps in Linux, I'd be i3 all day long.