What to do with a stupid client request?

Question

I won the bid on a project and now the client (who is itself from IT Department) wants me to architect/implement the solution in a very particular way. I am sure the application will fail that way for performance problems. And it will not be easily scalable.

This particular client/user does not know ANYTHING about the platform and language I will be using (ASP.NET / SQL Server). His only knowledge is in Cobol and trying to make him to understand my POV is just making him angry.

He contacted me. He was the person who selected me as a winner on the bid. He is who will be approving my checks. He is my only contact with this company.

I do not feel comfortable with providing a solution I know will fail and I do not want to be known as the stupid programmer who make it fail. I do know their real needs and usage patterns for this application because I have done projects for them in the past.

On the other hand, doing this in his way will just extend my contract more time (so, more financial gains) in order to solve the problems by modifying the code.

Should I resign from the project knowing that probably I will be losing this client forever?

Or…

Should I take the pill and take financial advantage from an extended project and just assume the bad fame as a cost?

Answer 1

You're looking at this from the entirely wrong perspective. This isn't a stupid request from a client who doesn't know anything about technology. It's a design constraint that you think introduces risk into the project.

So you do whatever you do when you encounter risk in a project: Define it, assess it, and recommend a mitigation strategy.

• Define the risk. Saying it will cause "performance problems" and "will not be easily scalable" is not defining the risk. You need to specify exactly what you mean. What isn't going to perform, and why? What changes in scale will will encounter these problems?
• Assess the risk. Okay, so you think there's a problem. How bad is it? How certain can you be that these performance problems will actually happen? What will the impact be on the users if they do? You say the program can't scale: is the growth in scale that will expose the design defect even in the cards? Most importantly, how do you know this? Here is where taking the time to build and benchmark a prototype can save you a lot of pointless argument.
• Recommend a mitigation strategy. What's the right way to implement this? Why is it the right way? Again, how do you know this? Again, prototyping is your friend.

A couple of things will come out of doing this exercise.

First, you may discover that while you're right about every particular, when you put them all together it doesn't matter. Yes, this program's not going to perform well or scale well, but if none of its projected use cases are going to run into those problems, it could easily not be worth solving them.

Second, there's a world of difference between telling someone "This isn't going to perform, I just know it" and telling him "I benchmarked the use cases that we expect, and it looks like this approach is going to result in four- or five-second response time per user transaction."

Third, if you know what conditions will make the software fail, and you articulate these concerns to the client, and the client says "We really just want it to work this way," you've discharged your responsibility. If this fails because the client chooses not to mitigate the risk you've identified, nobody can point to you and say it was the programmer's fault.

Above all, evidence trumps opinion. You've framed this entire question as a case of your opinion versus the client's. That's a losing proposition. What you need to do is frame it as "here's a problem that we need to solve." And to frame the question that way, you have to demonstrate the existence of the problem, and for that, you need evidence.

Ultimately, it's the client who decides whether or not a risk should be mitigated, not you. It's up to you to give him the best information you can to support his decision. And you need to make it clear, without being a dick about it, that it's his decision.

I've found, on more than one occasion, that a simple email focuses the attention perfectly:

I've been reviewing the design, and I think there's a risk here that we need to discuss. [Approach A] is really sensitive to transaction volume, and I'm worried that we're going to have enough users that we're going to run into trouble with it.

I ran a little test using [Approach B], and it's a lot less sensitive; in my simple prototype, I was able to get X transactions per second out of it. This makes sense, because [technical comparison of how the two approaches handle things].

I'm especially worried about this because [describe how program will fail if it performs poorly].

This seems like a significant problem to me. If it were me, I'd use [Approach B], because [describe how this approach will mitigate the risk].

But you're much more familiar with [Approach A] than I am, and I'll happily defer to your guidance on this matter. What do you think we should do?

This message very clearly says "If you disregard what I'm telling you, here's how the project is going to fail, and I'm going to have documentation demonstrating that you told me to do it that way." It also doesn't actually say that.

Answer 2

I think you will need to sit down with him, and ask some clarifying questions.

You will need to get at WHY he wanting to have it implemented in that particular fashion. You need to demonstrate that you are wanting to deliver a working solution that meets the business needs.

It's possible there is some underlying concerns, issues that need to be addressed, as you stated he may just not be familiar with your proposed technologies and needs some reassurance.

Failing that make sure things are fully documented and signed off on.

Answer 3

Option 1: Walk away, you already have a bad relationship and it is unlikely to improve.

However, don't do it because you want to prolong a contract, that is at best sly and at worst dishonest, but if you need the contract...

Option 2: Ask him to document his architecture choices and reasons and sign them off as a spec. Add a clause to the contract saying that you do not guarantee performance and/or scalability using the spec he has produced and then implement it his way. Send him a presentation of your favoured approach and reasoning.

If the project fails (he could be right) then you can always point out you told him so and offered an alternative.

Make sure that you implement his architecture in good faith, i.e. don't make it fail deliberately. Do early tests which prove your point and make sure he knows that they are failing. Give him clear written warnings throughout the lifecycle of the project that it is going off track.

Best of luck. Seriously consider option 1. An off-the-record heart to heart with the guy is worth trying.