Yet another reason why I'll never be rich

My desk at work is at the far end of the office and mostly obscured by the other cube walls. With goaltending being pretty rough on my knees, I like to sit very low so that I can keep my knees bent when I'm sitting or easily straighten them out by slumping in my chair. This means that people can't see me until they get all the way to my desk. This annoys people.

Were I somebody else, I would default to one of these options:

1.) Deal with it.
2.) Increase the height of my chair and get a box on which to put my feet.

But since I'm not somebody else, I started using this sytem where I placed an index card on the wall behind me to indicate to others whether I'm at my desk, away from my desk, or at home. This was an intuitive, low-tech solution, but failed to address the laziness problem. See, cycling between three index cards requires that I pay attention to what I'm doing and remember to change the cards.

I don't.

So instead of a reliable indicator of my presence, the cards were serving as public reminders of my laziness. They were lying to my coworkers' faces.

The one thing I don't forget to do, courtesy of college roommates, is forget to lock my computer. So I started thinking about having my machine toggle a light on and off when the computer gets locked. Further analysis revealed that this would probably be a lot of work,* so instead I decided to build a light that I could actuate manually.

A little-known fact about my day-to-day interaction with objects is my liking for a good button. Elevators, street crossing signals, keyboards, and anything else with buttons stands to make me much happier with a good, responsive button. Toggle switches are particularly desirable because they've got a solid mechanical feel and a decidedly retro feel.

I go to Radioshack, buy two project boxes, a spool of wire, a package of 68 ohm resistors, a giant LED, a toggle switch, and a roll of solder. We have broken the $20 barrier to build a light. With a broken keyboard donating a usable USB cable, I set to work building the simplest circuit known to man. I can sheepishly admit that replacing a battery with a USB power source in this circuit required the repeated humiliating refactoring of my design as I found myself continually building a circuit whose sole function was to short circuit a USB port.

I swear, I am actually a fully degreed and educated engineer.

So now I have a complicated solution to a simple problem, and all I had to do was spend $20 and a half hour at Radioshack.

*The Googling required to find a piece of software that will turn a light on and off was feeling onerous.

What UX Is

User experience design has spiraled wildly out of control since the release of iOS with the iPhone a couple years ago. Menus have become passé. Navigation is supposed to be touch friendly. Hell, even Microsoft is getting rid of the ubiquitous Start menu, having already eliminated (or at least hidden) the File and Edit menus.

These changes are not improving usability. Changing usability, yes, but not fundamentally improving the usability of an application.

Usability is not a measure of how easy something is to use, although that is often an important factor. Rather, it's a measure of how effectively something helps you complete your work.

Software isn't usable because very often, what we do with software isn't possible in the real world. Unfortunately, we keep trying to create digital representations of physical things in a futile effort to make things easier to understand, more "intuitive*."

Why are we doing this? Why do we keep forcing users into arbitrary folder structures to store files?  Aren't there cases where a single file makes sense in two locations?  Does a user care where a file is stored as long as he can find it? Does it even make sense to require users to save files?

These are the types of questions an effective UX designer will ask.

It's unreasonable to expect that every user will sit down with an application and instantly understand how to complete their work. In some cases, I'd argue it doesn't even make sense to try making an application instantly understandable. There will always be an upper bound on the number of functions an application can perform before it becomes necessary to start stashing things in menus. And that's okay! Users will put up with questionable UX if the software improves their lives. They will not put up with beautiful UX and no functionality.

There are some obvious things to avoid. The California DMV provides a particularly egregious example:

Outside silly problems like this, though, good UX is achieved through an understanding of user goals. Understand your users, understand their goals, and you'll construct an interface that gets out of their way.

*"Intuitive" is a word whose incessant use in IT leaves me confused and angry. The word has no meaning because it results in no action. Ask a user "is this intuitive?" and they'll say yes or no, providing absolutely no help and forcing you to ask the better question, like "what about this tool makes it easier or harder to accomplish this task?" "Intuitive" is not a quality of software. It is a buzzword.

Stop thinking strategically

My first day in post-graduate corporate America required a dramatic and unsettling change in my decision making. No longer was it enough to merely accomplish the goal - I had to think "strategically."

My problem with words like "strategic" is that they're rarely used in a way which corresponds to their English definition. I learned quickly that "strategic" meant "in a way that's unlikely to solve our problem but also unlikely to offend executives." And while there are valid reasons to make decisions classified as strategic or tactical, this insistence on being strategic overlooks the obvious: do the right thing.

Many hyper-dysfunctional IT departments become paralyzed by unexplained business decisions made years before. Having endured years of failure as a consequence of shortsighted management and a generally inept staff, they revert to the risk-averse approach of avoiding short-term fixes. Why bother fixing one defect if there are ten more? Wouldn't it make more sense from a strategic standpoint to just refactor the whole thing and fix them all? Let's form a tiger team! We can hire some consultants to introduce a new stack and let the stack fix everything! We won't even need developers because EVERYTHING WILL BE CONFIGURATION!

Meanwhile, the users are sitting around wondering why some critical piece of software has had an obvious bug hampering their work for months, the engineers are shaking their heads, and the corporate overlords are ten minutes from firing their third CIO in two years.

The right decision is to fix problems. Tolerate hacks that improve the user experience . Of course, yes, I understand, individual fixes may often create a hostile user experience in aggregate, and yes, you need to reinforce the need to pay down technical debt or incur an unmanageable tax. Sure, go for the whole-enchilada refactor when you must. But the correct solution to a pressing, time-constrained problem very rarely includes things like tiger teams.

Just like developers who pair program effectively surrender ownership of their code, effective project managers should surrender the desire to put their personal imprint on the project. Commiserate with your users and prioritize accordingly. 

Dogma

Note: This wasn't really what I planned for my first post here. I have this whole "anti-business speak in IT" thing I've been thinking about for months, but I felt the fire last week and went here instead. Boom?

There's a groundswell of support for pragmatism in agile software development. And why not? There's definitely a compelling argument that agile principles necessarily promote pragmatism, and I'm not going to hammer away at my keyboard denying this. The problem is, though, that in every organization I've seen, pragmatic turns into sometimes, sometimes turns into never, and never is amongst the dirtiest words in software.*

My organization was engaged with an agile-leaning software consultancy for about two years, with most of that time coming before I joined this noble band of  nerds. Upon their departure, I made my best effort to appear receptive to feedback and had a chat with an extremely intelligent and extremely proficient software engineer to discuss my job performance and other Things That Are Important Now That I'm An Adult. I was surprised by his comments. Rather than criticizing my sardonic management style or penchant for accidentally scheduling meetings in the wrong time zone, he made a plea.** Excuse the misleading quotations; this is not a direct quote, but I nevertheless wanted to make it appear conversational, because that's apparently how I am:

"Your organization has achieved success. But the success has brought laziness. Your developers are avoiding pairing. The business analysts are writing stories without QA input. Your QAs are rejecting stories without talking to the devs. At least one team hasn't had a retrospective in over a month.

All of the success the department has had over the last two years has been predicated on knowledge, whether it's knowledge shared between pairs or knowledge shared across the business. Do not allow "pragmatism" to infiltrate your teams. Be the person who upholds agile principles with conviction because success will minimize the organization's value of retrospectives, of showcases, and of pair programming. You always talk of how wonderful your mentors have been. What would they do? Be them now."

The aforementioned consultancy is frequently accused of being dogmatic to a fault. And, perhaps, it's true. The PMs who trained me insisted on biweekly iteration planning meetings, showcases, and retrospectives. They demanded dev huddles, daily standups, and thorough acceptance criteria. They added ACs like "Given that I am a developer who cares about quality, when I am working on a story, then I will write JS unit tests."

But they also defended core hours. They impressed product management. Most importantly, they delivered. And delivered. And delivered. Where our department had previously failed our clients, again and again, we started delivering high quality, high value software. We moved engineers between teams without sacrificing velocity or quality, we adapted to scope and requirements changes, and we got along. We sang karaoke. We drank beer. We watched the Kings win the Stanley Cup (well, I did, at least). Because we embraced the ideas behind the dogma, it stopped feeling religious and started feeling right.

"Pragmatic pairing" and "as-needed retrospectives" are a bad solution to an inevitable problem: every software shop is understaffed. Yes, it is absolutely possible to increase velocity by reducing the amount of time developers spend pairing, and yes, reducing meetings like IPMs and retros will increase the amount of time your devs can spend in Visual Studio. But the process has proven to be unreliable and unsustainable. Knowledge will be lost when your senior engineers wander off into the weeds to solve a problem while junior engineers implement the same feature toggle they've implemented 100 times before. Personalities will grind when the retrospective prime directive is not recited and retros, when actually held, will turn into performance reviews rife with ad hominem attacks and, yes, existential angst.

So when your team starts talking about pragmatism, address the underlying cause and move even further towards the dogma. Your clients will thank you and your devs will...well, they'll get it. Eventually.


*The dirtiest phrase, of course, is "scope creep." The horror!

** He also told me to start acting more seriously when people come to me with problems. Apparently, my flippant attitude isn't particularly comforting for the techies, although the business folk seem to enjoy it. I'm still an engineer, I guess, and the years of losing to math exams have created a coping mechanism in cynicism.