Tuesday, January 15, 2008

Commercial Software on Internal Project Constraints

I was sitting in a design review meeting yesterday and I learned something about what happens when you try to develop a piece of commercial software with the time and budget constraints on an internal intranet application. I hope this is not a surprise to anyone, but it seems to not be evident to the powers that be where I work.

First, some background. Yesterday, my development team was handed a design that suggested that when creating a link to the page of an item (document, comment, library, etc.) within our own site, the user should copy and paste the link from the browser to a form field and the data would be stored as a URL. We told the design team that doing so was not easy for the user because they would need to have another browser or tab open. We told the design team that it was more error prone and harder if not impossible to validate. We informed them that storing the URL as data would make tasks such as getting the id or title of the item later more difficult.

We suggested that at the cost of maybe a couple extra hours of time, we could use a set of drop downs to filter and select items. We said that ideally, a good selection control would be designed and developed that could be reused across the application, but with the quickie drop down compromise, the task would already be much easier for the user and the data would be stored in a way compatible with future improvements. After the meeting, the lead-visionary / president handed down an edict that the original design would stand due to time constraints.

There are many differences between internal software projects and commercial software. With internal projects, there is usually a fixed amount of time and/or money that the company is willing to spend to solve a problem. The development team must do the best job they can within those constraints to improve a current process. If that means it takes a user 2 forms and 5 clicks to edit a customer's first name, well at least it's better than the current punch card system. Making the system better and better is not necessarily justifiable if there will not be enough ROI on the development time for the one company that will use the application. You hit the point of diminishing returns very quickly.

With software, there's no excuse to hold back on the polish. If that one form can not be submitted without a single click of the mouse, it better be a technical impossibility, not just a hard task. "I'm sorry sir, no one has figured out how to make a web page read people's minds or submit when they blink yet," might be a good enough reason in this case. But the thing to remember is that cost of making a better software product will be spread across all of your customers. If you don't find this to be true, you are probably not running a software company.

In the end, the most important thing that I took away from the meeting turned out to be: when a software company creates their product with the constraints of an internal development shop, it is an almost certainty that the result will be a piece of software that sucks.