47

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?

5
  • 13
    Why can't you just write a report for your manager? – Kilisi Oct 23 '20 at 12:31
  • @JoeStrazzere In an attempt to be polite, I just demonstrated the feasibility analysis that I did on a dead-end approach that was suggested initially. It was received with confusion that a breakthrough couldn't be made and another dead-end approach was suggested in its stead. – An SO User Oct 24 '20 at 12:30
  • 1
    @CaptainCodeman If I say nothing and do nothing, eventually they'll figure out what to do with me :D – An SO User Oct 25 '20 at 16:40
  • 2
    You've used the words feasible/infeasible but you seem to be describing the word "possible/impossible". The two words in fact have different meanings. Can you please clarify which you meant? Infeasible = doable but not easily. Impossible = 'not doable" (as you describe). – TylerH Oct 26 '20 at 14:45
  • I suggest the Question can only be Answered for specific cases… what would you tell a senior demanding a family-priced, street-legal car with top speed 175mph and 0-60 acceleration in 3 seconds? "… with confusion that a breakthrough couldn't be made" is hardly standard English. Slip as far sideways in technical terms and why not expect confusion? Try "with the best will in the world, this is not possible. The standard approaches are this, that and the other and seven other angles were considered but all were thwarted by blah or bling, by widgetting or gizmicks." – Robbie Goodwin Oct 27 '20 at 22:51
133

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.

8
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. – Neo Oct 26 '20 at 14:28
  • 4
    "they may take a lot of time/cost a lot of money" is usually what people consider to be 'infeasible' (Defined as not possible to do easily or conveniently; impractical.). Did you perhaps mean to say "impossible" in your first sentence? – TylerH Oct 26 '20 at 14:41
  • 4
    I had one that was infeasible, there just wasn't enough inputs to get the output they wanted. When suggesting an additional input, their attitude was that we wouldn't need this software if we had that input. It was akin to asking who is in a white car driving down the highway. Sure I could give 1000 people who have that color car in that region...but they wanted it narrowed down to a handful with no other inputs. Good luck with that. – rtaft Oct 26 '20 at 14:59
  • 6
    I remember being told by a team that they couldn't even consider a certain request. I asked "our network can not support it?" "Oh, it can." "Ah, so we don't have anyone that understands that protocol?" "We could learn it, but we don't have the resources." "I see, and we can't get contractors?" "They're too expensive." "I see. Do you want to be the one to tell the man with a $10,000,000,000 budget (not exaggerating) that it's too expensive for him? Because I'm not." They came back with a quote the next day. In the end, it was too expensive, but you don't make decisions without data!! – corsiKa Oct 26 '20 at 16:23
  • 1
    @Will Not sure what 'who the responsible party is' has to do with my comment. Also "flexible" is a weird way to say "wrong". – TylerH Oct 26 '20 at 17:52
21

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"

5
  • O(n) isn't really relevant to the real world. (1+10^(-100))^n has a higher O(n) than 10^100, but the latter is going to take longer. – Acccumulation Oct 23 '20 at 21:02
  • 24
    One my former coworker used often was "9 women can't have a baby in 1 month." – Captain Man Oct 23 '20 at 21:27
  • 13
    @Captain That’s from a book called The Mythical Man-Month. Nearly 50 years old and still in print because most of the observations are still relevant today. – Patrick McElhaney Oct 25 '20 at 13:10
  • 1
    @Acccumulation examples about the irrelevance of big-O notation that pick big constants like 100 out of thin air aren't really relevant to the real world. Yes, it's true that arcane dynamic algorithms which improve the asymptotic complexity of a tricky problem often don't help in practice because they involve such big constants – but the other way around, if an algorithm has a high complexity then it does usually indicate that it doesn't scale to the real-world demands, whereas any algorithm that's both simple to understand and has complexity ≤ O (n · log n) is usually fine to use. – leftaroundabout Oct 25 '20 at 13:50
  • 3
    @Acccumulation and anyway your point seems to be more about the relevance of whether or not a problem is in P, not about the relevance of concrete big-O values. – leftaroundabout Oct 25 '20 at 13:53
9

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.

2
  • The problem is you can't abruptly make yourself trusted by management if you aren't already. – T.E.D. Oct 26 '20 at 15:08
  • Abruptly? No. But you can certainly work with them. One way you could start is by making them aware that they don't know what they're doing (politely) and to elucidate that you do know what you're doing (again, politely) and asking that they give you more trust/confidence in terms of that. – Ertai87 Oct 26 '20 at 17:38
9

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.

9

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.)

1
  • I like this answer because the job of a software engineer is to come up with solutions rather than problems, and indeed clients routinely ask for roundabout or borderline undoable features because they don't really know any better. It helps tremendously if you can ask the right questions to figure what they actually want, and then focus on all the ways to achieve that rather than all the ways you can't. – AmiralPatate Oct 26 '20 at 10:42
4

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.

1
  • Indeed, one should avoid XY Problems. Find the actual needs and requirements of the user, not what they (or someone else, or a chain of people) state the needs are. – jcaron Oct 25 '20 at 22:25
2

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.

2
  • 4
    This is not necessarily the case. Let's say you're working on a legacy system where, 15 years ago when it was built, nobody thought about feature X. Now, you're being asked to implement feature X. Probably 15 years ago nobody thought to document all the things the infrastructure doesn't support, including feature X. You can explain "feature X requires constraint Y and constraint Y can't be implemented because of <documentation>", but you can't directly explain why you can't do feature X, and providing why feature X requires constraint Y is usually very difficult to non-technical people. – Ertai87 Oct 23 '20 at 18:29
  • And if the documentation does not yet exist, ask for a small budget to explore the requirements hidden and do a good estimate for the full task. – schlenk Oct 24 '20 at 16:19
1

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.

-2

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.

15
  • An example would be asking for data from one SaaS product to be displayed in another SaaS product. – An SO User Oct 24 '20 at 12:25
  • @AnSOUser are they both yours? Do you have accounts there? – Strader Oct 24 '20 at 13:39
  • 1
    @AnSOUser That is normally accomplished by building a connector between the APIs of the respective products. If the SaaS products have no suitable APIs for the purpose, then it also involves negotiating with the SaaS vendors to develop the necessary APIs. – krubo Oct 25 '20 at 18:07
  • Many people complain about lazy bosses on this website, but this is one of the rare times I've read an answer that sounds like it was written by the lazy boss. It just missed the "bring solutions and not problems" motto. Why don't you hire a developer for 200k/year and ask him to solve Riemann's Hypothesis in this time frame? Even if the takes two years, you can collect more than a million dollars in prizes for this so sounds like a business opportunity. It may look difficult, but as an employee it's his job to make this happen! – Mefitico Oct 26 '20 at 14:50
  • 1
    @Mefitico Funny that you think i am a boss, i am actually on the other side of the employer - employee relationship, and businesses where OP works have been a very lucrative side income for me exactly due to a 'NOT POSSIBLE" attitude. In the modern age of technology there are very few things that cannot be done. And, of course, every solution comes with the cost. Keep it up, thank you – Strader Oct 26 '20 at 15:02

Not the answer you're looking for? Browse other questions tagged .