scarletmanuka wrote:Pretty sure you're just trolling now, Mustapha
Oh, people always are.
scarletmanuka wrote:The difference is that I, as a developer, don't assume that neurosurgery is easy. Or that general practice is easy, for that matter. Or, for example, plumbing. And if I get a tradesman to quote on a particular job, and he comes and performs that job, I don't go and complain about all the other things I'd like him to do that I didn't mention before and demand that he does them for free.
Are you absolutely sure
? Okay, so maybe you are indeed right, and you do have a very careful attitude when approaching other people's professions. That doesn't make you the rule, though, neither as a person, nor as a developer. For one: a plumber, for example, is generally well-seasoned in understanding people's requests and in getting more information than the customer thinks he needs to give. To give a rough example, a customer may say that there's a pipe that needs to be fixed, but he won't explicitly say that the wall needs to be broken in order for him to access the pipe; the plumber, however, will know that, and will not refuse to break the wall only because the customer didn't explicitly say so. If the plumber does a lousy job, though, the customer does
have to right to demand it to be fixed without extra charges. There's no absurdity in that.
The problem is that software developers and engineers often think they have the whole control of the situation, and they don't understand
that the requirements often change over time, that the client doesn't have a 100% perfect understanding of what
he needs before he has a prototype or a partially functional product, that he doesn't mention every
detail of the requirements because certain things for him are "obvious", and so on and on. Developers often don't see that as a natural obstacle to be overcome, and see that as the client's fault
. This is not just me saying: I'm taking Software Engineering classes, you see, and those topics are being constantly mentioned.
When someone wants someone to project a house, he will often "see" the house he wants, but he doesn't predict every single detail and characteristic of the house. He will only visualise certain differences and problems when he sees an actual blueprint. Is that because the client is a dumb moron
that "doesn't know what he wants"? Does he think that architecture is "easy" just because he constantly wants to change things? No: the thing is that he's not an architect and he doesn't think like one. That's the kind of thing architects are ready for: a blueprint is necessary, sometimes even a full 3D model will prompt changes and fixes by the client, and that's the way things work
. If an architect tells his client to go fuck himself because "he doesn't know what he wants", he will end in bankruptcy.
But with software developers, the norm seems to be very different. It's not hard to see why: information technology is very new, many people (both clients AND developers) are still getting seasoned to it, and there aren't enough rules and guidelines as there are in other areas. Many things are very hazy and unclear. It's easy for people to have a wrong attitude towards it, but nobody wants to agree on what their own share of fault is: clients think the developers don't know how to work, and developers think clients should know more about computers before having an opinion. Clients also have their share of fault, but it's up to the developers and engineers to understand that and work their way around it!
That's what they're paid for
! You are the developer, it's your job
to know how it works, not the client's! Can we just agree that the IT people also have their share of fault? I'm just absolutely sick of people thinking they haven't, be it for laziness, arrogance, or just plain ol' stupidity.
People who work with computers are -- gasp! -- imperfect too