"Putting the User Back in Architecture" or face the consequences
At last, I found the time to get ready for Teched Developers 2007! I just started downloading the presentation slides and noticed the presentation "Putting the User Back in Architecture" by Simon Guest. This is a great presentation that reminds us what we often forget: The software is going to be used by users, but developers seldom take users into account when designing applications. The presentation covers many subjects: Identifying the users and their needs, designing an application that users find easy to use and finally, designing the application to handle failure gracefully. I'll concentrate on only two subjects.
The first is, identifying the users and THEIR needs. Not the needs the developer thinks they have but the users' actual needs. Quite often analysts or developers gather requirements or design applications without ever talking with the actual end users, thinking that they know what the users want. The end users get to see the application only late in the development cycle, during user acceptance testing or worse, when it is actually installed in their machine. Not surprisingly, users tend to have certain objections at this point. At best, developers discover that the application doesn't fit the users needs and get drowned in change requests - at a very late stage of the project. Know thy user, and you will avoid a lot of pain.
Another common failure is that customers, analysts and developers discuss what they think the application should do. They fail to discuss what is the purpose of the application. They discuss how it will work, not what it should do. It's like discussing how to build a bridge, or the techical specifications of a car, without asking what they are for! The result, as before, is that the application will have to change a lot when the users start using it and discover that it doesn't fit their needs.
A friend once asked me how long it would take to create a web site with dynamic pages that would display data from a database and video chat. This was the only information provided by the customer. Instead of giving an estimate, I told him to ask the customer what the site would be about. It turned out the customer wanted to create a dating site! Now that is a very different thing from "a dynamic web site with video chat".
It is vitally important that developers understand what the application's purpose is, if only as a survival measure! Knowing the application's purpose and the users needs, you can detect missing requirements and anticipate change requests. Change request will still come, but at least this way we can avoid the "Redesign the application one week before rollout" variety. In fact, we should be alarmed when we are asked to work on a project without knowing its purpose or the users. My experience is that we should demand to know the purpose of the application and contact with the customers to ensure what we are asked to build is what they really want.
The morale: Know thy users. Ask what the application is about, not how it will work.