The back button

24 February

I believe I’ve cracked the code of “enterprise software development”. I know the secret to success having immersed myself in their culture, earned their trust, and bore witness to their rituals.

I am here to share that secret with you.

You’ll need a bit of the backstory to fully soak in the wisdom that took me years to pin down because it’s not all about what the secrets to success are, but why they are. I’ll keep it brief and include only the essential context.

But what does this have to do with the back button? The back button is just one of many casualties of the nature of enterprise workers. But that clearly needs some explanation, so bear with me as we explore the psyche of enterprise culture.

As we know with all cultures, their language affects their beliefs, their behavior, their biases, and everything they do. You can’t begin to understand a culture without learning their language.

A brief introduction to the enterprise mindset by examining the language

This first set of phrases can be heard in most meetings by non-decision-makers. Decision makers exist sporadically among the ranks. Making decisions in the face of uncertainty is probably one of the enterprises celebratory feats. But if you’re collaborating with anyone who isn’t a decision maker (or whole teams of people who aren’t) you’ll hear,

“Make sure to socialize that with the other teams and get consensus.”

“Let’s circle back in next week’s meeting when she’s back.”

“We have teams ready to work and we don’t want to keep them waiting.”

“This sounds like a good thing to bring up in the monthly Thursday meeting.”

Almost everyone is also practiced in avoiding providing information directly.

“You can find that in one of the design docs linked from the Sharepoint.”

“Our team handles that, is there a reason you need to know?”

“Our team looked into it, found the cause, and it should be fixed now.”

And processes are almost sacred rituals, especially if the people who made the process aren’t involved.

“We have a process in place for that and we should make sure we follow the process.”

Nobody would get admonished for such reasonable statements. The language is a safe language, perhaps the safest language they can muster in any moment. The language, and as follows their behavior and decisions, optimizes for personal career safety.

Take that mindset, try to come up with other phrases that maximize this “safe” and “reasonable” equation. With that enterprise-worker mindset we can now take a look at enterprise software development.

The birth of auto-scale or pay-as-you-go

The ever-persistent appetite for extracting more value led enterprises to develop “cloud strategies” to convert “lifetime-access models” to “recurring-revenue models” by repackaging what they sold before as “SaaS offerings”. All the business people were sold on the nickel-and-dime strategy, it was the safest suggestion.

Naturally, software developers have to write that code so the business folk asked the software folk to make it happen. Single-page applications (SPAs) were then safest suggestion for developers to suggest, and depending on whether it was before or after the React non-compete-with-facebook license fiasco the safest suggestion was usually Angular or React.

I’m not going to say SPA frameworks killed the back button, though they did play their part. Most frameworks seem to go out of their way to help developers keep it alive. What killed the back button might be apparent by now. But if it’s not, here’s the missing piece.

The death of quality

Concurrent with the birth of pay-as-you-go is the death of knowing how much anything costs. Everyone and their moms have cost estimation calculators, usage projection charts, soft caps, hard caps, and usage threshold alerts because of course that’s how your potential customers want to spend their time. If it can get us another nickel per month, fuck ‘em. Is the UX team really going to tell the business team “that’s a shitty user experience, let’s sacrifice that nickel to make it so our customers absolutely love our software”? That’s not the safe conversation.

Okay, so we need

“a SaaS app with 24 pages, 6 more for identity federation configuration and management, and a few more for our customers to deal with our price and service scaling, a mostly-shared navigation bar, and preferences in a modal dialog. We’re assigning 6 teams to this, and we need to deliver fast so we can iterate - no big-design-up-front!”

Oh, and all our programmers haven’t built cloud software before, not even web apps. Ready set go.

The enterprise software developer isn’t going to say “I need help, there are likely aspects to this that I don’t forsee and won’t without help.” At best it’s “Our team will take an online course to learn while we try to hire someone with experience and make progress building it at the same time.” Reasonable, right?

We’re lucky if it’s not all divs with onclick= attributes.

I encountered a bug (not related to the back button) causing an app to completely freeze until the user refreshed the page. The team working on that code said that “it wasn’t part of the requirements to handle [that situation which causes the app to freeze]…” They basically said it’s okay for the app to freeze if nobody specifically said that it shouldn’t freeze.

It doesn’t need to be an explicit requirement to not freeze or crash. For the web, it doesn’t need to be an explicit requirement to use anchor tags for links, button tags for buttons, or form tags for forms. Don’t flash the screen making it cause epileptic seizures. Don’t do weird things that fuck up screen readers. Don’t title all your pages with the same title. Don’t break basic browser functionality.

Some things go without saying.

This was where the back button took a critical hit.

“The official docs do it this way.”

“We gave ourselves an aggressive schedule.”

“Work tends to fill the time given to it.”

The enterprise software developer bases their decisions on career safety. After all,

“it’s usually ill-advised to think our situation needs a unique solution so we should generally do what everyone else is doing.”

And when “everyone else” is on the hype train for their favorite company’s favorite SPA framework writing tutorials with (non-production-ready) code showing how easy it is to write that (shitty) code, the safest conversations will have sentences like,

“I researched how others were doing the same thing online and followed their lead.”

It’s less work to do it the right way. Usually by the 2nd day it’s already less work. But the whole sequence of conversations, meetings, discussions, and decisions all converged around personal career safety.

That’s why your site still fails accessibility audits.

That’s why it takes teams of programmers to make the simplest of changes.

That’s why the back button doesn’t work.

The secret to success in enterprise software development

Be a mirror for their culture and their language. Be such a good mimic that they see themselves in you. To do this well, use safe language, make the safe suggestions, make the safest decisions, and make sure everyone sees how safe your decisions are so they can make the safe decision to promote you. That’s probably how they themselves got promoted. It will make them feel good to see their decisions and behaviors validated in your promotion.