How should a developer reject impossible requirements?

Question

Here's the problem I'm facing:

---

Quote From Project Manager:

Hey Spark, I'm assigning you the task of developing a framework that could be used for many different iOS applications. Here are the requirements:

• It should be able to detect the thickness of the thumb or fingers being used to manipulate the UI.
• With this information, all elements of the UI should be arranged & sized automatically.
• For a larger thumb, elements should be arranged nearer the center of the screen.
• For a smaller thumb, elements should be arranged nearer the corners of the screen.
• For a larger thumb, all fonts should be smaller. (We're assuming an adult in this case.)
• For a smaller thumb, all fonts should be larger. (We're assuming a younger person in this case.)

Summary:

This framework is required for creating user-friendly user interfaces programmatically. The framework should be developed in such a way that we can use for as many projects as needed, so it must also be very developer-friendly.

---

I am the developer given this task, so my questions are as follows:

• How can I explain that these requirements are a little ridiculous?
• How can I explain that it would be better to concentrate on developing actual projects?
• How can I explain that even if this were possible, I wouldn't recommended developing such a thing?
• How do I say NO to this project politely, gently, and respectfully?
• How can I explain that even for a developer with 3 years of experience, this might not be possible?

Answer 1

If you get a set of requirements that are physically impossible to implement as the device does not support and cannot support the wanted functionality, you need to explain this to the person creating the requirements.

You should be respectful and explain why the requirements are not possible to implement (i.e. the touch screen cannot distinguish between a thumb, finger or stylus. It does not have enough resolution in order to detect finger width.) - keep things factual, pointing to existing documentation if there is any.

Do not go into any sort of emotional argument and keep cool and professional. Saying to anyone that their requirements are silly is never a winning strategy.

See if you can get an understanding of the actual goals for the feature - why it is seen as a requirement. This could lead you to a different, better feature that will solve the need. (thanks @spoike)

@DarkStar33 suggests in the comments to do the research and provide an actual estimate of how much the project will cost and how long it will take, with the assumption that the result will be too expensive and lengthy to be worth it. Being armed with numbers and the data to back them up can certainly help your case, though I would still look at the business goals to see if they can be met (even partially) in another fashion.

Answer 2

These requirements are not silly, stupid or ridiculous. This is in fact very important problem for users of touch screens, that people with larger fingers have it very difficult to pinpoint the target, which is often not understood by little-fingerers.

However, if you find this requirements impossible to implement because device's sensors are not able to measure finger size, just simply write this so: Unfortunatelly, currently available devices do not support such functionality

Answer 3

I'm going to play Devil's Advocate here a bit and say that I think it's actually technically feasible to measure the size of a person's thumb. The iPhone is a multitouch device. For calibration, you could instruct the user to place their thumbs or two fingers on the screen side-by-side, and measure the distance between these touches.

Of course this would require testing and experimentation to see how feasible my intuition is. Perhaps the thumbs would have to be dragged across the screen to get a better reading.

That said, there are serious usability and implementation issues.

• What if the device is shared? When does the calibration happen?
• How can you dynamically determine the position of the UI elements arbitrarily across all applications built with the framework? Obviously each app will have a different UI and different layout.
• A simple survey of current iOS apps shows that the well designed ones use all the horizontal space available, and already space elements such that important buttons are as large as possible and placed near the edges. The full width of the device is used for lists and layout, obviously.
• Even if it were possible, what is the cost/benefit analysis? How much would be gained from such a system compared to standard UI controls? Wouldn't it be easier to have a simple toggle control for font size like many apps already use?

Answer 4

What you do is treat it seriously and come back with an estimate of how long it would take to do and make sure the estimate is very high and very detailed so they can't dispute the high numbers. Once you have shown it won't be economical to do they will leave you alone. Make sure to point out whci specific tasks are not currently supported by the hardware and may or may not even be feasible to do. Do forget to add costs for any sort of specialists additional people you might need for a project of this magnitude.

Answer 5

People at Apple already deeply thought of all these things and they didn't come up with a resizable interface depending on thumb/fingers sizes.

As a user, I would hate moving targets under my fingers.

Answer 6

If you are worried about getting in trouble for being given impossible requirements, then the best choice is to tell them immediately that it is impossible. The longer you let them build a business plan on an impossible project the more likely they are to blame you for the failure of the project.

Above all, try not to worry about things that are not your fault, we all have enough to worry about that we do have the ability to control. If somebody were to hold you responsible for such a project failure then it is injustice against you. Do you believe in Karma?

Answer 7

One way of diverting the unreasonable request is by helping the client understand the nature of the problem they're trying to solve. Through a planning interview technique colloquially known as "popping the why stack", you continue asking "why" recursively (in a polite, intelligent way of course):

One important tool for both getting communications going and "cutting to the chase" of specific issues is what Barrett calls popping the "why" stack. This is simply to keep asking the question "why is it done that way?" about project requirements. He gave an archetypal example of what the technique can unearth: "I once worked with a client where there was a requirement that data was printed out at a particular stage in the process, so I asked why" he said. "The answer was that the department receiving the data needed to key it in. It had never occurred to them that the data could be transferred to their application automatically."

The goal is to arrive at the core business value of the feature:

• Protect revenue
• Increase revenue
• Manage cost
• Increase brand value
• Make the product remarkable
• Provide more value to your customers

(Items from Cucumber wiki)

If the feature doesn't fit one of these categories, it may help the client to see that there are either more important things to focus on, or through this thought process you may be able to advise them on how to address the problem they're trying to solve in a more meaningful way. Often the real problem lies at a higher level of abstraction than the problem they've requested you to fix.

To use your example of scanning thumb sizes:

Client: We want to detect the thickness of the thumb or fingers being used to manipulate the UI.

Dev: Why do you want to do that?

Client: Because when I try to tap these small buttons I often hit the wrong thing, and our software is used by a lot of construction workers with big hands like me. If they could calibrate the UI for their finger size, it would make it easier to use.

Dev: Ease of use would certainly be valuable to the customer, but why would they want to calibrate the UI? If the people using this are known to have big hands, why not adjust the design for that use case?

Client: I never thought of it that way, I suppose a cleaner design would work just as well for people with small hands too!

Answer 8

Disclaimer - I don't know whether your request is possible, and if it is possible then you need to determine how long it would take and provide that feedback to your manager. But I'm writing this answer with the assumption that it is not feasible, at least using the standard framework - and I'm extending my answer to the more general case when you really can't or shouldn't do something.

Just say NO.

There are many 'never say no' answers in this thread, which I believe is a soft and submissive attitude. Think about it this way - I'm the technical expert in this team, and my other team members are trying to do something that I think is unfeasible, over-complicated, potentially not possible. It's my responsibility to say no.

Of course I can & should say no gently; I can "strongly recommend against this" while offering to "investigate whether it's possible" before saying no. But I'm ultimately going to say no because that's my job.

There are so many analogies to this

• My Accountant, I want you to put my Thanksgiving dinner down as a tax deduction
• Mr Chef, I would like my chicken left on the counter overnight and served raw, please.
• My Lawyer, I want to sue my children for not tidying their bedrooms
• Mr Mechanic, please install a turbocharger on my electric car

You can ask all of these people to perform tasks that they'll know are silly, wasteful, dangerous or wrong. And you would expect all of them to advise against these actions and ultimately refuse (at least I'd hope so). If any of these professionals replied 'Hmm okay I guess we can do that' - without giving me a straight up "This Is A Bad Idea" - then quite frankly I wouldn't want to hire them anyway.

Your colleagues will value and respect your honesty, and you will save everyone a lot of time and money if you provide useful feedback rather than going along with something you know won't work.

Answer 9

It should not be too hard to tell your client that you cannot implement something your target platform does not allow you. But take a step back and ask yourself , what is the logic behind these rather riddiculous requirements? From what I can read they are very concerned about user-friendliness. Then ask them, dig a bit deeper till they say the same thing to you: "we want a user friendly interface". Then guide them into what is doable and what is not. Tell them that if they want an easy user interface there are easy (and cheaper ways) such as letting the user set the font/icon size (I assume that i possible on the IoS). Maybe you can let the user control the font size/icon size and arrangement for the application through a settings tab? That should be easier (and more accurate!) than trying to guess the age of a person on the thumb size! The last thing your manager would want is unnecessary, bloated, hard-to-maintain code that achieves the same thing that the os already provides. Tell your client that users would prefer controlling the application rather than the application controlling them in ways that may infuriate them.

Answer 10

My response would be that I would start looking into some of these untried technologies and let them know if it is even possible. Based on those discoveries, a potential development plan can be started.

I don't think you'll be able to tell one person's thumb from someone elses, but you may be able to get enough dimensions from the fingers to know when they're using the thumb. The real problem is because of the angle of the thumb it may not touch any more space on the screen than others. No one ever uses a phone with their thumb and places it flat on the screen like you're having your thumb print taken.

Leave the company. Figure out how to do it. Sell it for a lot more money than you're making now.

Answer 11

When it comes to requirements I usually do it like this: I try to estimate how long it would take to realize a specific requirement.

In case of requirements that might be impossible, ask for some days or whatever time it takes to find out whether it is possible. In your case the question is: "Is it possible to determine how thick the user's finger is?"

In fact this question is even a bit more complex: "Is it possible to determine how thick the user's finger after the first touch in less than 200 milliseconds to allow for a immediate interaction?" (replace first by 2nd or ...; and 200 ms by 300 ms or whatever...)

Maybe even answering this question takes one month. Maybe even if this is more or less feasible, it takes a super complex algorithm that only works good in 80% of the cases.

You see where I'm going?

People often make wrong assumptions about possibilities because they have low expertise and experience regarding the field in question. Therefore you cannot argument with intuition, but you need facts.

If the other stakeholders realize that this feature would take 2 man-years and requires the iPhone 10 to arrive before 2014, there will quickly downscale their requirements.

Answer 12

This sounds complex but not impossible at all; the point that the touch screen cannot distinguish between a thumb a middle finger or a stylus is moot; the user is asked at initialization (session startup, whatever) to place a thumb, then a middle finger, etc. to calibrate the sizes (make some statistical averages) using several movements, etc.

Answer 13

I'd consider trying to solve the root issue in another way before saying it can't be done.

For instance, if the user often tries to click a small button and misses, you could watch the area around the button and use that to re-calibrate all other clicks.

Presenting a creative solution like this is probably what they are after more than asking you to magically figure out the width of a finger (which you can inform them is not in the API).

It may still be difficult--placing an area around buttons to detect misses--so estimate more hours.

Answer 14

Don't outright say no as that would hurt his feelings. Just make it clear that due to technology constraints that 60% of the time it will work every time.

And once he realises the impracticality and cost involved in such an undertaking, suggest a more practical approach within his budget such as having a setting that allows you to change text size. And the Russians took a pencil into space.

Try to get him to state the problem and requirement and not the solution and design for future projects.

Answer 15

What I like to do, is to approach the problem from a team perspective. In this case the project manager and I need to come up with a solution. I also like to show that I come with an open mind. If I hear what I think are hearing impossibilities, there is a chance there is a misunderstanding between me and the project manager. Or perhaps we have not reached that aha moment.

Once we decide to take a leap and have an open conversation, I find it easiest treating the problem as an economic one. In technology almost anything is possible given an infinite amount of resources. Discussing what it would take to do, many times is the easiest way to respectfully "say no". And that would be the way to clear any possible misunderstandings. Although, to be honest, we are not quite saying no. And, what is the purpose of saying no anyway. If the work is not worth doing, it does not matter whether we want to do it or not.