A train ticket to Brisbane - the very beginning

Hi all! I'm Frank. I would like to begin a series of short articles about code designs in English. It is because I found that we have nearly no chance to use English, especially in writing. I can't guarantee that there is not any types of mistakes, including gramma, spelling and knowledge ones. I do hope that there will be some comments so that I won't feel alone.

Yesterday, a strange story came up in my mind suddenly: What will happen if a person get a task about buying a train ticket to Brisbane from his boss?

As all we know, Brisbane is in Australia. And a train can never running over the sea. Probably, you will refuse to complete the task if you are not crazy. In an alternative way, you might suggest you boss not to go there by train, but by airplane. The reason for which you will persuade your boss to change the travelling way is that you speculate the main object is not to travel by train, but to arrive at Brisbane.

It is a common sense. However, when you're in a designing team of a software project, you might not notice that. Sometimes, you customers will order you to design a function or a page, which is not so suitable in the information world. When the old-fashioned guys are asking you to do so, they are neither right nor wrong. In the real world, human can not process a business in a perfect way as computers do. For example, they can not remember every thing, create relative links to every thing which ought to be, or querying information in flexible ways.

Let's take a close look at this real case:

One day, my boss asked me to do a business support system. In this system, he specified some detailed functions. One of which is a page in which it could show up a report ordered by month and should have some specified columns. At the beginning, the system was designed as what he expected. However, he found some more new demands, which meant you should provide some more pages with different ways of ordering, and with different kinds of data under each columns. That became a totally mess since the system is not designed to be like that. It was hard designed. Any new requirements would need a completely new set of codes behind a completely new page though we have a business layer and a data adapter layer.

Finally, we found that it was a task to buy a ticket to Brisbane: The boss actually need a support system which can report any sets of information in any ordering and grouping ways. So the system should not be designed to make a page for each specific request, but be designed to gather any information in any proceeding way as ones wishes. How would this happen?

In fact, the boss didn't realize all the requirements at the beginning. What came up in his mind is the most urgent stuff to be resolved, for example, a monthly report about revenue in sales pipeline. As soon as this was done, he would think about something more as the system brought him so many conviniences. So, the first requirement he discribed to you would sound like to buy a train ticket to Brisbane. Although he didn't mean it.

After we realized that, we designed a module to render a reporting page by explaining an xml configuration file. Thanks to this module, we can produce many pages to satisfy abundant of demands without coding any more. What we have to do is just providing different xml files. And next, we also designed a module with which you can pick up the fields you want to show up in a report and select a way of statistic. That module will generate the xml configuration files for you. In another words, I bought an air ticket for him.

In this case, I learned that it is very important to dig into the requirements before you start designing. Knowing the requirements provided by customers is not enough. Some times they just don't know what would be the best solution for them.

Alright, what if you did buy a train ticket to Brisbane? Guess what might happen if you still can't feel the coming terrible situation? I will try to tell a different story in the next essay.