10   Let Customers Make Decisions

“Developers are creative and intelligent and know the most about the application. Therefore, developers should be making all the critical decisions. Anytime the businesspeople butt in, they just make a mess of things; they don’t understand logic the way we do.”

Developers must be involved in making design decisions. However, they shouldn’t make all the decisions on a project, especially the business decisions.

Take the case of project manager Pat. Pat’s project at a remote site was on track and within budget—it appeared to be a textbook example of a stellar project. Pat cheerfully took the code to the client site to demonstrate but came back crestfallen.

As it turned out, Pat’s business analyst had fielded all the questions personally, rather than discussing them with the users. Business owners were not involved in the low-level decisions made throughout development. The project had a long way to go before completion, and already it fell short of the users’ needs. The project had to be delayed and became yet another typical textbook example of project execution failure.

So you have a choice: either you can let the customers make the decisions now or they’ll go ahead and make the decisions later—at much greater cost. If you avoid these issues during development, you increase risk; but by addressing these issues early, you avoid the possibility of significant design and code rework. You can also avoid mounting schedule pressure as you approach the project deadline.

For example, suppose you are working on a task. You think up two ways to implement it. One way is quicker but will limit what the users can do. The other way will take more time to implement but gives more flexibility to the users. You are obviously pressed for time (have you ever seen a project that isn’t?), so should you just go with the first, quicker option? How do you decide? Toss a coin? Ask a colleague or your manager?

In one of Venkat’s recent projects that faced a similar problem, the development manager decided in favor of the first option to save time. As you might guess, the customer was shocked—and furious—when these limitations surfaced during beta testing. The resulting rework cost the team much more money, time, and effort than necessary.

The most important design decision a developer (and a manager) can make is to decide what’s not in their hands and to let business owners make decisions on those issues. You don’t want to have to make decisions that are business critical by yourself. After all, it’s not your business. If the issue at hand affects the behavior of the system, or how it’ll be used, take it to the business owner. If project leads, or managers, try to make those decisions by proxy, politely convince them it’s better to take this up with the real business owners/customers (see ​Damn the Torpedoes, Go Ahead​).

When you talk to the customers, be prepared with the available options. Present them with the pros and cons and show the potential costs and the benefits—from the business point of view, not the technical point of view. Discuss the trade-offs and the impact of the options on the schedule and budget with them. Whatever decision they make, they’ll have to live with it, so it’s better that they can make it on an informed basis. If they want something else later, it’s fair to renegotiate the cost and time for that change later.

Either way, it’s their decision.

Let your customers decide. Developers, managers, or business analysts shouldn’t make business-critical decisions. Present details to business owners in a language they can understand, and let them make the decision.

What It Feels Like

Business applications are developed as a partnership between the business owner and the developers. It should feel like a partnership—a good, honest working relationship.

Keeping Your Balance

• Keep records of decisions and the reasoning behind them. Memory is notoriously unreliable. An engineer’s journal or log, a Wiki, an email trail, or an issue-tracking database are all acceptable, but take care that whatever method you choose doesn’t become too heavy-weight or burdensome.

• Don’t bug busy businesspeople with trivial low-level details. If it doesn’t impact their business, it’s trivial.

• Don’t assume a low-level detail doesn’t impact the business. If it can impact their business, it’s not trivial.

• “I don’t know” is a perfectly acceptable answer from a business owner. They may not have thought that far ahead yet or may need to see it in action to evaluate the issue. Advise them the best you can, and prepare the code for the eventual change.