Programmer for Hire

A lot of people have use for specialized, custom built software, but far fewer are able to create it themselves.  So it is common in my industry that software is created to be used by someone else.  This gives rise to a gap in the perspectives of the creator and user: the creator is often only a user to the extent that they ensure that every piece works as it should, whereas the user needs to use it in a real working environment every day.

What this means is that even a well meaning and highly talented developer can produce something that end users hate, simply for lack of the day-to-day user perspective.  Consider:

Creator: This feature works like a charm.
User: I use this feature 100 times a day but takes 4 clicks to get to when just 1 could do.

Creator: The login system works really nicely and is secure.
User: I get booted out of the system after 20 minutes of idle time, and my usual task away from the computer takes half an hour.

Creator: This downloadable spreadsheet report has all the info about orders placed.
User: I still take 4 hours a week to manually reconcile this report with our CRM system.

Creator: This date picker widget lets you quickly choose your date range for exporting orders.
User: I never need anything but the orders from the last 7 days, but I still have to always pick those dates using this stupid date picker.

This gap is only a problem when there is no communication between developers and users. And it’s not surprising that communication is generally sparse between the two.  Less-than-awesome software is more than common, and so among users there’s a common mindset that that’s just the way it is.  Either it can’t be any better, or perhaps the developer hates them.  (Though the latter is irrational, even I fall for it when I think of the development team behind IE6–I know they were doing their best.)  Both views give rise to a “I’ll deal with it” mentality, perhaps with a “well at least it’s better than the old system” thrown in.  Even if an end user can make requests directly of the developer (seldom allowed to avoid willy nilly wasting of expensive developer resources), the idea seldom occurs as a real possibility.

But what if that communication is strong and the custom development arrangement does allow for tweaking based on such real world feedback?  The above four hypothetical issues are ripe to be fixed with a little bit of tweaking, if only the developer knew about them.

A great solution to this gap is to have the developer become a user in the real working environment after the project has been presented as complete.  That time lays bare a great number of shortcomings that a system might have in actual practice.  It’s fun for everyone involved: the developer gets to be a hero and enjoy the satisfaction of making big win tweaks.  Users have their issues addressed and their needs met: their cool new system just keeps getting better, often within minutes of making a request.  And key stakeholders in the project are delighted by both the improvements and the happiness of the people using it.

A day on site spent beside end users  is something I’ve done now and again, but I haven’t thought to make that a more standard part of my service until now.  It’s that extra mile that provides so much with many kinds of projects.