mobcode

Sieze slack time

There is rhythm to life. Times change. One day there is intense pressure to get things done. The code needs to be finished immediately, there are production problems, or some such thing. Then a few days later there is apparent calm. Nothing is obviously broken and there is no immediate pressure to deliver. What to do in these times?

One answer is to work ahead. Attack the list of things to do as if there were immediate pressure. Why? Because there is a good chance that tomorrow things will change and the app will need to be done. If you work ahead now then you can alleviate that pressure in advance.

This is in essence what the planning game is all about. It takes the tremendous pressure that is felt at the end of the project and brings that back in time to the beginning of the project. By forcing hard decisions about priorities to be made early the planning process some of the end pressure is moved to the beginning of the process. In this way, the pressure is distributed and the ultimate pressure is relieved.

What else can you during slack times? This is a great time to invest in some strategic efforts that can shape the entire project and be leveraged for the duration of the effort. For example, invest time at the beginning of the project to establish automatic build servers and automatic testing. These efforts set the project on a trajectory that will become the standard for how the project operates.

Whatever you do, realize that the slack time will not last and seize it to drive the project on to greater success.

Users need simple algorithms

We programmers tend to like hard problems. So if users give us a pile of complicated requirements we often jump right in and build a complex system to capture all of the rules. Or even if we are given simple requirements we might take on an exercise in fantasy and make a complex system.

Some people can get away with implementing complex systems. Take Google for instance. They have a bunch of really smart people doing really smart things to implement web search. And the results show this complexity but users are not bothered by it. The user interaction is simply: type something in and get a bunch of web pages. The users are blind to all of the complexities concerning what results are shown, which appear first, why some pages are not shown in the current results, etc. So the complex algorithms underneath lead to complex behavior, but the users don’t care.

Google can get away with this but most application developers cannot. Most applications need to produce results that are consistent, predictably correct, and relatively easy to understand.

So perhaps you are making a rights management system for an app. If you just collect all the requirements and make a big pile of rights then you will have a complex system that no user can predict how to use. They will revert to trial and error in an attempt to determine which rights control which screens.

As developers we need to fight our fascination with complex problems that we can code and instead concentrate on delivering systems that capture simple rules the users can understand and use.

TANSTAAFL

I think I am like most developers. I tend to like working with code. In most cases I would rather not mess with pesky users. And I certainly don’t want to spend time fighting production problems. Recently I found myself in a position where I was isolated from users and production problems. I certainly wasn’t going to complain. Although I would often think to myself, “boy, it seems like I should be talking to our users”. I ignored those thoughts and just enjoyed the isolation.

I was wrong.

That isolation has been removed and I see that all of my work suffered from working in a vacuum. Previously I was cutoff from feedback from real users. That feedback is what should have been keeping me growing and learning how to make the system better.

I should have paid attention to what I knew to be true. I should have pushed myself into the user world. I should have taken the pain in order to learn and grow.

I should have remembered Heinlein’s advice, “There Ain’t No Such Thing As A Free Lunch“.

Deliver information in a broad, shallow structure

Web sites should be broad and shallow, not narrow and deep.

Imagine a user FAQ site for a product.

It can be built to require many clicks and give just a small bit of information. Click to choose what area you have a question about. Click to choose a specific question you want answered? Then you see one answer. Maybe just a sentence or two.

Or it can be built to provide much information with no clicking. The entire user FAQ is provided as a single web page. The user has easy access to all of the content.

There are pragmatic reasons reasons why it is better to provide all of the content on a single page. Users can hit ctrl-F to search the single page of content. Users can print the page and have a complete printout of the content. This approach also requires less work. There is no need to artificially create a structure to hang small bits of content in. Rather the content itself provides the structure. For example, the questions in a FAQ become the headers for each answer.

But there are deeper reasons why a single page of content is better. It fits the way humans think. People are good at scanning through large amounts of information to find what they need. They can see patterns, pick up subtle cues, and generally use their eyes and brains to browse the information and find what they need.

People quickly become frustrated with systems that show a tiny window of data and require repeated clicks to navigate. The reason is that this mode of receiving data disrupts the user’s cognitive processes. Users experience this disruption as an unconscious frustration with the system. Users feel like they are constantly walking down long narrow tunnels trying to find what they want. Which means… people won’t like your site.

This is hard lesson for computer people to learn. We are so enamored with hierarchies we over-categorize everything.

The expert on this topic is Tufte.