/tech home / projects / personal 'blog / about


ARCHIVE: Developer, Know Thy User

Fri. Jun 10th 2005, 06:27pm:

Developers often make the same mistake as politicians - we forget that we are the servants and not the rulers. Our job is not to sit high up in our cubi-thrones mocking the luddite proletariat while spewing forth illegible gibberish, be it code or legislature. The reason we are paid and elected is to solely help the people. It could be a typical office user or the oldest member of the Management who fears new-fangled technology like steam-engines and horseless carriages. Despite all the inherent problems in our industry from massive lay-offs to despotic management that is often unfit for the position, I think we still need to remember that our goal is to make the end-user's life easier and hopefully richer.

While we go about our daily recompiles, deployments, bug fixes etc., concentrating solely on the technical aspect of the development, we often miss the point of the development - satisfying a real need for an end-user. We write code for document/file sharing, instant-messaging, photo editing, report generation, website content management, or something as rudimentary as automating mail-merge in a Word document. They use our wares for sharing funny videos, leaking dirty secrets to everyone on their buddy lists, removing red-eye effects from bad photos, printing copies of goods that need to be labeled and shipped urgently, updating the SoHo website anytime a product goes out-of-stock, and of course, sending out Thank You letters to all the 200 people who showed up at their wedding.

Users don't care about JavaScript's parseInt() function interpreting "005143" as an octal value for "2659". Nobody's going to understand when you try to explain that while the order numbers on all the printed reports are always in the format "000000" and six characters long, internally the order number field is just an auto-increment unsigned long value. And sadly, while typing "5143" will open the correct order, "005143" will open an entirely different order if you used the parseInt() JS function without specifying that the base was 10. What I mean is, yes, we all have problems. Our job is not easy. You spent three hours last week fixing a stupid spacing bug that showed up on IE but not on FireFox or Safari. You spent another hour trying to make sure your site validated after the hack-fix ordeal. And in the end, you find that your boss/client, coworkers, and the web site visitors are completely oblivious to your dilemma and how you overcame it. They don't even seem to care when you tell them about it.

We realize the users don't care about our problems. And to show them who's the boss, we stop caring about their problems. "You can't read the files in the shared folder anymore? Guess you'll have to go to the public computer lab across the campus since we don't allow non-IT staff to use the two spare computers. Have a great day!" Poor user. If she was nice to us, we could've told her that it was because a lot of things went wrong when we were forced to switch all our servers this weekend from Samba to AD. Going to the public lab wouldn't help her either as most of the migration issues were still not resolved. Guess she shouldn't have demanded to the management that "My department needs to share eVisio 2003 GroupWare ShareCom and we were told that we need this thing called 'Active Directory' installed on the shared server ASAP!" Payback is hell, sweetie :)

Sometimes we're not mean, we're just confusing. "It's uh... because the new version of LSASS.exe that was updated last night during the installation of Service Pack 2 also changed software firewall settings and there's no patch issued for it yet." The user has no clue what we just blurted out and will simply blame things on "the computer" or "the database." Of course, had we looked into it, we could've found the simple fix suggested by someone on Usenet - simply open the single port that the user's stock-tracking application needs to listen on for streaming ticker prices. Do we even bother? Of course not! His department was responsible for slashing the IT budget in half this year; we have bigger projects to work on right now and they can live with half the tech support.

If you consider yourself a good "IT Guy" like I narcissistically do, you're going to disagree with everything I stated above. Sure, the user doesn't care about the nitty-gritties of our daily drudgeries but that doesn't mean we are mean to them! No way! I am the best programmer ever! There is no better helpdesk support than me and my team! Of course, we're nice, hard-working and all that jazz, but as I said above, over time we slowly lose the "touch" - we forget who we are really working for - not our home mortgage company, but the seven hundred distributors around the world who use our online sales management web application.

So, when was the last time you called up one of the top distributors and asked him what reports he needed? Did you invite the local distributor for an informal meeting and show her the new features tucked under the "Sales > Accounts > Forecast > Turnover" panel? Or how about asking the distributors with the lowest potential-to-sales ratio whether there was something you can do to help them track their potentials better, maybe an auto-follow up email that the system sends every week until the potential client is abandoned or successfully turned into a customer?

But that's NOT MY JOB you shriek in disgust! We all know it's not. We're getting paid to write code and format the database structures, not end World hunger. However, at our disposal, we have some powerful tools and some very strong sets of skills that, if we choose to, can help solve a lot of problems for many many people.

Imagine if the developers of IE had spent some extra effort fixing the PNG transparency problem then we wouldn't have to even think about these preposterous fixes. A few days worth of their development time would've resulted in time savings of hundreds of years for the web designers around the world. Now put yourself in the same position. Sure, you CAN save the processing department about 2 hours of tedious work daily by making a button that says "Print All" or "Print Selected" instead of having someone selecting each order and clicking "Print Document." I know it's not your fault that they didn't ask you to make a "Print All" button when you were given the design specifications. So technically it is their fault. However, if you spent just a little time talking to the folks using your software and actually observed them using it, you'd have so many more ideas on how to improve efficiency.

That's one of the things I love doing. While it looks pretty unproductive to anyone who happens to walk by, I feel it helps me and my users a lot when I stand around in a busy office and just watch people go about their daily duties. I smile and chit-chat a bit but keep an eye open for repetitive actions. If the customer service person has to get up every time she wants to fax some random document and she faxes about 20-25 documents a day, maybe she needs a fax machine on her desk. Or if she's printing a packing slip from the database on to the shared printer, then takes the printout from the printer and walks over to the fax machine, she just might be better off with a Fax-Printer-driver that she can use to directly Fax documents from your database. And if you see her typing her name in the "From:" field for the cover letter every time she's sending a fax, you can setup a default cover letter template for her that has her full contact information in it.

If you're not the only IT guy in your company then this really isn't your job. Why do you care about someone doing repetitious things in Excel when your job is to make sure the corporate network is protected from internal and external security breaches? Obviously you don't and shouldn't have to. However, there are things you can do in your position - maybe finally allow people to access the company's internal server as long as they have SSH and can learn how to tunnel in.

My point is not that we're not doing our jobs. Of course we are. We work very hard. But every once in a while we need to remind ourselves that in the long term, it doesn't really make a difference if our favorite text editor is no longer free or that RSS is getting more popular than Atom despite it's shortcomings. What matters most is whether our users efficiently use the technology we design and provide. What determines our success is not whether we can manage to cut down the deployment time for our warehouse management product from 15 seconds to 3 seconds. Rather, the fact that redesigning the GUI to let the warehouse guys type in an item number or scan a barcode without having to change the selected field by clicking somewhere has resulted in tremendous time-savings, albeit immeasurable.

At my work, I realize I need to formalize the process of observing the users in the production environment instead of just testing and debugging latently. If more developers did that, we wouldn't have the UI Hall of Shame :)