I had a weird confluence two weeks ago. Early in the day, I read
this blog entry over at CodingHorror.com—great blog by the way—about how the user interface is the application. Then, a coworker lamented how much he hated UI work compared to the clarity of working in code-behinds. Finally, I was talking to Bob Parsons about the progress on the application I'm working on when he asked how it looked and mentioned that the UI is all important. These three events were so glaring when taken together that I had to ruminate on them.
I'm now very convinced that the user interface is actually everything. You can have the cleanest, most object-oriented code possible but no one that matters is ever going to see it. In other words, your code could be horrible, dreadful code pasta and customers could still flock to it. I'm not suggesting that code cleanliness is unimportant—far from it, in fact, because spaghetti code makes making things better an odious chore—but I am suggesting that beyond a certain level, there are diminishing returns in making things elegant.
I'll admit that I suffer from an ingrained sense of code aesthetics. All my classes are laid out by member type, then by accessibility levels, and then alphabetically. That's crazy organized, for those keeping score, but it's my particular little mania and it doesn't take a long time to maintain. Outside of that obsession, though, I'll do whatever fulfills the interface requirements. That means that I've used a GOTO statement before and that means that I'll use a Repeater even though a DataGrid is far easier. There's really no place for dogmatism in web application development.
For as long as I can remember, I've seen managers focus exclusively on the look and feel of a web application—often getting hung up on the smallest little details. A small quirk here and there during development is to be expected, but it can often derail a presentation or demonstration. I've always thought that managers afflicted with such beliefs were lacking in vision and hung up on the superficial. By and large, that was a fair assessment. The people displaying such behavior were both near-sighted and superficial.
But to hear Bob Parsons say such a thing really made me question my thinking. He's definitely neither. His business sense is on display for me every working day. His opinion is not dismissible as the vapid blathering of someone who loves to hear himself talk. I started to ponder what it might mean to say that, paraphrasing, looks are everything. That's what led me to realize that the customer is never going to see anything except the looks. He doesn't care that you chose SQL Server over MySQL or ASP.NET over Python or a table-less design over font tags.
As long as the site comes up quick enough (a ever-diminishing requirement as broadband gets more widely purchased), you could be running an Access database with a FrontPage-created UI. The customer's sole concern is whether your application is worth the money he's paying. (If it's a free application, then he only cares whether it's worth the time he's investing.) That certainly puts the relative importance of many of the web developer's cherished decisions into sharp relief.
It also means that if you're not willing to come up with a stunning user interface, then you better price your application pretty cheaply. This is assuming, of course, that you've got little in the way of competition. That's a huge assumption in this day and age since the barriers to entry have never been lower. Conversely, if you've got a stunning interface and a useful application, then you can kick your pricing up a touch and get away with it. This latter conclusion is bolstered by the excellent fortunes of Apple since 1998.
All of this has some relevance for the product I'm developing at work, to be sure. But mostly it's applicable to the idea I'm devoting my spare time to. That's right, I've finally decided what to do with my life. For a long time, I was torn between writing a series of books, developing a non-profit surrounding an online encyclopedia of Phoenix history, and becoming a software entrepreneur (don't call me an ISV, please). Each of these options suits me terrifically but I'm mostly interested in what might have the greatest returns the soonest.
I think the books have the greatest potential with the lowest risk because each book in the series will build the audience for the next one and no one else would come up with the same book I can. Unfortunately, the books are really suited to someone with a bit more career experience and I think a lack of credibility would be a serious hurdle to overcome.
The non-profit history project has no substantial monetary return but an incredibly satisfying emotional one. Hell, I'll finally be using my degree in history. That would make me feel a lot better about the student loans I'm paying on right now. Luckily, though, Phoenix history isn't going anywhere and will be easier and more satisfying when I'm older anyway.
So that pretty much leaves the entrepreneurial option. That suits me very well and can be very rewarding, but I was quite adrift due to a lack of a good idea. I've got that now—several, in fact—and an excellent opportunity that will pass by November if I don't act soon. That makes for a considerable catalyst to my daydreams and I'm knee deep in a functional specification that I hope to complete soon. I'm still not sure how much I want to publicly reveal or to what degree I'll be blogging about my experience as a startup, but you readers will be the first to know should I opt for transparency.
And you better believe I'll be focused on the application's interface. More so than I ever would have before.
