Most of the time I'm contacted by a fellow yellowbleeder and presented with a question that has me asking two questions for their every one. I'm fine with this - don't get me wrong - as it's something that I do literally every day.

"Can this be done?" is often met with a "What are you ultimately trying to do?" and "How is this going to be used?" from me, as I find that most of the time a person is set on a way of doing things well before they even ask a question. Which - again, don't get me wrong - is fine, but as we all know there are about 50 different ways to get the same results, and quite frankly setting your mind to only one of those methods when looking to another geek for suggestions can often limit your end product.

Here's a few quick random thoughts that I think can help any of us "Corporate Application Developers"...

• Learn the mailto link syntax and use it.
  

  Sure, this is a simple thing... but one of those things that can really make an impression on the user community. You post something on your intranet and say "contact so-and-so for more information...". Now, wrap that name in a mailto link and use the subject parameter to pre-populate the subject line. You've not only given the users one-less-step to getting out that email, but so-and-so will get emails with a common subject line that they can quick-and-easy visually group.

  This is a single example here... but a good one. KISS isn't just a band y'know? Sometimes it's those simple things that really make a difference - so keep that in mind. Something that you may see as trivial and beneath a genius of your talents can make the most impact to the user.

• Make sure you're using Web 1.0 before you even attempt Web 2.0.
  

  I see this a lot - a CAD (no pun intended, honest) will want to try the new flavor of the week on a project request that comes from some business unit that just wants a simple and easy-to-use form for collecting some information and eventually reporting that data.

  Sure, it's not sexy... but here's the thing. Most of the people in this situation are looking for the familiar, not the cutting-edge in UI development. You should work towards such things - don't get me wrong - but don't introduce a Web 2.0-laden iPhone-like UI to someone who simply wants a feedback form.

• Code to the requirements.
  

  I've kinda touched on this in the previous item, but I think it warrants it's own bullet. Don't assume that you know what the user wants within 5 minutes of the discovery meeting. Part of your job is to interview the user, get the requirements that they might not even know that they know, and get them down on paper so the user can see how stupid what their request looks like. Remember - most people are visual creatures. They could expound for hours, hands flapping like they're orchestrating at Carnegie Hall, telling you about all the wonderful and amazing things that they must have in their applications. It's part of your job to pull them down from that "some developer's listening to my ideas"-high and get some solid requirements.

  Also, you gotta stick to the script. If you've agreed on something - that an application should work this way - don't stray from that without at the very least contacting the requesting user and confirming that this is a road that everyone in the project team wants to go down.

• Development efforts should be like the Special Effects in a movie.
  

  The best movie SFX are those that you don't notice. It's not the green-screen, CGI Cthulhu terrorizing the all-star cast, but the subtle often overlooked SFX that allow you to become fully immersed in the movie. Development should be the same way - they should allow the user to seamlessly continue with their day-to-day - often not even realizing all of the awesome that is happening behind the IT curtain.

These are hard lessons learned and even harder lessons to stick to... but I think that, regardless of your level of development knowledge, these are excellent reminders to CADs or hell, anyone that writes code that someone uses.