Hello World Revisited

So, you have to write a new software application. It's called Hello World. When it runs, it prints out "hello world". What do you do?

As previously discussed in my article "How to move beyond requirements", it is essential as a Software Architect that you constantly follow my mantra of "Think crazy, act sanely". However, what can you practically do to keep your software nimble?

As any software developer first starting out, you probably have written one or more "hello world" programs in your time. I use it as a glorified example of a simple initial requirement that later grows. Imagine that the customer wants other texts to be written, maybe wants the text to be dynamic, and possible wants it printed on a printer instead of a screen.

Here are your options for making "hello world" future proof:

1. Put the text "hello world" in a global definition. If it ever changes, you only need to change it one place.
2. Have your program read "hello world" from the command line. Now anyone can change the text without even recompiling.
3. When reading from the command line, write the text to a file, so next time the program runs it can check the previous text and print it again if no new text is offered.
   
4. Add an input parameter that default to "screen" so the user can specify where to print the text to, like "printer".
   
5. Add another input parameter that could specify the color to print.
6. Prompt the user to enter all these questions on the very first run, then store them to a file, and use them for subsequent runs
7. Prompt the user only if a special command line parameter is added.
8. etc. ad nauseum.

It quickly becomes obvious that you can add a LOT of things to just this simple little program in anticipation of future changes. Some of you might be asking why? Why add all this when the user haven't asked for it?

The purpose of adding these features is that it is faster to do from the beginning. You can architect the changes into the program from the start. It may take 5% longer for development to think about them, and 10% longer to implement and test. But re-writing the program 6 times as new requirements trickle in will take 100% longer. At least !

As a Software Architect, you must weigh the immediate cost of spending some up-front quality time thinking, versus spending a lot more time later re-architecting.

Now, let's consider a real-life example.

In 1996, I was tasked with writing the "Menu Server" for Nokia's Series 40 phones. This server was to handle anything in the menu system for all S40 products. At the time, the S40 User Interface (UI) was text-based with only lists of menus. You are probably thinking this sounds fairly easy, so let me give you a little list of considerations that I had to take into account, a list of features the Menu Server had to support at the time I was writing it.

• Support for hundreds of languages, including Arabic and Chinese.
• Support for sub-menus
• Menu-indicator showing the location in the menu to the user (like 3-1-4)
• Help, after 15 seconds help is shown.
• 4-5 different layout of the menu, like single items, items with a sub-text (like phone book), etc.
• Menu can be activated from various places, to it must support 'jumping' to a menu item
• Sometimes, pressing 'back' goes two levels back instead of one.
  
• Support for variable keys. Each S40 phone can have different ways of navigating the menu.
• Scrollbar
• Header showing highlighted menu
• Wrap-around scrolling on some menu's, but not on others
• Some menu items has extra functionality, in which case a text would be shown on a special function key
• Etc.

As my first task developing the Menu Server, I decided to write a requirements documents with all of these. There were literally hundred of little things it had to do. The document helped me focus, and group the requirements into logical groupings.

After this was done, I did a brainstorm. I literally came up with more requirements, thinking about how phones might develop in the future. For example, I considered:

• Different fonts and colors
• Graphics would come (at the time only text phones was available for S40).
  
• Different Screen sizes would bring new layouts
• Timeouts would change
• Help texts would change
• Navigation options would change
• We may get touch-screens eventually

Based on these very broad concepts of the market and technology, I came up with a list of features that I needed to build into the Menu Server, although none of these were initially required:

• Support for Icons
• Support for dynamic layouts
• 4-way scrolling
• Dynamic event handling (would handle eventually touch-screens)
• Support for colors
• Configurable timeouts
• etc.

I had a bunch more, but they were so far out I had to let them go.

As you can imagine, developing the Menu Server suddenly became a very different effort than originally envisioned. I had to make everything dynamic. For the Nokia OS, this meant that the entire menu system became configurable. Every menu, and all of its behaviour became configurable, which meant that the extra functionality really was a matter of configuration, rather than coding.

When I was done, the menu supported almost all of these extra features. I couldn't test them all the way, because I didn't have the hardware to, but 3 years later, when Nokia introduced 4-way scrolling in the main menu, using icons, I got an e-mail from the center in UK. They had flipped the switch, and turned it on, and it worked. I probably spent a month extra thinking of all this, and writing the extra code. But three years later, another person had taken over, and he would have had to re-architect the entire Menu Server has I not done it.

With very little 'relatively speaking' effort on my part, I was able to save time in long run. Lots of time, for by now most of these features are in use.

Was there any drawbacks? Yes. The Menu configuration became rather big an complicated. Partly as a consequence of the Nokia S40 UI Architecture, which did not allow for anything more fancy than tables. Was it worth it? Definitely.

So remember... Think Crazy, Act Sanely.

A little more effort up front, will save you a lot of effort later.