A few tips for the any-level Corporate Application Developer

08/06/2008 12:08 PM by Chris Toohey

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.