How to politely state that a software requirement is infeasible? [duplicate]

Question

I work as a software engineer for a small software company. One of the things I've observed is that a lot of the system requirements that come my way are based on the whims of the boss and never thought through from a technical standpoint. My manager simply nods along and hands me the requirements.

This puts me in the precarious position of going back to my manager, and periodically to the boss, with the news that the system cannot be built because, say, the architecture does not support it, or the route that boss wants to take is just a figment of imagination and downright not doable from an engineering standpoint.

While I do understand that feasibility study is the manager's task, I am, be as it may, the one who has to do it. What is a polite way to tell that a system cannot be built?

Answer 1

Very few things in software engineering are actually infeasible. They might take a lot of time and/or cost a lot of money, but most things can be done eventually one way or another. "The architecture does not support it" is in fact "this would take X months and need Y people". Your job is to estimate X and Y, your manager can then work out how they want to resource the project and/or communicate to their boss how much extra resource they need.

Answer 2

It really depends on how well you can explain the technical barriers and how well those you are explaining those technical points to understand them. It's not uncommon to be in this sort of a situation where a requirement is not feasible within, budget, time, framework, etc.

Your job as a technologist often is to find a way to explain these types of things in a way people who have less technical knowledge or even just less domain experience in a way they can understand.

Two of the best ways to do this are numbers and analogies

If something is technically unfeasible for example due to time it would take to execute a script, explaining the problem in big-O notation for example likely isn't helpful. But if you present it as "the system needs to scan 30k records and for each record needs to reference all other records the number of operations the code has to take is 30 000^2 and if each takes 0.05s to run to execute the whole function will take 4 500 000 seconds or just under 2 months to complete. Big numbers can easily be used to explain these things in a non technical way with such a constraint.

Similarly analogies are handy for explaining technical barriers. Likening your problem to even a weakly analogous car example would be a good way to simplify the problem to a stakeholder who is a car guy. for example stating "Well it's like an engine, at a certain point if you want to get any more horse power you are just going to need to swap out the entire engine. You can squeeze more power out with tuning and after market upgrades but there always will be a cap on any given engine"

Answer 3

This is why most functional software companies have tech/engineering leads; they are people with domain expertise in technical matters who management trusts to make technical decisions for the company that the business management might not be equipped to understand. It sounds like your company doesn't have such a person. So in lieu of that, you have to make yourself that person, and make management understand that you are taking that role.

Which is basically to say, you have to ELI5 (Explain Like I'm 5 years old) everything to management. When you explain why something can't be done, explain it in excruciating detail so that they understand that you're not just lazy or jerking them around. It's important in your question you used the word "infeasible", because this is descriptive of most software problems: You can refactor this 15-year-old application to do this thing, but it might take 5 years to refactor; does your company want to budget 5 years of your salary and 5 man-years of your time to doing this? Or else, someone else might be able to do this but you don't have the expertise; this comes up a lot e.g. when the company hires a backend Java developer and they want to build a fancy, flashy looking website. Or when they want to do some big data stuff without a data scientist. Or when they want to do ML without an ML engineer. Mostly because they don't actually know the difference, they hired a "software engineer" who they thought can do everything, because "it's all just code right?", and they need to be educated on what they missed.

So basically, you need to identify where the shortfall is. Is the application too large to refactor to add in the required support and they need to allocate time, money, and manpower? Is the domain of the problem something outside of your expertise and they need to hire a specialist? Is the level of infrastructure provided insufficient and you need more budget to buy more servers? First identify that with management and then see what they say, but the most important thing is to come to them with a very specific and detailed reason of why the thing is infeasible right now and what you would need to make it feasible. Even if the thing you need to make the infeasible thing feasible is itself infeasible, at least it's an action item for management to take and consider; they can say "sorry, we can't afford a million dollars on infrastructure that you're asking for", but they could also say "yeah sure here's a million bucks go buy a server farm", and that's their call to make not yours.

Answer 4

Money

While I do understand that feasibility study is the manager's task, I am, be as it may, the one who has to do it. What is a polite way to tell that a system cannot be built?

Your bosses do not care or understand technology. There is no point in expecting them to beyond a very rough overview. If you want to persuade them to do something or not do something you need to speak a language they understand and respect : money.

So while you might explain very briefly that what they want to do is not practical or (in rare cases) actually impossible for technical reasons, you need to focus (and headline) the cost of trying in terms of :

• man-hours required, resources required and people required
• realistic timescale for achieving goals.
• hours lost to other more potentially useful projects
• long term costs for maintenance of the work
• relative benefit compared to other proposals
• impact on company reputation for missing other goals and commitments to focus on the proposal.
• impact on bread and butter operations like bug fixing and incremental changes requested by key customers.

If possible you should also make a suggestion or two about a limited alternative that is practical and has reasonable cost-benefit to the company.

An important issue to be ready for is the argument that someone may make that "we would become industry leaders if we do X". This is a common management delusion. You need to be ready to explain that the goal may not be practically achievable and/or would involve such costs that it would endanger core operations and is likely to undermine the existing revenue generating operations.

It is important to learn to think of your own activities as revenue generating. It has been my experience that many people in management will act as if development are an inconvenience that costs money but contributes nothing. This is in part because engineers generally fail to speak to mangers about money. You must speak their language and that language is cost and money and profit and loss.

Answer 5

When you are a technical person working directly with non-technical people, your job is not just to write the code but to help educate as best as you can (without being condescending) and to understand what the end goals are. Requests almost always have a reason behind them and, sometimes, the request is a XY Problem where what they are requesting is a solution to the problem that they see with their understanding of the system. Sometimes, simple requests like "Can we export to excel?" hide the actual problem "This table doesn't show totals ."

If a request comes down that is NOT feasible like "I want my Youtube views and FB share counts to show on Twitter" you need to:

1. explain why it is not doable
2. determine the actual goal
3. offer an alternative if possible.

You: Unfortunately, we aren't able to do that because Twitter doesn't let us manipulate the counts, but why do you need twitter to have Youtube views and Facebook shares?

Boss/Manager: Because our page shows the Twitter button but it doesn't include most of our shares.

You: Okay, we a have couple options then:

1. we can add FB / Youtube buttons also
2. or we can pull numbers via the apis and show them separately

Is this so user's can see popular articles?

Boss: Not really, right now our authors like to look at the page to see their shares for motivation, but they have to go to Youtube and FB directly.

You: Perhaps, we can make a dashboard for the authors to see?

Frequently, the business person doesn't care how something is done so any direction on how something is done is usually them offering a solution to a problem with only partial knowledge.

You need to get into the habit of finding out the why for the rest of your career. At the beginning of a career you have to do this extremely diplomatically, but later in your career or after you gain respect of the people you work with, you can be a little more blunt. (At this point in my career, if I get a request or question out of left-field and don't understand why it's being asked, I won't answer until I understand why it is being asked. Occasionally, it can cause them to react rather negatively, but, in most cases, they understand why I do it and become used to it.)

Answer 6

In my experience as a software engineer, sometimes a task that was given to me was either actually infeasible given the budget and time limit of the project or actually a misunderstanding between the developers and the business manager. I would recommend ensuring that you understand everything that is being asked of you (such as what task should be performed, what approaches management wants you to take, etc.).

In my experience, I was asked to determine attributes of text based documents. The task, when initially given to me, sounded like a complete utilization of AI/ML/NLP technologies that would take months to fine tune and more to gather data for, before even showing it to the user. During a meeting with my boss to go over how the task seemed infeasible, I explained why I thought the task was infeasible, outlining the technologies that I would need to take, as well as what I understood was being asked of me. My boss clarified what he wanted and, after outlining some approaches that I felt would meet the newly clarified requirements and him agreeing to them, I realized that it actually was feasible to produce the project.

In summary, meet with management to go over how you understand the requirements and see if there are any clarifications that need to take place on their side. If they have the same information as before, follow through with the advice that the other answers have given you, such as providing numbers for the relevant budget costs, personnel needed, the appropriate amount of time you will to complete the project, etc.

Answer 7

What is a polite way to tell that a system cannot be built?

Provide documentation.

If there are some sort of technical reasons preventing a system from being built, there is likely some official documentation stating/explaining the reason(s). Provide this information to your manager in a detailed and clear report.

Also, you should attempt to offer ideas for alternatives to reach the desired goal. This is to let your manager know that you aren't just trying to avoid doing tasks that are assigned to you.

Answer 8

What is a polite way to tell that a system cannot be built?

No there isn't a good way to say that in your position. It only makes you look either incompetent or uncooperative.

While I do understand that feasibility study is the manager's task, I am, be as it may, the one who has to do it

And building things is your job and working on a 5 year project to make something difficult happen is actually very interesting work. If a requirement needs a lot of work and re-architecting, that is not a problem for you. It is a problem if your management believes a 5 year project can be done in 3 weeks and breathes down your neck if you take any longer..

The way around it is to properly manage expectations of your managers. If you get handed a requirement that is hard to do, be sure to give a conservative estimate on how much time it may take and also give them an estimate on how long it will take you to get more clarity. "This will probably take between 1-5 years, depending on X and Y. I can get more clarity by doing Z, which will take me 3 weeks. I can get started on Monday."

It might be very likely that giving a 5 year estimate will have the same result has saying "it is infeasible", but by giving a figure you will leave that position to your managers. From the managers point of you is very frustrating to hear "This can't be done", because it takes all options. Maybe your manager needs your project to solve a higher level initiative and all options have someone saying "this can't be done". But in the end you need to be able to compare the "this can't be done" from engineer A, to the "this can't be done" from accountant B to the "this can't be done" from legal council C and the "this can't be done" from operations specialist D. Your manager doesn't want to go to the board of directors and say "We can't move forward, because Stacy in engineering said so." Your manager wants to give a detailed cost analysis of all possible options and come herself to the conclusion that project is currently infeasible. And there also is a chance, that your managers are willing to pay the price tag you are giving them, because of reasons that you don't know.

Giving a good enough estimate will help your manager to do their job and help you to look capable of creative problem solving and higher level analysis.

Answer 9

As an employee, as far as i understand, it is our job to make things happen.

Not sure that requests are so outrageous and dreamed out. You haven't provided an example :)

They may be expensive, but cost is usually responsibility of the different department.

I would suggest that you submit your report with required hardware / software, including their respective cost to get the job done.