Software Development With Clients In Mind

Why does it seem so hard to deliver quality products to clients? Sometimes it feels like clientseither don’t appreciate quality, or they have their priorities all mixed up. To help us understand, here is a wonderful sketch from Monty Python called “The Architect’s Sketch.”

I’ve been searching for awhile for a good example for this subject, and when I saw this sketch, I knew this would be perfect. It outlines two large problems with developing solutions for clients: quality & suitability.

In the sketch (transcript avaiable) each architect presented their solution. One was very well designed with high quality in mind. The second solution was well suited for their needs, but obviously has a sub-par quality. Which brings us to the conclusion, which solution did the developers pick? The poorly designed one of course! Why? Suitability, how well somethings fits, comes before quality for consumers and clients.

These seems rather obvious, but in-fact many developers get caught up in quality and then are totally surprised when their clients aren’t happy. Why? Because as developers we notice and respect quality a great deal more than suitability.  However, clients rarely consciously notice quality. Sub-concisely they’ll notice speed, performance, bug-free, etc. However, they don’t really realize it, it is just something they come to expect. If a software solution doesn’t suit their needs as they would like, no matter how high of quality the solution has, clients and consumers will think its poor quality.  So how can we deliver a high quality solution that also is suitable for their needs?

Understanding Needs

Before you can meet a need, you must understand it. I think software development education is severely lacking in helping students learn to understand client needs. There is a lot of education on theory, best practices, and technologies like programing languages and database design. However, at the end of the day, these techniques fall under the “quality” category. Don’t get me wrong, all these skills are extremely important and deserve the time and effort they receive. But what about suitability? I don’t care how well a program is designed and coded if at the end of the day it doesn’t suit my needs.

This is what my current boss calls the “get it” gene. There is so much more to software development and design than just under the hood. Like I’ve said before, clients and consumers don’t really care whats under the hood as long as it is working. For them their number one concern is having their needs met. Have you ever received a specification, followed it exactly, only to have your boss or client turn around and say that it won’t work for their needs? It has happened to me, and its extremely frustrating. It feels like such a waste of work many of the times.

Developers who “get it” do more than follow specifications. They can visualize the people who will use it and understand what they need. Specifications are usually just a good outline, and when following it a developer needs to ask himself these questions as he works:

• What are the needs of my end-user?
• Why are they doing this?
• Is this a practical way to accomplish this task?
• Is it easy to understand and follow?
• How often would they do this task?
• Can they do it in a reasonable amount of time?
• Does this make my client more productive?
• Is this really filling their need?

I know of a software development company where in the 80s they created a software product for video rental stores. They wanted to be different from the rest of the competition. Everyone else used the keyboard as their only method of interfacing with the program. However, the mouse was becoming a popular standard with computers, so they decided they would use the mouse to navigate and execute transactions instead of a keyboard. They worked hard, created their first version, and released it.

There was just one problem: it took a lot longer to use the program than the competition. While one person had to move and click across the screen for just about everything, the competition could quickly use keyboard shortcuts and do the same thing in 1/4 of the time. In a retail store, if it takes 4 times longer to get customer through checkout, it is a serious problem. Not only that, but it was more work moving and clicking the mouse.

In short, while the interface was sleek, elegant, and it was easier to train, it didn’t fit the primary needs of their clients: check out clients quickly. This repetitive task wasn’t quick enough. Imagine if your IM client required 5 steps to send a message. You wouldn’t use it, it would a giant waste of time.

How To Become More Understand

I’ve jotted down a few ways a developer can work on becoming more understanding:

• Meet the Client – I would suggest any key developers who will be working on the client’s project should meet the client. Developers should feel free to ask questions to help them understand better the project. I suggest the developers be briefed first by the project manager, ask him questions first, and then any unanswered questions can be asked to the client. I’ve also believe that putting a face to a name always makes business more personable.
• See the Need – If at all possible developers should go and see the need that they are trying to fulfill. If you’re working on a Point of Sale program for an automobile supplies store, try and visit the client and see where your software will be at work. I remember working on a tool to help prep kiosks for deployment. The client sent pictures of the work area, and the lead developer went to visit the warehouse. See the environment helped the entire team understand the needs and challenges we faced, and helped up create a better product.
• Open Communication – There should be one point of contact with the client where questions can be asked. If there is something you don’t quite understand or isn’t clear, the Project Manager should be able to get answers in a timely fashion to keep things moving along.
• Frequent Client Feedback – This can be a double edge sword, and expectations about “feature-creep” should be set and kept. However, showing the client regular progress is important. Getting feedback during the entire process will actually help eliminate feature-creep at the end. While testing in the Alpha and even Beta stages of the project can be hard, using tools like Camtasia and Jing can help get feedback from clients when change is easier to make instead of a day before the deadline.
• Usability Testing – Try to have an environment that is easy to quickly perform usability testing. This should be done throughout the entire development process. Like I’ve said before, its easy to make small changes as you develop. However, making a lump of changes at the end can be expensive and frustrating.

From jr. developers to project managers, it is important to understand the needs you are supose to fullfill. The reason computers and software has become to popular is its ability to make our lives easier. Focusing on all aspects of software development, and not just the technical aspect, can make the difference between an okay developer and a great one.