How to deal with requests for ridiculous functionality in your software? [closed]

Question

Of course, most of the time this type of request comes from management that neither has a clue about what the users really want, nor does [s]he have a clue about the technical aspects of building a specific software project or software in general. See Dilbert's Pointy-Haired Boss for more detail.

However, that's just one aspect. What about requests for items that you know will hurt overall performance of the system you're building? Or how about the technical idiot who's foolishly been given authority and yet nearly everything they do turns to dook? (See this post for an awesome example)

Ultimately, how do you eloquently, professionally and gently deal with requests or edicts to what you're building that you know will ultimately hurt the project?

---

Dupe: When the Client asks for something ludicrous and insists

Fourthclass

I did quite a bit of looking around before posting. Sometimes one just can't find a match on the same words others choose to use. – Fourthclass

This question appears to be off-topic because it is about workplace politics. – Naima

Answer 1

A good software designer will restrain from calling a feature request ludicrous. You've got to trust your gut feeling, but it's just a good indication that you want to consider the problem carefully.

I suggest a simple model:

1. Try to understand what the actual problem is, not the solution the user is asking for. The golden design rule "Don't discuss solution with the client, discuss requirements".

2. Be able to explain where in your opinion the problem with the proposed feature lies. Paul Graham has an excellent piece called "How to Disagree".

These two simple steps will help you and users to deepen the understanding of the actual problem. Software is meaningless without users, most of us depend on users paying for it. Work with the users instead of alienating them with an attitude that may appear insulting.

Some "ridiculous" feature requests have their roots in very intresting and hard to solve problems.

Magruder

Answer 2

Always relate any request to money. The people that come up with these requests are usually more concerned about money so make sure they are aware that it will cost them more because:

• it is going to take longer
• it is likely to introduce more bugs
• it is likely to slow down maintenance
• it will slow down development of new features relating to it

Penance

I'm afraid it's too abstract talk. People generally not care about what will happen tomorrow. They just want it right now. So only thing is when you say it will last a long time to implement that. – Superstratum

I'm with Mastermind, on this one. The above points are true for ALL features. People need quantifiable reasons. – Kutzer

time is almost always more important than money for people who quote ridiculous things in my experience – Salts

Answer 3

I find the phrase "shall we do that in phase two?" works wonders, possibly backed up with "I think we can manage without it to start with - let's get something out the door first".

Monstrosity

I used that phase two phrase in place of "I will never do this." – Tilbury

Oh yes. Features often get bumped to phase 3. I don't think I've ever seen them survive longer than that before the client forgets them altogether. – Monstrosity

Answer 4

Your weapon of choice should be the estimate. Ridiculous functionality, usually comes with a ridiculous estimate. When must have feature X gets a 3 man year estimate, it magically turns into, nice to have feature X.

Kutzer

Answer 5

If it is a customer and technically possible to do, and you can do it, get a statement of work - and do it.

If it is a job you have, you do the same as anything else. You say, "Yes, sir (or ma'am), I'll be happy to do that. And I don't mind doing it at all. I just thought you might want to know how this would impact our other systems or budget. Not saying you're wrong, just saying that maybe we should think about this a little bit. Is that okay?"

If they say no, well, they signed off on it and you do it. If you really concerned, document your conversation where your advice was not heeded. Remember, if you don't document it it didn't happen. If they listen, then you win a friend.

This would be the same for any job - computer, construction worker, whatever.

EDIT:

I took this from my comment below:

Doesn't anyone watch Star Trek anymore TNG or TOS? Remember Number One would let Captain Picard know of anything wrong and sometimes Jean-Luc would agree and sometimes he wouldn't. That's all I'm saying

Rivkarivkah

It's a pity someone downvoted this and didn't take the trouble to say why. This is an interesting answer and given the subjective nature of the question this answer ins't "unhelpful". The downvote really does need some explanation here. – Paniagua

I thought so too but didn't want to whine. I like the website but it's not worth a religious debate. I find it sad that good old respect is discounted. I guess I think more of the people involved than the project - unless it were a moral problem with the requests - I'd kindly remind my supervisor and then do what I'm told. Who knows...they might be right. – Rivkarivkah

-1 and here's why: a) People don't behave like that, being subservient is only helpful in the military, if anyone expects you to treat them like that, they should be fired . b) A construction worker is a bad comparison to a software developer. Sorry, all jobs are not created equal – Kutzer

People are relying on you to be the expert in the field of software development - therefore if something is technically possible it does not follow that you should do it as you expert opinion may state that the feature compromises the rest of the application - your client/superior may not know this and you should not, therefore, always accept work just because someone is paying for it or telling you to do it. – Penance

Greg, maybe you can learn from the military then. Construction work is a great example. If the supervisor said to dig here and there was a gas line, and you told him, and he said dig anyway - you shouldn't do it. That's moral. Disagreeing because the trench should be a certain direction because you think it's best is different. Let him know respectfully, see what he says, and do it if he says so. You should always respectfully submit when it is appropriate for you to do so. – Rivkarivkah

Paul, I am not saying to "always accept work." I am saying politely remind the person giving the orders of your concerns and if they do not agree - do it anyway, unless there is a moral reason not to. When you get to be the manager, you'd want the same thing. Doesn't anyone watch Star Trek anymore TNG or OTS? Remember Number One would let Captain Picard know of anything wrong and sometimes Jean-Luc would agree and sometimes he wouldn't. That's all I'm saying – Rivkarivkah

Answer 6

I would take the time to listen politely, if there is more than one request ask them to prioritise them and get the request in writing, idealy "signed off" or whatever procedure you have. Then tell your manager / customer that you will review the requests and get back to them with estimates and the impact it will have on your schedule. Explain that just to produce these data you will need to take X number of hours (or days) and therefore your other work will be delayed...

Then come back with estimates - if the request was ridiculous then your estimate is likely to reflect that:-)

If your manager / customer wants to proceed and waste lots of time and money then at least you have made it clear up front and you have done what you can to help them.

If at all possible you should ask them to defer such requests until a future phase, suggest you look at it in the next version (I think a couple of other replies mentioned this idea already).

Paniagua

Answer 7

These are all good answers. You need hard data (if it's possible to generate it), "believably ridiculous" estimates, and, most of all, respect.

Johnny's answer was right on in essence, if not in the exact words (I'd comment if I'd built enough rep). In some cases, though, using those exact words might create enough dissonance to get the requestor to take a second look at the content of your objections. And yes, this applies to any project-based endeavor: software, advertising design, even (gasp!) construction. Not that the grunt carrying the mortar will have the grounds or clout to object to flawed design, but the construction lead does have an obligation to tell the architect if his plans are unbuildable.

If all else fails, document the discussion & build it anyway. It's no longer your responsibility.

Priggery

Answer 8

Ridiculous feature requests fall into two camps for me when responding to them.

1. Feature will cause the application to stop functioning as expected, i.e. breaks it, slows it down too much, makes it unworkable
2. Feature that will not cause the application to stop functioning as expected but I don't understand why you'd want such a feature

For type 1 I'll analyse the request and respond with either hard facts or professional opinion. If the analysis indicates that it may be possible with additional effort on existing code then estimate and estimate high!

For type 2, firstly I'll ask the requestor to explain the feature in more detail, after all they may work in an area of the business that I don't have a clear understanding of beyond the problem space for the original application spec. If I still don't get it and I really cannot see the purpose of the feature then I estimate high to discourage them.

If they accept the estimate or I do, finally, get it then I do it.

At the end of the day, they are the customer and if a customer goes into the tailor and asks for trousers with 4 legs, the tailor may argue for a while but in the end it's a custom job and far more expensive. So if they see enough value in the feature that they are willing to pay be willing to take their money; just because you can't see the value doesn't mean they are wrong.

Outpouring

Answer 9

I think the only thing you can do is very concisely describe the major issues that the change request will bring up to the people involved. At my place of work we have the same problem as you do.

Some of the change requests force the developers to jump through hoops just to get it done and in the end it results in less maintainable code for a feature someone upstairs thought would be a good feature.

In my experience there is really nothing you can do to stop this and eventually management will start complaining about how long development is taking etc etc. It's a horrible crappy cycle which will either end in the site being re-built or your team spending eternity in code hell.

Good luck.

Thrombocyte

Answer 10

There are different kinds of "ridiculousity".

• It's too expensive: I argue that the customers need must be worth the money to spend
• It's just unnecessary stuff: I try to explain that the customer can't use it. If they still want it, they can have it.
• It's against existing concepts: This is actually "too expensive" of the kind "unaffordable". They won't get it.

I like to discuss about requirements :-)

Edit:

A Typical discussion

• Marketing Guy: Next to this table we need a button to provide function X to the selection.
• Developer: But we need additional parameter P for function X
• M: Parameter P is obvious is many cases
• D: But we have to cover all cases. We need to prompt for P
• M: No! Users don't like to be prompted for obvious values! They just want to "click and go".
• D: It's impossible in this case. We need to prompt.
• M: (accommodating) Can't you guess it and only prompt if really really necessary?
• D: It's hard to guess reliably. Actually takes weeks or even month to implement and it's a high risk. What if we guess wrong? We'd need artificial intelligence for this.
• M: But it's very simple: Always in case blahblah, we know P
• D: Yes, sure, but we don't know what the user knows.
• M: Hm. You developers are always so complicated.
• D: ...
• M: So, can you do it or not?
• D: No.
• M: Why?
• D: (irritated) I just explained. After all, do you think the user likes that the system guesses P if he actually wants to decide?
• M: You just have to guess what the user decides.
• D: But where do I know?
• M: It's this situation blahblah ...
• D: I know, but it's not as simple as that.
• M: Ok, I go to the project leader, he will give you a task.
• D: ...

Hispanicize

+1 for the word "Rediculosity"! Awesome!!! – Fourthclass

Answer 11

I find that most of the time people asking for the impossible don't realise why what they are asking for is such a problem.

Generally, I just ask for more and more clarification of the requirement and more and more detail until:

• A lightbulb comes on in my head, I realise what they are trying for and I can say "ah, what you really want is X, not Y". At which point they will generally say "yeah, that's what I was saying all along".

• They realise how unrealistic they are being and they withdraw the request

• You jointly realise that it would be really good but it's not possible. Usually, in my experience, that one happens because you'd need to make a change to a large closed-source application - in which case, you just make it a feature request to the supplier, which is more satifying for non-techies that for techies; Microsoft don't make changes to Excel because one small firm asked them to!

Exine

Answer 12

Customer created requirements can be a major cause of this problem. The issue is that the customer sometimes tries to do a software developer's job.

They have a problem and then work out what feature they will solve that problem. Unfortunately some (most) of these poor souls aren't very good at software design hence you get a very curious feature at the end of it.

A way to remove some of these kind of retarded features is just via the recursive .Why() function. Keep asking why until you find their problem and then design the feature yourself. In a lot of scenarios you can re-design it in a way that is simple, inexpensive and satisfies all parties.

---

There are also times where what seems to be a ridiculous functionality request does actually pan out to be a good one. There are times where software developers (and I have caught myself doing this in the past) say no to a reasonably complex but highly useful feature that will make the company a lot of money. So when you encounter a "ridiculous" feature be sure to calculate its potential value to the business before instantly dismissing it.

Gonocyte

Answer 13

We have sometimes such requests coming from product managers.

In one case I explained there were going to be performance issues and the senior guy confirmed that so we won.

The next time and raised a similar concern but the senior guy wasn't available, so I just did what they wanted because noone really cared. I decided no to as well.

You probably mean things like sending a multi-criteria request to the database, showing the results and at the same time showing which one of all those criteria had a hit. Guessed it?

Superstratum

Answer 14

• Sometimes you can explain why the functionality is ridiculous, and the functionality is dropped.

• Sometimes you can get someone more senior to say "no" for you.

• Sometimes you are senior (or influential) enough to say "no" for yourself.

• Sometime you can say "yes", but give the task a low priority (and never do it).

• Sometimes you just have to get on with it.

In the latter case, you should make sure to do the task very, very well indeed. Why? You will shine, and as you do so, the shadow of the ridiculous will be brought into focus.

Berube