But this should be really easy. This shouldn't take much time to develop

Well I’ll share a few opening sentences that tend to make my heart sink a bit as a programmer. I’m an independent software author so I don’t have any problems with others telling me what to do, but often get requests from users. I’ve found ways to work with this over the years, so it’s much easier now than it was. But I used to get many frustrating questions, and still do sometimes.

1. It’s not working - and then when you ask for details they don’t answer and expect you to solve it without knowing what the problem is. Still get this sometimes. Usually I manage to get details eventually but it can take quite a few messages back and forth. It’s understandable but frustrating at times.
2. It’s working now - sometimes good news, but not if you haven’t fixed the bug yet. Users have a different perspective from the developer. As a developer, if you can’t reproduce the bug yourself, you are dependent on them to reproduce it. So - especially if you’ve spent maybe several hours or days trying to fix a bug, and have nearly got there - narrowed it down to a few lines of code perhaps - then suddenly the user says ”it’s working now” and no longer is interested in reporting back and helping you go through the last few steps to find out what really caused it and fix it - it can be quite frustrating. You just have to wait for someone else to report it to continue the debugging. That happens much less often now because I’ve got much better automatic reporting from the program, so long as they send me the necessary data on request.
3. I know how you can fix this bug - when users say that they almost invariably are wrong. They haven’t written the code, and I wouldn’t be able to say that to another programmer even, if I didn’t have the code. Sometimes you can see how to fix a bug right away. But if not, it’s often a bit like trying to solve a mystery in a detective story - it’s almost never the culprit you thought it was. If you can’t see it as programmer right away it is very rare for the user to see it somehow.
   
   Unless of course it is something unusual about their machine e.g. “I’m using a third party shell for all the windows” - that was the answer to one rather strange user interface bug - the menus were buggy, they couldn’t see some items - because they had a non standard third party shell that was displaying the menus in a slightly different way, (I forget the details now). It took several messages back and forth before we figured out that it might be due to their UI shell - it’s the sort of thing people tend to install and forget.
   
   That sort of thing is very useful to know as of course you can’t know that without being told. I found a work around for them in that example. I installed their preferred UI shell on my computer, duplicated the bug, and then played around until I found a solution - I added some extra spaces into the menu item names which had no impact on other uses but fixed their issue - it was a workaround for a bug in their UI shell basically.
4. I’ve got this great idea for your program - sometimes it is a good idea but often it’s something like e.g. - a text editor that plays a different note for each letter typed (okay made that one up) - Now that I have a wish list, this is no longer a “sinking feeling” type email or message. Instead it is quite fun now, I just add it to the wish list and they are satisfied by that also, and from time to time I implement some of the ideas. Bounce Metronome Pro Wish List And the user never has a clue about whether there idea will be easy to implement - sometimes astonish them by doing it in a few hours - or next to impossible - something that seems dead easy to do for a user may be a one or three year project for a team of a dozen developers, as in this xkcd cartoon.
   xkcd: Tasks

1. This idea is so great it’s going to earn both of us a fortune: I get this from time to time, maybe once every few years, not that often, but when it does happen they are often very sure of themselves and persistent about it. “I know lots of people will like it, and it’s incredibly important to do it, please do it and give me 50% of the royalties.” - nowadays I have a clear statement on my website that I never make royalty agreements in exchange for ideas and send them to read that. It’s at the bottom of this page: Standard Disclaimer
   “I WILL NOT ENTER INTO ANY ARRANGEMENT INVOLVING PERCENTAGES OF SALES OR FUTURE RECOMPENSE IN RETURN FOR SUGGESTIONS, BUG REPORTS, ALTERNATIVE GRAPHICAL USER INTERFACES, OR ANY OTHER PROPOSALS FOR MODIFICATIONS OF MY PROGRAMS.”
   
   If they say it is secret and I have to agree to share royalties before they tell me, I just say, please don’t send it to me. If they are still keen for me to do it, I then add it to the wish list, or program it if it is easy to do. The reality is that if something is an outstanding business idea for a software program, then nearly always someone has done it already, probably dozens of developers done different versions of it.
   
   If not done already, then it’s a reasonable guess that it is perhaps of great interest to a small group of people, but they are greatly overestimating how much it would earn. If say 0.01% of the population are interested in it, that may mean there are tens of thousands of potential buyers. But advertising to reach them would probably cost much more than you’d earn. And the chances are that most will want it for free. The reality of the situation is that there are very few programs with millions or thousands of sales, rather more that make a few sales per week, and the majority of programs by independent developers will only make a few sales a year or ever. It’s best to do a program that you want for yourself, or have friends who want it and just do it because you think it is fun and interesting and useful, and then if you earn anything from it, that’s a bonus.
2. “Oh, that’s not what I wanted” - after working on it for weeks or months. This used to be very frustrating - though some of the ideas I programmed in this way were useful for other users though not for the person who originally asked for them. The problem is that users don’t really have a good insight into how the UI will work, so they may say that they think you need to do x, y, z in great detail but when they see it they realize it is not what they want at all.
   
   The main issue here is that it is natural to interpret what they say as if they were programmers talking to you about your program. It’s important not to deal with user requests as if they were program specifications, but instead ask them to explain why they want these features and try to learn what it is they are trying to do. Often you find the program does it already, just that the help was a bit confusing, or that the obvious way of doing things is buggy, so you have to fix that bug and they are trying to get you to program a work around for a bug they haven’t thought to report, etc.
   
   Nowadays I deal with that by going over it more clearly, like that. Also once the idea is clear, or as clear as I can, I get a rough version for them to see at an early stage, instead of implementing the whole thing, just some part of what they want. Then if it is still interesting, if they say “Great that’s just what I wanted” etc then I take it further. If not, haven’t spent too much time chasing that particular red herring.
3. Please make this program more user friendly - that’s reasonable enough as is, but then you go on to say “Okay, do you mind testing it for me and giving some feedback” and they say “no, why do you need to test it? Just make it work better”. If I was the likes of Microsoft I could have teams of users to test everything. But an independent software author can’t do that, you test it yourself, get a few friends to test perhaps - but if that is not enough you are dependent on your users to give some feedback. If they can’t answer questions or don’t want to, you just have to give up on it, and wait until someone comes along who will explain what the issue is for them.
   
   And if it is something very specialized, the only people who can test it are the ones who would be using it. At least in detail. You can go a certain way towards this goal by following user interface guidelines, relying on past experience etc. But after doing that if they still say “make the program more user friendly” - where do you go next when you’ve already done everything you know how to do? You need feedback from the users of the software otherwise it is just randomly changing things in hope that it will help, which is as likely to make it worse as better, and also to annoy previous users of your program who are used to the way it is now.
   
   I deal with that by explaining the situation somewhat better than I used to. It’s a tricky one though, as you need to be a programmer I think to understand quite how complex UI programming is. The modern friendly UI - e.g . the editing UI for quora as an example - it seems so simple but is a result of thousands, or more likely millions of carefully thought out ideas, many sketches, programming, user interface testing, this UI - which I think is very good as a user - it must involve so much by way of thought and testing and experience… And to most people all that is totally invisible except when it goes wrong.

My worst experiences with non-programmers usually has two repeat elements:

1. Can you just…
2. Why don’t you just…

The first issue starts off with someone asking for something that is seemingly simple to them (“can you just…”) but in reality, is tremendously complex. I can’t give them a technical answer, because they have zero technical knowledge. But when the person I’m talking to is a supervisor, company executive, or someone with a controlling budget, I’m forced to give an explanation because they need to weigh it against ROI, valuation, or opportunity costs.

This often results in trying to explain complex technical issues using analogy or metaphor. In so doing, I get the point across, but then they try to solve the problem—as though I’m incapable of it—thereby compounding the abstraction by trying to solve the metaphorical concept. This results in them responding with “why don’t you just…” as though I’m completely daft and never thought of that. But this often destroys the metaphor, because I didn’t use an analogy for the purpose of solving the problem, I used it to explain the situation. They think they’re being helpful by solving at an abstract level, but all they’re doing is compounding their ignorance and forcing me to come up with an even worse analogy.

Some examples of this pattern:

• Can you just… show their account information in the checkout?
• Answer: “Yes, but not easily… the account information is in a proprietary database behind a firewall, and the website is hosted in the cloud. We’d have to create an API into the back end system. Kind of like building a bridge between the website and our database, but it needs security, so more like a controlled-access bridge, which would require more effort. It might take a month or more.”
• Response: “Well bridges are for crossing rivers, and computers don’t have rivers between them. So why don’t you just skip the bridge by just putting the database on the website?”
• Can you just… move our customer data from that system to the new one? We’d like the new system in place next month so we can train everyone.
• Answer: “Our customer data is our custom-built system, and the new system is an off-the-shelf product. They’re not compatible. We’d have to completely restructure the database or build conversion scripts. It will take months. It’s kind of like trying to stick a gasoline car engine into a diesel car and expecting it to just work. They’re not compatible. We can do it, but it’s a ton of work, and it won’t be done in a month.”
• Response: “Well even engines follow basic patterns, and use standardized parts, so it can’t be that difficult. Didn’t you design the custom database correctly in the first place? Why don’t you just use Access to get the data out, and push it into the other one? My nephew can do that. It’s just data.”
• Can you just… change the forms to go straight into our database instead of emailing us?
• Answer: “Yes, I can, but the site was developed by a third party and they used a custom form tool that they have the only license to, I don’t have access to their code, and we’re using email as the receiver because we don’t have an API to connect to our database. It would be like trying to make your iPhone control your microwave by just making a wire that plugs into the phone and the thermostat jack inside the microwave. We’d have to know how the systems on both ends work, and both devices would have to understand each other. We’d have to spend research time on that and see if it’s possible. I don’t know how long it will take.”
• Response: “Well, I need it for next week, and you’re making this too complicated. If the third party developed the site, then they must know how to do it. Why don’t you just… outsource it?”

That last one is the worst. It assumes that because you’re asking for something that you don’t understand and you’re too impatient to wait (or you failed to plan ahead), you think a third party can do it faster because we’re too dumb to just make the magic happen.

“That should be easy.”

I hear this a lot.

My immediate emotional response to this is “The fuck you say.” I honestly don’t care if it is easy, they should not be saying it. They are in no place to evaluate the easiness and the hardness of anything. They are almost always wrong.

What is often the case is that the things they think are easy are hard and the things they think are hard are easy. It kills me how often they look at me with serious, pleading eyes and ask “can you, is it at possible, please dear sir, would you be able to change that icon to cornflower blue?”

Just as I am smirking to myself they drop on:

“And calculate the number of atoms in the universe…while you are at it.”

Insert obligatory xkcd(xkcd: Tasks):

Usually the thing they want. They thing they have already written off as completely trivial. That thing. That thing is the wrench that messes up the whole works.

Now, if you are talking with non-developers just in general, then it is:

“Hey, I have this great idea where you do all the work and I sit over here and supply the idea and we will both make millions of dollars.”

After reading most of the answers here and considering my very own experiences through the years, I'd break it down to the really most annoying and irrational words I presonally heared way too much in my career:

"But this should be really easy. This shouldn't take much time to develop."

Every time I heared this, I just asked myself:

Why can people without any knowledge in software development, espacially completely non technically oriented people, claim that they are definitely able to estimate the complexity and amount of time of a development task?

Immediately after this, I often smile and laugh to my inner self because I have to imagine how it would be if everyone of us would show this behavior in everydays life on any situations. Imagine those situations like me, as a software developer, I would ...

• tell the doctor performing a surgery on me, that it is easy fixing my heart with a by-pass and it won't take long
• tell the mechanic that disassembling and reassembling the engine of my car is so easy and it shouldn't take long
• tell the grocery store employee, that placing the 4 tons of delivered wares in the shelvings is that easy and it shouldn't take long
• tell the architects and construction supervisors, that building my new house is damn easy and it shouldn't take any time
• tell any random mother around me, that raising a baby and providing it food and safety and a warm home is just damn easy and it shouldn't take long for it to grow up

...and so indefinitely many more.

Twisted reality.