Software Product Lines

Several years ago, I gave a presentation at the SPLC2 conference in San Diego on Software product Lines (SPL). The conference was hosted by the Software Engineering Institute at Carnegie Mellon, who have championed the ideas of Software Product Lines for some years now, and are making great progress maturing their formal descriptions.

While I worked at Nokia, I experienced first hand how software product lines may work in highly complex environments (Nokia was inducted in the SEI Product Line Hall of Fame in 2000 during SPLC1).

Software Product Lines enables companies like Nokia to develop very large software deliverables, based on a 'factory' line model of development. For Nokia, different teams deliver different part of the software, which are then combined and built into final deliverables by product programs. Each software line, develops a well defined part of the product. If compared to a car, you could say that one line develop the wheels, while another develop the engine.

The product programs pick the 'wheels' and 'engine', and put together most of the car with components delivered from a number of software lines. They then apply the 'paint' to the car, in terms of product specific configurations such as number of keys on the phone, specific ringtones, background, colors, number of phonebook entries, etc.

A mobile phone has many thousands variability points, but by using software lines, these can be kept under control, and released in well-defined 'bundles' at regular intervals.

I've co-authored a research article that examines the Nokia Software Product Lines in more detail.

One of the drawbacks of Software Product Lines however is the speed with which software can be developed. Because components of lines are delivered to many products, each deliverable can easily end up being defined years ahead of delivery. This means that organizations can become very rigid in their product deliverables, and unable to quickly add new features.

Where an organization with just product lines quickly can add features to a product, an organization with software product lines becomes limited by the concentration of knowledge to each line, and the inability of product programs to develop complicated features that span multiple lines. Furthermore, duplicate work is often done because each software line manager (or guardian), often will refuse to take back changes made outside his line.

It doesn't have to be this way. If a system is put in place where software product lines can become more flexible, a process for 'adding' new external features back to existing product lines can be put in place. With a strict review process in place, this can enable external software developers (external to the product line) a way to add software back which can be utilized by the entire organization.

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.