Trust me that the problem is shared. I've got som 20+ years developing software in different contries and the problem description hasn't changed.

Furthermore, at least in my case, it's not at all limited to The Management (bows in deep respect and keeps job) but just as flagrant for any user of my/our software.

It's very common that when our user community calls us up with an idea:

• We do an analyze of the idea and presents the analyze to the user
• The user says that it's great
• We ask the user to somehow commit to the requirements (at least in an internal e-mail, asking for a physical signature would be politically incorrect.)
• The user studies the requirements for the first time ;-)
• The user organizes a set of meetings with other users to make sure that the decision becomes a "concencus decision", i.e. an "it wasn't me deciding that" decision
• The user comes back to me/us saying that it's OK
• We develop a prototype with an interface without guts, all according to the requirements agreed upon
• The user immediately finds that the interface must change; "Put this button to the left of that button"
• We make the changes of button placement
• The user agrees and wants to use the application the same day
• I/we tell the user that we can now write the guts of the application
• The user complains
• We write the guts of the application
• The user "tests" the application during five minutes and agrees to put it in production
• We ask the user to somewhat confirm that, at least in an internal e-mail
• The user tests the application for more than twenty minutes and let's us know that the functionality is not what s/he wants
• We show that the application does what the user asked for
• The user ignores our arguments and tells us what s/he really wants
• We write down what the user says and ask the user to confirm, at least in an internal e-mail
• The user goes back to his/her colleagues...

Furthermore, at least in my case, it's not at all limited to The Management (bows in deep respect and keeps job) but just as flagrant for any user of my/our software.

That's quite true, but then management people have the tendency to just say "Do that" (or even have someone else tell you).

Users (at least those in my proximity) come to me, explain what they would like, and then listen with big puppy eyes to me telling them what can be done, what makes sense and what doesn't. And adapt their ideas accordingly. Sometimes.

--cs

There are nights when the wolves are silent and only the moon howls. - George Carlin

That is the way to avoid this issue. First thing you should do upon hearing "I'd like such'n'such" is to say "Ok, I'll write up a use case for your approval." Then, when they approve the use case, you write it to exactly that. If they complain, you ask them for the time to modify the use case and do the development. (I mean, they just gave you an RFC, didn't they?)

If they complain, you explain it's for their benefit, so that you know what they want. They'll come back with a bunch of changes, but it's easier (and less error-prone) to modify a Word document instead of an app.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

This is a step, it's not a total solution IMHO. The problem is that people will look at a Word document and say "Yeah, that looks good. Do that" but when they get the application in their grasp they'll see things they want to change.

Yeah, they will. But, that's when you say: I met the design. If you want to change the product, please find the hours for me to:
1. Change the design
2. Change the test-suite
3. Develop
4. Change the documentation
Treat it like a "real" product and you'll find that they will, too.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

My observation from being in this industry for about 20 years now - and most of that time being in the position where you find yourself - lends me to my observations on this topic.

1. Managers usually are faced with a particular topic or challenge where they need technical support or a technical solution.

2. In their attempt at providing the solution for those that are seeking it and not knowing what the proper solution should be - attempt to draw out a solution via an interative process that will ultimately fit the needs of the business model in question.

3. This process ultimately provides answers - usually by accident. This process is also very inefficient for those in the trenches.

There has been a surge recently to provide better means of process improvement - this includes but is not limited to design of systems. One of the most highly regarded BPM (Business Process Management) methodologies around today is Six-Sigma.

I am a huge proponent of 6s as it does tend to streamline and clarify processes and expected outcomes within an attainable set of expectations. It also helps reduce the "waste" in the process (ie - the multiple iterations).

Another point of view is that of RAD - Rapid Application Development - the process that you are witnessing is symptomatic of that approach. Do it - present- refine - present - refine - present - accept.

As a technical person and a manager I find that both work well - in the end. It is not necessarily how fast one gets to the solution - but how well the solution is in relation to the strategic direction and business objectives of the company. Many times unfortunately, that path is not clear and needs a bit of prodding (the iterations and continual changes) to find the solution to the question that was not formed perfectly to begin with.

We are all human - and managers like the rest of us - do not want to look foolish in front of our peers and bosses - so it is easier to not complete the thought process when our bosses are not around (adopt the RAD approach).

Just my views - I hope this helps.

draconis's post prompted another NDA-anonymizing horror story from the corporate front.

draconis brings up two excellent points. First, few employees at the manager level in technical companies can do the work they oversee. Many can't even understand it. This is not their fault exactly, though one wonders why anyone would accept responsibilities they can't truly handle. It's the fault of the corporate culture and everything bad that can go with it: buddy-system, somehow an MBA means you're a worthwhile individual and not an Enron exec, &c. It's an inefficient company that makes these mistakes b/c it's obvious from all the posts here, and any water cooler conversation, that it causes friction and wasted time in most offices.

Second, the horror. Few managers are good enough to admit they were wrong. I think many of them are too scared to b/c they are aware they have landed in a seat via musical chairs and not by skill, effort, or brains. We had a chaotic but nicely functioning system of command line Perl tools in our office for a few hundred employees. Management replaced it with a Java GUI which, nearly a year after it was supposed to be complete, still only covered 30% of the original tool base. This basically wrecked an entire department. Two sets of tools. Infighting about who was using what. Two sets training. Unofficial training to catch up. 80% abandonment of the new toolset.

This fiasco cost the company millions of dollars and everyone saw it coming and understood it from the first 2 months of it. But the managers were unwilling to accept that it was a bad idea. That they'd completely misunderstood the scope of the environment and they should just cut their losses. They just kept jamming a square peg in the round hole. It went on, crippling what I think was the best department of its kind the world, until the Java was scrapped in favor of a fresh set of Perl (often wrapping C/C++).

If they'd been willing to admit they were wrong, it could have been dealt with in 6 months instead of 2 years.

I found in the past few weeks that management (and some non-management coworkers as well, but less so) have a tendency to demand things to be done without specifying how they want it done.

This doesn't have to be a bad thing. If someone gives you a task without specificing how to do it, you might consider that bad management. However, you could take a different point of view. Perhaps you are given responsibility. Perhaps you have earned some respect or trust. Don't panick.

And once that is done, they see another thing which could be done in another way - the last time I put a simple presentation on the web for download, I got requests to change file format, link text, link placement etc. over a time span of three weeks...

And this is strange? Seems perfectly normal in a process of creating a product. Writing good specs is very hard. Knowing what you want and formulating it in such a way a good spec can be written is even harder. Besides, people change their minds. Remember the second rule of Perl development: Larry can change his mind anytime (Rule 1 being: Larry is always right).

Sometimes I wonder... is it really that management people just can't express themselves and communicate properly, or we tech people don't understand them?

If all tech people could express them very well, and communicate properly, we wouldn't need Damian to write exergesis, would we? Then Larry's apocalypses would be clear for everyone, and the perl6-language list would only have postings of code implementing perl6, without the need for discussion.

Apart from writing specs down and have them approved, how do others work around this kind of problem? Is it a problem at all in other companies?

It would only be a problem if they expect you to meet deadlines, and they keep putting in change requests all the way to the deadline.

Abigail

I've done the same trick myself, sad to say...taken a 'functional' program that's generated a bunch of user requests, got a designer in to make the buttons look nicer and prettify the menus / dialog boxes, and handed it back to rapturous applause. As programmers, we often tend to think in more functional ways where interfaces are concerned - but some users *like* clicking A, seeing a pretty box, scrolling down, clicking B etc., rather than simply typing 'find' at a command prompt as you or I would tend to do.

Just my $new_world_order_currency * 0.02.
Ben

This is very true. I'd summarize your post in the following statement: Non-technical people normally will judge the completeness of your application by the UI you present.

The corollary would be: If you want to avoid frustration, demo half-finished software with an at most half-finished UI. If the UI is perfect, but the backend doesn't work, your boss will be very astonished why it takes you so long to finish your job since "everything is already working".

Note, by the way, that this is not meant to be demeaning to non-techies -- not at all. It is just normal to judge things by outer appearance if we lack the understanding of the inner workings, and it takes an effort to make yourself understand that you need to look closer. It happens to programmers as well, just in other areas.

When creating software, you will encounter some requirements that are very hard to fulfill, and others that are quite easy to manage. Unfortunately, the difficulty of implementing something is not necessarily proportional to the impact it has on the final product. The result is that non-programmers have difficulties to write specs for a software (unless they learn how to do it) -- it will simply not occur to him or her where the real difficulties for the programmer lie. They will see the problem in their context, and not in the context of programming.

The result is that as a software developer, it is your job to help the guy that's having a problem. You will have to understand the problem in his domain, transfer it over to yours, solve it and transfer the solution back into his domain (This is a vast oversimplification, of course). At the same time, you will have to communicate your needs.

Fortunately, I am able to deal with this quite well in the small shop where I work. My boss is not a programmer, but as a new project approaches, we take the time to sit down and talk about what I need to know and what needs to be specified. This makes it a lot easier to plan ahead, especially when the client's expectations (as usual) are a moving target. Because he then has the background knowledge where the real difficulties lie in the project, he can better deal with the client and fence off requests that would endanger the project -- or at least communicate to the client the costs these changes imply.

If you are in a public institution like me, it is almost assured that the person talking to you does not have sole authority to order the change. Have a look around. There will almost certainly be a technical committee, compliance manager, PR department, liason officer etc. who should be consulted first. Failing all of those, ask if you need to ask the legal department for advice on the changes. It's very, very easy to block anything in a pblic institution.

In a private business, it can be even easier because other people will *want* to interfere in your business. There will be marketing people etc who you can consult, there will be an official 'webmaster', and so on. There will probably be a corporate standard to follow, etc. Ask if your boss is sure that he wants the page to look different to the VP's vanity page. Enlist other technical people in your struggle.

While all the above strategies sound silly for a simple thing like a link change, use them for a battle that's worth fighting(ie something that is really inconvenient for you). Then when people want a link changed, they'll remember how hard it is to force something past you.

Note that all of the above actions are effective declarations of beaurocratic war, so delete all your illegal mp3s off the fileshare first.

____________________
Jeremy
I didn't believe in evil until I dated it.

.. a simple choice. and sometimes that is not enough.
To exemplify,

Q: Would you like Bacon or Eggs ?
A: Yes
~ ~ ~ ~ 
Q: Should A get X0,000 or Y0,000 ?
A: All of it.
[download]

I saw perception mentioned a few times in a couple of meditations this week. If the tool owner (management, users, whoever) perceive that they're making the choices, they can often be more amenable to the dire straits those choices put you in.

I have found that when writing software for in-house use, people can usually describe a tool from one step to another, but have difficulty with the holistic picture. Breaking things down into a choice between this was and that way greatly reduces 'furrowed-brow-syndrome' and lets you get on with the job. It also permits the developer a little bit of fancy footwork like ,

Well here we can use an X.500 directory or an LDAP connected database.
Which do you prefer ?
[download]

Spontaneous wishes by other co-workers often give a hard time for a programmer. I think they should be taken easy. They are not real production software. Usually I don't hurry with them too much and let the ideas crystalize. If I'd have to implement every wish of my co-worker, I'd be dead in no time ;-) So, my suggestion is: take it easy on those talks and give them a talk back ;-)