In the software programming world, particularly custom software, many debates rise between clients and programmers. These constructive discussions tend to focus on how a specification should be reflected in the upcoming software. The question is: is the client always right?
The client pays the bills so in the end so whatever happens he'll have the last word. This being said, its important to listen to both point of views because they both bring important and distinct information on how to tackle the problem.
Here are a few examples of typical views in these debates:
1- The programmer wants to build the simplest possible solution
This is quite frequent. If you ask a developer how to build a particular specification, chances are, he'll suggest the easiest "technical" solution. This might be the easiest solution and also the cheapest solution (in direct costs) but it isn't necessarily the most effective.
This kind of thinking has put forth some great technical software designs on an engineering standpoint but horrible in terms of user experience and efficiency.
Good examples for this are the operating systems in smartphones. Before the IPhone, smartphones had evolved capabilities such as email and web browsing but they were so un-user-friendly, that they were very scarcely exploited. Why? Because the designers thought of functionnality first and user efficiency second. Apple changed all that by providing tools that were, yes a little more powerful, but immensely more user-friendly.
As a matter of fact, Apple revolutionized the whole way of thinking in terms of customer based approach for technological devices. A device with the same kind of hardware will be WAY more profitable if it offers a more ergonomic interface than its competitors.
2- The client is not aware of the importance of data integrity
Obviously the programmer isn't always wrong. Let's take an example to illustrate this point: customer management. Every other software manages customers (add, remove, edit customers, etc). Whatever the software, the customer is usually binded to other entities such as bills or orders. One of the specification a client might ask is to be able to delete a customer. Its obviously technically possible but what will happen to all the binded entities? Should the bills and orders not refer to that customer anymore? Obviously not. If we did, we would be left with bills and orders that point to no customer. This is a clear example of going against data integrity. I won't go into details, but as a programmer that is the most important thing to avoid.
For a programmer, this kind of "data integrity problem" is obvious, but it won't be for a client. The solution to this particular problem is to find a way to remove the customer without affecting the data integrity. The typical solution is to allow the customer to be archived. The data is note deleted per se, it still exists in the database, but it won't be visible through certain user interfaces. This is a simple example to illustrate my point but this can get quite tricky with large software solutions.
3- The client is not aware of the cascading consequences
"All I want is a list of my employees". This may seem like a pretty straightforward specification but many questions will derive from it: Can we sort this list? Can we filter it? Which information should we see for each employee? How many should I see per page? All? And if there are 50 000? Do I want to export this list in another format (excel, pdf)? Etc.
As you can see, the basic specification can have many cascading specifications related. The discussions between the client and the programmer will help the client evaluate what the range of possibilities is and allow him to make an informed decision.
It's a bit like going to a car dealership and asking: "I want a car." A car can cost as little as $10,000 but can also be worth more than $100,000.
4- The programmer does not predict the user interactions
When we develop a software, we use it in a certain way through our tests. Since we built it, we use it as it "should" be used. But the end-user does not know how it was built and therefore does not know how to use it. He'll use it the way he thinks it should be used. And that's normal!
Its the responsibility of the programmer to take the time to think of the different ways the software can be used and to guide the user through an ergonomic software to use it the right way. But even by trying to predict how users will use it, we're always surprised at how they end up using it. Its therefore even more important for programmers to sit down with end users after releases or pre-releases and explore how the software is used. This will help improve the software according to the different users and their feedback.
What we need to remember through all of this is that good communication between programmer and client is essential. These kind of debates are not bad. On the contrary, they must take place. In the long run, the results of these discussions will help build a stronger, more efficient software.
UX (User experience) is a specialty that is born through these kind of debates. The UX specialist works between the client and programmer to help find the most efficient design for the client while taking in account the programming constraints. This will help the client get an ergonomic software that meets the data integrity requirements.
