New Tools Can't Fix Old Habits

I'm currently facing a problem. Every day I sit down to the same system — piles of shaky dialogs and buttons stacked like cordwood trying to hold back event stacks deeper than the Mariana Trench which were obviously written while learning the platform. Oh the joys of UI development in the world of the "new hotness."

Faced with looming deadlines and hordes of anxious customers, proclamations are uttered from on high, "We don't have time to (re)design! Just make it work." So we do, don't we?

We build interfaces out of the recycled design patterns of yesteryear while shaking our heads. "This sucks, but it meets the requirements. I just hope they don't need more functionality."

But, they always do.

So, we dive back into the sludge we've poured for ourselves, barely able to see our hands in front of our faces, thrash around a bit, and pray that a solution might come and fix all of this garbage.

False Prophets

New technology emerges, as it is wont to do, that claims to solve all the problems we currently have while tearing down all the blockers we currently face. Of course we adopt — it would be foolish not to.

Again, commandments boom from the mount. "With this new technology (which we've graciously purchased), it should be trivial to replicate existing functionality. Also, the customer needs more functionality than what we currently have to justify the cost of the new technology (which they've graciously purchased). Make it work." So we do, don't we?

Sooner or later, but always sooner than we'd imagined, we're back in the muck, blaming lame sprints on the poor foundation we've created because we were only given time to "make it work" for the customer.

Confusion abounds. "How are we facing the same problems we were before? We bought new technology!" The kicker is, the technology is rarely the problem.

Breaking Bad

In rapidly evolving ecosystems, this cycle can be very difficult to mitigate, primarily because it requires designers and developers to stop writing code and start reading code. Of course, if everyone sits around not writing code all day, how will we ship products? The painful truth is, we won't.

Taking time to study new technology will slow things down. Taking time to design based on what you've learned from study will slow things down. The end result, surprisingly enough, is a more stable, more maintainable product whose development time is shorter than a product made to just work.

"But," you ask, "if I'm going to have to take all this time to actually learn about this new technology before I can harness its incredible potential, how is it better than the old technology that I've been learning?" That's the kicker — it isn't necessarily better at all.

Without fully understanding what your technology can do and creating a design based around your technology's strengths, it is impossible to develop a product without little issues that, given time, create huge problems. So the next time a new technology promises to fix all the problems you have, it might be a good idea to sit down and read the instructions before putting it to use.