|
I did stuff that was used inside the company. So I regularly talk with the other developpers. I know it's not the same thing as a more "common" client but I tell you. Even when they're developers, they still don't know what they want.
|
|
|
|
|
and they think that I'm an a**hole...they really do. You can't please everyone. No matter how well you do your job and how well the software works, someone will ALWAYS find something wrong with it. Users suck. 
|
|
|
|
|
It sounds like you're in the same boat I am. Most of the time, if an app works well, the user doesn't bother communicating with its creator. It's when the app screws up that they get on the phone and start screaming. The official communication I have with customers is through the company's bug application. The end result is all I hear is the bitching and complaining about things the application doesn't do correctly.
If your organization is big enough, try talking to other people that connect to the customers directly - sales, technical support, or field service (if you're a hardware outfit). If you're app is any good at all, you'll find a more balanced view from those folks. Even better, if your industry participates in trade shows or industry conferences, try to go to one of those (or at least talk to the people that go). You then get to talk directly to customers, unfiltered by three layers of phone support and managerial double-talk.
Update: I don't know who univoted you, but I gave you a 5 to balance it. It's hard not thinking users are morons.
Software Zen: delete this;
|
|
|
|
|
Absolutely agree. They need something out of the blue.
|
|
|
|
|
I get a completely different feedback from our users, the ones still employed, they are so pleased they are the ones chosen/capable of using the software they managed to retain their positions. Mind you I have small userbase so when the CRs come in they are addressed rapidly.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I agree.
I'm usually required to program a "matchbox" so I give a time schedule and that's it... but no,
after the "matchbox" is ready it turns out it should have been an "zero-emissions-nuclear-shoesbox"
and the classic "could you please make the whole box made out of titanium? that's a quick change right?"
So, I really don't like dealing with users, they just keep giving "ideas" that 40% of times are crap and 40% of times
are too expensive to develop (however they still hope you can do these even though they didn't mentioned them
in the initial specifications when the price/time was fixed)
|
|
|
|
|
In my case... the development team, is same as the support team... 
"He that is good with a hammer tends to think everything is a nail."
- Abraham Maslow
|
|
|
|
|
Agreed. In my role as the D.S.J.B.(*) I am responsible for two applications.
The first, and a source of some pride, is a debugging tool we use that monitors communications between the components in our distributed application. This tool uses a lightweight TCP/IP socket connection to each application and service to record trace messages and to send debug commands. Over time it has matured into an indispensible part of our tool set.
The second, a source of embarassment, is our build process. While the process works well, is pretty stable, and is even documented, its construction is horrible. It starts as a Windows GUI app that lets you enter some information, which in turn starts a Windows shell script. The script runs the majority of the process, which may invoke compilers, batch files, the original app with command-line options, or additional applications  . Recently I added a Windows service that lets you start and monitor builds remotely. If I ever get run over by a London bus, my advice to my successor is to chuck the whole mess and start over  .
(*) Departmental Sh!t-Job Boy
Software Zen: delete this;
|
|
|
|
|
Yes. You've got to stand behind your work. If you write buggy code, you deserve phone calls at 03:00.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
