I found this thread very interesting. The replies I recieved interpreted my comments in many different ways: only a few that were on the exact wavelength that I was trying to communicate on, but pretty much all were worthy. But I have to say yours so completely missed the point that I feel obliged to respond.

to presume that you have a monopoly on the production of solutions just reeks of elitism.

Im afraid this is a false start. I dont claim to have a monopoly on solutions. I have no idea how to fix the air conditioning, or the lan, or the backup library, or the power plant, or the sales department, nor the finance department. I wouldnt even consider telling the lawyers how to do their job: not only am I from a country with a totally different set of laws and legal principles, but I dont even know the ones in my own country well enough to comment on them. However, insofar as the IT/IS systems that are used in my company I'm one of the few that knows them (or the trade in general) well enough to make intelligent decisions. (Sure there are others with similar skills, but I either work with them already, or they work for radically different parts of the company: as in a different country, or on totally different subject matter.)

Do you even admit the legitimacy of other professions?

Of course I do. As I said I wouldnt dream of telling the network guys how to fix the lan when it goes offline. But lets turn this around. Do they respect me? Is it respectful to go to a skilled professional and tell them how to solve your problems? Lets say the lawyers are working on something that has to do with me. Would it make any sense for me to go and tell them how and when to file their briefs? Would it make any sense to go to the finance department and tell them how they should account for things? Why should it be any different for me (us)? Why is it somehow ok for a lawyer to walk up to me and ask me to set up an "Excel database for storing real time data from these web pages?" Why should it be ok for someone to dictate to me how to implement a solution that I will be responsible for writing and maintaining? If someone came up to you and told you that you should write an order entry system in brainfuck would you do it?

The whole point of this meditation was to point out that in a large enterprise enviornment there are lots of people who think they know enough computer stuff to tell development how they should do their job. (And the additional point that there are many people in our field who for one reason or another go along with it.) They want us to produce "excel databases" for mission critical systems. They want us to do all kinds of stupid things. Thats not our job. Our job is to produce systems that solve the business problem in a stable and efficient manner, and as cost effective as possible. If I grant the wish of the customer when the customer has asked for something stupid then all I'm doing is wasting my time, and the companies money. Which is most certainly NOT what a developer is for. We are there to produce tools to save the company money. Not to satisfy the whims of the less technically savy parts of the business regardless of the cost.

An example: A long time ago I was too fresh to say no when a customer asked for a bizarre solution involving a lot of mission critical data stored in a zillion excel workbooks. I was too fresh to say "No way we are doing that. Well design you a database and a client to manipulate it, but im not touching your excel sheets with a ten foot pole." In fact I said something like that, but I allowed my better judgement to be overriden by the argument that "this was an interim solution, and we dont have any money for it anyway, so we just want something quick and dirty. After all we only can afford two days of your time." So I did the two days work and put together a JGID solution. And it worked. For a while. And then one day the team involved got a new teamleader, who in his infinite wisdom decided to change all the excel sheets around. Which of course broke the code I had written. So of course I then had to change the code. There goes another couple of days of development, and a few more in analysis and support. And because the solution uses excel sheets as though they were tables in a DB its horribly fragile. Despite far more hours of work than the project is worth there are still a whole host of things that can and do go wrong. Many of them requiring intervention by a developer. So now this project that was only going to be "two days of work" has literally mutated into weeks of work over the past few years. Never more than a few hours at a time, but all together in the range of a few hundred hours over the time the system has been run.

If I had refused and forced the business to implement a proper solution I reckon it would have been between 40 and 80 hours work total, with about two or three hours maintenance by an operations team over a year. As it is the cost is far far higher.

If theres arrogance involved here its in the patient that goes to the doctor and tells them what medicine to prescribe. No self respecting doctor will let the patient determine the cure, and in my opinion no self respecting developer should let the customer determine the solution. The customer defines the legitimate constraints just as the patient describes the symptoms. Just as a good doctor will include factors beyond the immediate symptoms, and will ferret out hidden symptoms and issues that the patient hasn't mentioned, so a developer should do the same.

So it seems I misunderstood, sorry.

I'm relieved to know that you do in fact respect other professions, at least I accept what you say, and on reflection I suspect that my misunderstanding was probably semantic; a different interpretation of the word "solution".

To use your doctor/patient analogy, I was asserting that the patient has every right to say "I have halitosis, it's inhibiting my social life, and I want sweet smelling breath", whereas I would agree with what I now think you saying that the patient does not have the right to say "...and I want you to prescribe benzodiazepine."

I'm relieved to know that you do in fact respect other professions, at least I accept what you say, and on reflection I suspect that my misunderstanding was probably semantic; a different interpretation of the word "solution".

Ah. Thats probably my fault for not expressing myself better. Judging from the wide range of responses I didn't make my point clear enough. But in hindsight I'm kinda glad: I think the responses would have been less interesting had I had been less of a windbag. :-)

To use your doctor/patient analogy, I was asserting that the patient has every right to say "I have halitosis, it's inhibiting my social life, and I want sweet smelling breath", whereas I would agree with what I now think you saying that the patient does not have the right to say "...and I want you to prescribe benzodiazepine."

Yep thats pretty much what I was driving at. :-) And your example is particularly pertinent, in that its quite possible the doctor you mention might simply say "lay off the garlic in your meals", and not prescribe any medicine at all. Just as we might simply point a customer at a commonly available tool instead of writing any code.

Anyway, im glad thats all settled then.



---
demerphq



First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

I know this post is way after the fact; but I hope that people can still derive some benefit from it.

I have worked at a shop where the upper management (VP) was a former JGID programmer; and most of our Business Partners (we weren't suppose to call them "Users" or "Customers") were trained to ask for solutions.

We tried for a long time to re-train the BPs into presenting their problems and letting us design the solutions; but it hadn't worked up until the point I left.

I found it very difficult to say "no" in that situation; because when we did, we were "wrong" and had to do it anyway; or we were labeled "purists" and denigrated for not living in the real world where things had to get done.

The business was pretty successful despite these drawbacks.

What do you do in a situation like that? How do you convince the BPs that there is a better way?

Well i guess it depends. If you can figure out what the underlying problem is and identify a better solution then you have a number of options. You can provide several quotes for how much work will be involved, naturally the dumb solution will take longer. :-) Alternatively you can simply implement your own solution as a "proof of concept" and then point out they can have it Right Now, or wait some time for the dumb solution.

Another approach that works is use deductive reasoning to identify potential issues in the design, then write a very carefully worded mail saying that you wont procede until the issues are resolved to your satisfaction, or until a manager provides you with written instructions stating that they understand the issues that you have raised and want to go ahead anyway. This is useful because very few people like this want to be put in the hot seat. By forcing them to provide documentation you are making clear that in no way in the future will you be held responsible for the poor design, and that instead they will.

I suspect the truth is tho that the only really good solution is to find a different place to work.

---
$world=~s/war/peace/g