User Interface
Work More Hours
If you’re a senior-or-above talent, you know how work longer hours without it significantly impacting your work product. For this, I’m talking about the 40-50 hour range. Most people start to fall off around the 50-60 hour range, and we all start producing crap around 60-80 hours. Beyond 80 hours, it probably time to look for a new job. Having said this, let’s focus on the 40-50 hour range. If your employer suggests or requires that you work these extra hours, it’s probably not going to destroy your home life, or wreck your sense of well-being, so the impact should be minimal, if not negligible. Why not work these extra hours? Because you’re not getting paid for them.
The Point
Let’s briefly take a step back. Yes, we’re all very concerned with how best to drive software development. We love our methodologies and our philosophies — our little software calendar platitudes and acronyms. We love Martin Fowler, Kent Beck, Eric Evans, Bob Martin, so on and so forth. But really, what is the point? This article is for everyone who has ever been subjected to my ongoing ramblings and critiques of software, processes, and team dynamics. I’d like to try to offer you a moment — if ever so brief — of catharsis. These were my intentions. Here was my point.
No, Actually, Simpler Than That
Stop adding features. That one mantra — if followed consistently — would improve the majority of user interfaces. In terms of concrete evidence, it’s out there in droves, but I leave it to the reader to discover the truth of it. In essence, humans have a tough time finding what they need in a sea of what they don’t. The more features you add, the more the likelihood that you’re adding what the user doesn’t need at a given point in time. This guideline, as simple and intuitive as it is, is an extremely difficult pill to swallow for business that make their money selling new features.
What Crappy Looks Like
When we see a crappy user interface we know it. We can’t articulate it, but we know it. We look at it, have that sinking feeling in our gut, and try to figure out a way to say something about it. But we can’t. We’re afraid that we’ll offend someone, or worse yet have the wrong opinion. And really, that’s all it is – your opinion. That’s really the problem. If your assessment of a user interface is only your opinion, how can it be valid? It’s valid because you *know* it’s crappy. You don’t need a degree in human-computer interaction, industrial design, or usability engineering to know it’s crappy – it just is.
It’s Called “Service” For A Reason
Well, we’re all writing services now. This is a service, that is a service. We need a persistence service, a web service, service generating service, and services that service other services. Please stop. Put the word, “service” down and think about what you’re doing and saying. Everything you’re writing ain’t a service. “Service” ain’t the new term we’re using for “code”. You’re not always writing a “service”, sometimes you’re just writing a class. When you’re writing a service, it’s got a higher purpose and meaning that your average piece of software. It’s got to service something, or someone.
