Solution Files

If you have used any version of Microsoft's Visual Studio IDE you will recognize this post's title as the file type that identifies a project's top level descriptor. In that you would be right. You may also assume this post is about Microsoft development products or platforms; in that, you would be wrong.

The reason is chose the above headline is that I feel it captures the essence of our craft. For the most part, what we as developers deliver to the customer are files. But they represent software that provides solutions. The operative word, of course, is solution(s). The medium of delivery is irrelevant as it might be a hosted service, a memory instance, files on a hard drive or shrink-wrapped media —yes, some people still ship those.

The point of all this is not only to remind ourselves of   which side our bread is buttered on, but of what our definition of "done" or "complete" should be. This might seem redundant until one notices the the large numbers or applications that are marginally useful to their intended users but  contain all sorts of buzz-worthy technologies and widgets. 

A notorious example of this was an in-house time management software my team was fated to use for way too long. It had all sorts of fancy popups, submenus and taxonomy representations yet was unintuitive, difficult to navigate and sacrificed performance on the altar of excessive widgetry. It was application hell. 

This, I am afraid, is what happens when we lose site of what our core job description: provide productivity boosting solutions to user problems. In the same way in which we expect our tools to allow us to do more in less time, our users also want some gain in exchange for the time they invest learning to use our software.  I think that's a fair expectation, don't you?