Software Fitting Need

Software is an exciting area of endeavor. Through it, a cold piece of hardware comes to life and takes on the seemingly impossible challenges of our diverse world. However, as the world is complex, software too can be complex. How well it fits the actual need will determine how well it succeeds. Determining that need, and fitting software to the need, is something that computing professionals have done, or attempted to do, for many years. Sometimes the results are spectacular, and other times the results may not be so memorable. Many of the issues start with determining what the actual needs are.

When one thinks of needs, especially with software, the sky is the limit. However, the sky is a pretty big object, and often the list of needs need to be brought down to earth a bit. Is every feature wanted something that is actually needed? The problem may be simply stated as “for every feature added, some additional complexity will be involved.” Let me use a quick example to demonstrate the issue. We have two people who want to create a document which contains three stories. The first person, Betty, is an older retired individual who is writing their daughter about their trip over the summer. The other, Julie, is a college student creating a newsletter about their club's recent fund raising efforts. Betty just wants to to get the stories written in a way that they can be easily read so that she can send her letter off to her daughter. She doesn't use a computer that often, but can't write well enough by hand to be legible, so she wants to type it up. Betty doesn't care about fonts, text alignment, columns, margins, headers, footers, etc., her needs are very simple. On the other hand, Julie wants her newsletter to have multiple columns with lots of different fonts, and articles which have text that flows to multiple columns on multiple different pages, much like a newspaper. If Betty was provided with a tool that had all of the features that Julie needed, she would be overwhelmed as to where to start. On the other hand, if Julie was limited by the needs of Betty, her creativity in laying out her newsletter would be suppressed. Both people need to put text on a piece of paper, both people have very different needs. The same software will probably not be able to handle both of their needs effectively, as the complexity required through the addition of the features needed to appease Julie will totally crush Betty one way or another.

This is a fairly straight forward example, but there are things that may be more subtle. I once worked on implementing a new accounting system in a company. The commercially available software was written to be specific to the industry, so everything should have gone well. There was a hidden problem, however. The software assumed that the accounting department was of a certain size. There were so many controls in the software, for each position in the accounting department, that it became almost impossible to actually use it in a smaller company. One person had to log out as one type of user, to log in as another type of user, to approve their work to get to the next step. In this case, although the main needs were certainly handled (through the software being written for a specialized industry), the software failed through missing the target for a secondary need to be more simple from a personnel/department size perspective. The need to have advanced access control superseded usability.

One of the great rewards as a software programmer and designer, is to be able to distill the actual needs in an environment and bring to life a piece of software that actually fills those needs. When software actually “works”, productivity goes up, staffing needs go down, and the company succeeds. On the other hand, a piece of poorly fitting software can so hinder company operations that failure becomes imminent. Of course there is a cost. When looking at implementing software, the needs may be so specific that pre-written commercial packages may not be an option. Much effort needs to be put into reviewing needs, comparing them with existing solutions, evaluating processes, reviewing customization options and determining what really needs to happen to be successful. One of the great dangers of today's computing world is how this critical process is written off as unneeded. At one time, you always hired a computing professional to evaluate your needs. Now, these important decisions may be left in the hands of an office worker, or other individual. While these individuals may very well be talented people, who want to do good, they may not have the breadth of understanding to see the whole picture. The result may very well be sub-optimal, and the problems may not even be initially seen. In the long run, the small problems may fester into larger deeper issues that may be harder to overcome. The success of a well implemented piece of software will result in such cost savings in the long run, that this step should not be simply written off. A piece of software that actually works like the office works, or “thinks” like the user thinks, is a challenging order, but it is spectacular when completed.