You get what you ask for!

I had a discussion with an acquaintance recently and the discussion reinforced some of the lessons that I have learned in my own professional career. The acquaintance mentioned an application that they had developed in the past year. The application was was designed primarily for data entry and storing information provided by the users. After deploying the application, the organization soon realized that they had missed an important feature based on user feedback – They did not provide any means for users to view or retrieve the data they had entered! The acquaintance mentioned that the programmers were not to blame as they only designed what they had been asked for.

There were many lessons I could glean based on this interesting discussion.

  • You only get what you ask for!

I was immediately reminded of an experiment that Jerry Weinberg and Donald Gause mention in their book, Exploring Requirements: Quality before Design. The experiment was interesting and here are the details:

In a typical experiment, five teams were given the same requirement for a computer program except for a single sentence that differed for each team. One team was asked to complete the job with the fewest possible hours of programming, another was to minimize the number of program statements written, a third was to minimize the amount of memory used, another was to produce the clearest possible program, and the final team was to produce the clearest possible output.

The results were quite fascinating. Each team aced the objective it was given. Jerry and Don shared the following conclusion:

In short, each team produced exactly what it was asked to produce, and didn’t produce what it wasn’t asked to produce. Before these experiments, we had often heard software buyers complaining about the inability of programmers to give them what they wanted. The experiments convinced us that in many cases, the buyers simply did not tell the programmers clearly what they wanted.

This is exactly what happened with the incident I related earlier. It was a little surreal to hear about a real-life example of the experiment!

  • Information Age and Data

In an age where we find ourselves overwhelmed by data and information, an application that only allows for data entry seems to be anathema to the Information Age. One of the many insights I gained from reading Data Driven was that data needs to flow to be of value. If data is just sitting in a database, it does not add any value. It needs to be able to flow to the right users and decision makers who can make effective use of this data. We cannot lock data up without hearing from the users!

  • We cannot ignore the Requirements Process 

Software projects may or may not have a requirements document. However, there is always going to be a requirements process – the process of determining what the Client wants. I believe that as software engineers, we have a responsibility to ensure that we ask the right questions and ensure that Clients and users receive a quality product.

This entry was posted in Software Projects. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *