Front-Load the Pain
This is a story about a bug that I still think about.
It could have been avoided if I’d been able to successfully convince us that we should sacrifice a little bit of backwards-compatibility. It would’ve meant customer complaints. Some customers would have delayed their upgrades; some may have even threatened to not renew their contracts (although the chance of them carrying out that threat was incredibly slim.) In other words, it’s a decision that would’ve caused a lot of up-front pain.
Here’s the story, in short:
Product redesign. Fundamental change to product functionality and positioning (and one that had been well-researched, thoroughly user-tested, and really well-received.) Just one problem: we’d made the promise that the layout of the UI would be backwards-compatible (as a white-labeled software package, we were styled to match the branding and templates of the ‘parent’ website). “You won’t have to change your templates or stylesheets or the order of the modules on your dashboard,” we’d said.
But it just wasn’t possible. When you add information, you just can’t fit within the exact same dimensions. After a lot of reworking, we had a lot of workarounds: Customers could use flexible-width instead of fixed-width. They could shift from a double-column to a single-column layout. They could keep the double-column layout but make one column slightly wider than the other.
I was mortified, frankly. It was a problem I should’ve caught earlier, and now that we were rapidly approaching release dates, I had no solution. I made the only recommendation I could.
“They’ll have to make a change,” I said, “but we can help them make it as painless as possible. We can do the stylesheet revision work for them to make it as close as possible. Their end users may not even notice.”
I was overruled. We’d told them backwards-compatible UI layout, that’s what we’ll give them. Figure out a hack to make it work. Postpone the pain.
And here’s the consequences:
So we hacked a solution for the first customer. Reduced font-sizes, sliced off a few pixels of whitespace here and there. It worked – kind of. But hacks aren’t good at solving for edge cases. So the bugs started rolling in – in certain circumstances, the layout would break again. And we’d fix that issue, but then the next customer would find a different way of breaking the layout.
I can’t count the number of hours devoted to variations on this one bug. Customer service had to deal with it, design, professional services, engineering, QA – every fix touched multiple departments, and never fully resolved the issue.
For all I know, the same bug is still being hacked on, 3+ years later.
It would’ve been painful to tell customers that we had to go back on our promise and break backwards-compatibility. But that single decision probably cost tens of thousands of dollars in productivity loss. Hours and hours in opportunity costs. And the customer goodwill we’d hoped to preserve was at least somewhat eroded by the fact that we kept breaking their layout, anyways.
Pain fades with time. (Anyone who has lived through a website redesign knows this: you’ve seen a ton of vitriolic customer feedback, followed by little to no actual effect on traffic, followed by people forgetting that it was ever any other way.) But trying to avoid pain at all costs takes constant, ongoing effort.
-->
