This editorial was originally published on April 15, 2008. It is being re-run as Steve is on holiday.

The other day I was observing a developer interacting with the end-user, who was asking for a particular enhancement to an application. Actually it was a a couple years ago, but I'm just getting to this.

The user had a request to change the way that a process worked, but adding a feature. The end-user was explaining that this small change (to him) would produce a lot of time savings.

The developer listened to most of it and then proceeded to explain that the system wasn't built this way and that it wasn't possible. As the end-user tried to explain further how this change would greatly speed up the process and make the application much more useful, the developer continued to give technical reasons why things weren't built this way, how it would cause problems and take a long time to get working. Eventually the end-user kept suggesting smaller or related changes and the developer finally agreed to make a few changes.

As I watched, I was struck by how painful it was for the end-user to get the developer to work with him and agree to make a change.

When I built applications, I was always a glass half-full developer. I felt that I could do anything (given enough time and money) with an application and worked hard to make my applications fit with users. My goal and desire was to make the end-user happy and I would make suggestions as we talked, trying to find solutions to their problems, and getting myself excited about building the application.

Now in this case it might have just been this developer or even this change, but I've seen this over and over from many developers. It seems that there are more and more developers who find reasons why things can't be changed, even valid reasons, without having the brainstorming and excitement to help the end-user solve the problem.

Maybe it's a work overload, and maybe it's a sign of the times, but try to remember that whoever your client is, an end-user or the developer you help as a DBA, you should look to help them. Even if you shoot down their idea or suggestion, give them an alternative. Work with them to get things done, find an alternate, or even revisit your assumptions about why you don't want to do things their way. Discount their solution, but consider the idea or results they want and make it happen.

Remember it's the drive and determination that allow humans to achieve almost anything, so try and recapture that the next time someone asks you for help.

Steve Jones

The Voice of the DBA Podcasts

The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

Overall RSS Feed: or now on iTunes!

• Windows Media Podcast - 27.8MB WMV
• iPod Video Podcast - 22.9MB MP4
• MP3 Audio Podcast - 4.8MB

Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.