Sunday, January 22, 2012

Putting Yourself in the User's Shoes

I was engaging in my usual habit of consuming information when I encountered this great post on Study Hacks about how the pursuit of convenience often interferes with performing great knowledge work. The article makes a strong point regarding the construction of work habits, but I think there's an additional point to be made about the construction of software.

Here's the article:
http://calnewport.com/blog/2012/01/21/distraction-is-a-symptom-of-a-deeper-problem-the-convenience-principle-and-the-destruction-of-american-productivity/

and a quotation from it:
The following line is from an e-mail I recently received from Georgetown’s HR department. It references “GMS,” the slick new database system they installed to unify all employee services:
Please remember to log in to GMS a few times each day to check your Workfeed for any items requiring your attention and/or approval.
Among the tenure-track faculty, the message was a source of amusement: the idea that professors at a research university should be checking with the HR department several times a day, just in case there is some administrative task waiting for them to complete, runs counter to everything we’ve ever been taught about how people succeed in academia.

The author goes on to explain the Convenience Principle and how it's undermining knowledge work. I want to discuss the IT system that the HR department inflicted on the rest of the campus. The creators of the system did not spend enough time putting themselves in the shoes of their users. They created something for the convenience of a few people that was inconvenient for everyone else.

Here's what went wrong and how I think it could be improved:

1. No one wants to check an additional inbox. 

Optimizing your information flow means reducing the number of buckets you have to check for new information. Adding a website that you have to check is another bucket of information that you need to look at on a regular basis. It can be a huge waste of time, considering that most of the time, there isn't going to be anything new. It's also another distraction that can sap energy from your day.

A better way to perform this task is to publish the information in multiple formats. Offer the users a choice between a weekly email, RSS, in person meeting, and other commonly checked notifications. This eliminates the additional bucket and allows the users to batch this new information with their current workflow. We already have RSS, email, websites, social networks, SMS, snail mail, etc...  Let's not force our users to check another inbox.

2. Respect the time of your users. 

A common theme of IT systems is that they are convenient for everyone but their end users. The HR department that implemented this system did so for their convenience, not thinking about the users of the system. They save time at the cost of everyone else's time. This work jujitsu can be expensive. I think that organizations need to take the time spent using the application into account when doing their cost benefit analysis. Developers need to make performance and the time to complete workflows important design considerations. We need to design for user efficiency.

Here's an example:

Let's assume that this system saves the time of two full time HR workers and costs each employee an additional five minutes a week checking the system. Georgetown employes about 3,500 people, so if you do the math...

Time Saved:
2 workers x 40 hours / week =  80 hours / week

Time Wasted:
3500 workers x .083 hours / week = 291 hours / week

Total:  211 hours wasted per week.

Five minutes feels like nothing compared to two full time workers, but the math shows how significant those five minutes are. This is why performance is such an important consideration when designing software. A small cost can be very expensive when multiplied across many people.

 
Conclusion


Software designers need to spend more time creating software for users, as opposed to creating software for themselves and then inflicting it upon users. We need to prevent the creation of new inboxes and respect the user's time. Software development is about creating tools to improve the lives of uses, and it behooves us to spend more time thinking about what they want.

Remember the platinum rule:

"Treat others in the way they like to be treated."



Thursday, December 15, 2011

Book Review: The Passionate Programmer by Chad Fowler

The Pragmatic Bookshelf had a sale on Thanksgiving weekend where they discounted all of their books by 40%. Since their eBooks are around half the price of their print books, an additional 40% off made them a steal. I scored three technical books for $36. Merry Christmas to me. The first book that I read was The Passionate Programmer, by Chad Fowler. This book has been sitting in my Amazon wishlist for a while and I am happy to say that it was worth the wait.

Summary:

The Passionate Programmer is a series of essays about building a software development career. The book deals with five major topics.

1. Choosing Your Market.
    This chapter deals with the issue of choosing what to specialize in. You need to take control of your own learning and not rely on others. Choosing the right platform to invest your time in can lead to great career opportunities. Additionally, learning about a specific industry is a good use of your education time.

2. Investing in Your Product
    This chapter is about improving your skills. In order to succeed in business, you need to learn how business works. You can not creatively apply software to businesses that you do not understand. Teaching others is a great way to learn. Learning from the experience of others is also important. You can do this through finding a mentor or by reading about design patterns. Finally, you need to practice the craft of software development on a regular basis. You can't learn everything on the job.

3. Executing - How can you apply your skills to create maximum business value?
    This chapter is a series of tips on how you can improve your performance on the job. You need to realize that you work for a business and it's important that your software adds value to that business. Think about how much your services cost and how you can add enough value to cover that cost. Also, don't let fear guide your decisions.

4. Marketing - How do you market yourself to others?
    This chapter deals with how you market your skills and accomplishments. You must disregard the negative connotations that are sometimes associated with marketing. Work to manage how other's perceive you. Communication is one of most important non technical skills you can acquire. In addition to learning how to write well, you also need to learn to use language that's appropriate for different audiences. What makes sense to a developer probably won't make sense to a business person and what makes sense to a business person may not matter to a developer.
 
5. Maintain Your Edge - How do you keep up with current practices?
   This chapter is about keeping up with the ever changing world of technology. As technology marches on, your skill set will become obsolete. You need to constantly look for the newest technologies. Don't worry about the end, but focus on what you can do to become better today. Continuous improvement is the key to keeping up.

Major Takeaways

1. Software development is a craft. You need to continuously invest in and practice your skills. Choose those skills with care.
2. In order to have a successful software development career, you need to realize that you work for a business. You need to learn how that business works and how to speak the language of your business users. This  will help you create more valuable software.
3. Take control of your own destiny. Create road maps and plans. Do not let your employer determine what you learn and what you can work with. Be deliberate.

Should you read this book?

I think that most software developers would benefit from reading this book. The book focuses on soft skills, but I feel that those skills are important. I really enjoyed reading this one.

Monday, December 5, 2011

Aesthetics Matter: Good Looking Software Works Better and is More Valuable.

This is part of a series: The Business Value of Software Craftsmanship

Engineers commonly think that appearance is irrelevant. Managers and business users often don’t feel that investing effort into the visual design of a product adds business value. Especially if that product is meant for internal use. I think that these viewpoints are incorrect. Paying attention to the aesthetics of a product makes the product work better and adds business value.

Studies show that users perceive more attractive products as being easier to use and less error prone. This concept is referred to as the Aesthetic Usability Effect.
Don Norman sums this up well:

“Positive affect makes people more tolerant of minor difficulties and more flexible and creative in finding solutions. Products designed for more relaxed, pleasant occasions can enhance their usability through pleasant, aesthetic design. Aesthetics matter: attractive things work better.”- Norman, D. A. (2002). Emotion and design: Attractive things work better. Interactions Magazine, ix (4), 36-42.

Because attractive products are easier to use, training time is decreased. This saves money, but it also helps to increase the credibility of the team that's developing the product. This is important because users may work to undermine development efforts if the development team loses credibility. Upset users can increase the cost of development by submitting excessive bug reports, refusing to provide information, and holding up the development process. Spending the time to make a product attractive pays off in the long run for these reasons.

Another area where aesthetics can add to the bottom line is typography. By creating appealing type, you can improve the readability of an application. Increasing readability increases reading rate. Poor typography slows down reading and can even cause fatigue.Think about how much time a user is going to spend reading the text in a business application. Even a marginal improvement in reading speed will pay for itself.

Even though I think more attention should be paid aesthetic concerns, I want to make it clear that I do not think we should abandon all other aspects of development. I think that aesthetic design complements functionality. I am also not saying that ugly applications are useless. There are plenty of useful utilities that look terrible. The point I am trying to make is that paying attention to the aesthetic aspects of an application adds business value.

Additional Reading:
http://usabilityfriction.com/2010/03/30/aesthetic-usability-effect/
http://www.jnd.org/dn.mss/emotion_design_attractive_things_work_better.html

Saturday, November 19, 2011

The Business Value of Software Craftsmanship

I recently read the following article that contained some career advice for software developers.

http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

This article contained many good points, but there was one section that bothered me:

“Engineers are hired to create business value, not to program things:  Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs.  Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things.  (That can, but does not necessarily, entail actually doing them.)  The person who has decided to bring on one more engineer is not doing it because they love having a geek around the room, they are doing it because adding the geek allows them to complete a project (or projects) which will add revenue or decrease costs.  Producing beautiful software is not a goal.  Solving complex technical problems is not a goal.  Writing bug-free code is not a goal.  Using sexy programming languages is not a goal.  Add revenue.  Reduce costs.  Those are your only goals.”

I think that the above quotation illustrates a common software development myth. This is the myth that quality doesn’t matter when creating internal business software. People who subscribe to this notion think that spending extra effort creating great software is a waste of company money and that we should just produce the lowest quality product that the business users will accept. Aesthetics, good design, and extensibility are irrelevant in their quest for mediocre software.

I think this is a bunch of crap, and I am going to attack this myth like Godzilla attacks cites.

This is going to be a multi-part series. I will go through each aspect of software quality, explain why it adds to business value, and give you some techniques on how to improve that aspect. When I’m finished, you will equate proponents of mediocre business software with people who still think the Earth is flat.

Part 1: Aesthetics Matter: Good Looking Software Works Better and is More Valuable.


Saturday, October 15, 2011

Tab Order Helper


One of the major issues I've noticed as a developer of enterprise web applications is that when a legacy application is converted to a web application, no one considers the fact that the legacy application user is used to keyboard centric entry. Web application developers forget that the people in a business environment use their applications for rapid data entry and requiring a mouse slows the user down. I've also noticed that the need for keyboard centric data entry never seems to find it's way into the requirements. Business users don't think of it either. These unwritten requirements are found at the end of the project when the users report cursor focus bugs.

To help simplify tab ordering and cursor focus, I created a jQuery plugin. This plugin abstracts the tabIndex and provides a more intuitive way to deal with tab ordering.

This plugin allows you to define tab ordering by the id of the next field, allowing you create a linked list of fields. After you define your next fields, you can call the "setTabOrder" function and it will set all of the tab indexes for you. Here's an example:

  
// This code sets the tab order on a group of form inputs. 
$("#txtAddress2").taborderhelper("nextField",{nextField:"ddStates"});
$("#txtFirstName").taborderhelper("nextField",{nextField:"txtAddress2"});
$().taborderhelper("setTabOrder");

Tab Order Helper

Thursday, August 25, 2011

Will Smartphones and Tablets Spur a Resurgence in Desktop Sales?

I need want another computer.


Initially, I was planning on purchasing a laptop. I already have a desktop, but my laptop died a while back and I was planing to replace it. I also have a smartphone that I use heavily. At this point, I can't think of many things I'd want to do on the road that I could not do with my smartphone. Because I no longer need the portability a laptop offers, I've decided that I'm going to purchase another desktop instead.

I wonder how many other people are going through a similar thought process. Now that we have phones and tablets that offer almost all of functionality you'd expect from a desktop, the portability offered by a laptop computer is far less useful. Why lug around a 2-3kg laptop when you can surf the web and check your email on your 0.15kg phone?

I tried to find some statistics to answer my question, but two minutes of Google searching only yielded articles from the mid 2000's about how laptop sales outpaced desktop sales. I have a feeling that my line of thinking won't be emulated much because my computer usage is different than the average user. Since I primarily use my computer to make things, my needs are different from the average person who uses their computer to consume content and communicate. Additionally, a "Walmart Special" laptop costs as much as a "Walmart Special" desktop, so there's no obvious price advantage to picking a desktop over a laptop for the average consumer. Since I prefer to build my PCs, building a desktop offers me a better value than configuring a laptop.

It'll be interesting to see what happens in the next couple years as tablets and smartphones become more popular and more capable.  Perhaps desktops will make a comeback.

Wednesday, July 20, 2011

Ultimate Web Platform Deathmatch


I was talking to my coworkers today and we came up with an idea that is awesome, but insane.

You occasionally see articles in the news comparing one web programming platform to another to see which is the fastest. The only problem is that, in most cases, the benchmark is skewed to whoever is paying for the study. I think someone should start a website devoted to web platform benchmarks. The site should be like "Tom's Hardware":http://www.tomshardware.com/ for web programming platforms. To make it fair, you could open source the code and configuration files. In theory, this would result in the best code being used for each platform. Ideally, you would be able to objectively determine which platform is truly the fastest.

There are a couple problems with this idea.

1. Platform speed isn't as important as some people think it is. 
Assembler is much faster than Ruby or C#, but no one wants to use it because it's no fun. As computers become faster, we want to optimize for human efficiency, not machine efficiency.

2. There are too many variables to properly test any programming environment. 

3. Even if you created a perfect benchmark, no one would believe you anyway. 
Confirmation bias is very strong.

Because of those reasons, I will not be creating Ultimate Web Platform Deathmatch.