Over a million developers have joined DZone.

Beauty vs. Usability - a Tale of Two Masters

DZone's Guide to

Beauty vs. Usability - a Tale of Two Masters

· ·
Free Resource

We as passionate developers (or managers, CTO’s, help desk jockeys…etc) have one thing in common, we are attracted like moths to a flame towards the latest and greatest. If something new is coming out we are all talking about it, reading up on it, we could probably tell you five things it lacks before it’s even released. That’s one of the main reasons we are in this, all the cool sh*t we get to play with. This trait comes with a dangerous side effect, which is getting lost in the bright flashy lights of new technology and forgetting what we are here to do in the first place:  solve problems and make the user experience more pleasing.

I have heard stories, and have seen myself, situations where a system has a hodge-podge of very cool stuff, but isn’t usable. Also, there are applications that have been refactored to death, turned into a bloated barely functional mess. What it means when this happens is that someone couldn’t find the balance between what they think is neat, and what will benefit the business. I myself am coming up on a project I am very excited about. When I first started the planning process in my head I was going to use MVC for URL rewriting (ugly url’s are becoming inexcusable) and LINQ for my SQL and I was going to set up all the designers with the Expression Suite and it was going to be the pinnacle of forward development and everyone would be impressed with what I knew. However, after taking a step back, realizing that organizing a project like this is new for me, I decided to go with more familiar methods like active record sets and stored procedures. The new things I am going with are the 3.5 framework, and VS 2008 from 2005. Why? Well, they both cost me very little “learning overhead” time and the 3.5 Framework is better with paging than 2.0 and VS 2008 has better JavaScript debugging, two things that will save me a lot of time. (seriously, how did it take this long to get good JS debugging? It’s only been around as long as, I don’t know, the internet?).

So, how do we avoid this issue? What are some questions we can ask ourselves that will help us choose a good advancement over one that will spin our wheels but not benefit the application. Well, let’s start at the part where you find something exciting. The first thing you need to think of is your feature debt, what does it look like? How does adding this element to your existing application help to lower that debt? Will it save you time that you can use for development? If so, how much time? Will it eliminate some of that debt? Really? Will it, or are you just saying that so you can feel better about playing with it?

Another great way to tell if your investment is worth taking is to convince your end users or project owners that it is. Non intar-people don’t want to hear about refactoring, or code integrity, or WPF. They want to see bright shiny flashy things that look cool and make their lives easier. Convincing them that they need something they’ve never heard of and don’t care about will be a great barometer to see if this change is worth making.

Someone called the solution this quandary an Aristotelian Mean the other day. I had to look that up, but it basically means a perfect balance between two extremes, which is applicable only if you can attain it. Perfect code is beautiful, but if we keep going back and second guessing ourselves we aren’t always helping our users. All my advice is well and good, but while I have the knowledge I lack the experience of finding this Golden Mean between these development poles. I’m sure I’ll learn on my way, but if anyone has any more suggestions, I’d love to hear them.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}