Marketing Groupthink Deforms Software Design
I was implementing an API spec recently and I came across a curious word in the documentation. The word was “UX”. If you asked me what this word meant a couple years ago, I would not have been able to tell you. “UX” is short for “user experience”, which is more or less buzzspeak for “look and feel”.
Why didn’t I know this term? Well, because I’m not a graphic designer, I’m an engineer. I have no problem with this term, I actually think it’s clever. But why was it in an API spec? How did it bleed out of its rightful sphere of design? After only a small amount of investigation I discovered that the venture dudes for my company were rubbing elbows with the venture dudes for the third party, which was why we were using them in the first place. Not a bad thing there, but…
What was a bad thing was at some point one V.C. said to another V.C. something about “UX”, which was overheard by our V.C. who then said to the third party’s V.C. “I want the API to have good UX”. Like toddlers in daycare sneezing on each other, the UX meme had been spread.
Pressure came down from on high to the people in charge of the API I was now trying to implement. Pressure to do something impossible: make the API “flow” better with the user interface. This puts engineers in the uncomfortable position of having to make guesses about how the API is going to tie in with a given implementation’s visual elements. Instead of saying “no and here’s why”, they instead made their own implementation under the table and then began to redesign their API around their mock implementation.
The API was no longer a protocol for interacting with their back end. It was now a description of how their mock-up worked.
In their scramble to appease the higher-ups they had forgotten crucial parts about making handshakes, had documented the argument order for certain calls as being the opposite of what was actually expected by the server, and had left out other parts entirely such as how to get a push notification to our servers when certain events happened. In place of that documentation of course was a snippet about how great it is that you can get it to do that. This is something that was supposed to be a technical spec. Their “spec” also included screenshots of their mock user interface, which sucked and was not very UX. UX is an adjective now.
I am not in a position to say what was being made, but I can tell you the third party was video conferencing software. For some reason the creators thought it was more important to make the server wrap HTML around its responses than it was to document how to query the statuses of your contact list. Without all this crap it would have been a very clean and minimal service. In some places it was impossible to turn this HTML off.
The higher ups are responsible yes, but ultimately this is the fault of the programmers for forgetting the principle of the separation of concerns, primarily that design has no place in the data stream. They are the ones putting hands-to-work. It is their will which builds the system, not the flowery words of management.
Eran Hammer removed his name from OAuth2 because he understood this principle.
This is life and death.
If you are building a bridge, and you know that the bridge is faulty and will collapse in the near future, and you build the bridge anyway, you are to blame. If you tell your boss and they tell you to do it anyway, they are also to blame, but not as much as you.
If you are writing software for a heart monitor and you decide to silence error conditions because dealing with edge cases is somehow conflicting with the launch date, you are responsible if that device kills someone.
What is worse is when I talk to programmers about this issue, the top response is “Well, they sign the checks, so they make the rules.”
This has lead me to the conclusion that most programmers are not engineers, they are mindless idiots only interested in obtaining a paycheck so they can buy more anime figurines.
I’m an engineer, I’m not paid to think.
You are an engineer. You are paid to be smarter than your boss.
So start acting like it and actually earn that anime figurine. Say no. Put your foot down. Sit your boss down and calmly explain the implications of what they put forward.
As the lead engineer I did exactly this. That particular software was abandoned. Without life support, market forces ate them up and they no longer exist.
Good. Enjoy your anime figurines and poverty. You earned it.
