Software Product Lines

This is the first of a series of articles on an approach to systems architecture called “Software Product Lines.” To introduce the concept, let’s ignore the word “software” for now and focus on what a product line is in a more general and tangible fashion.

If you are in the market for a laptop and go to Dell’s website, you have a choice of several different base models that can be configured to your specification. Once you select the base model, you can configure things such as the size of RAM, size of the hard drive, type of display, etc. What makes this possible is a hardware architecture of various components that can fit into the same slot – compatible electrically as well as physically. This allows Dell to create and mass produce (or purchase) several standardized components and simply plug them together to create a customized product at a reasonable cost in a short timeframe. When new technologies come out that require changes to the base product, like ATA laptop hard drives, Dell spins up a new product line with that one modification reusing the old technology and components that is still valid, tried, and true. This sounds like a great idea and solid common sense, doesn’t it?

As with anything, there are challenges to this approach. Take for instance a design flaw in one of the more heavily shared components, such as the motherboard, where the power connector solder joints go bad due to heat and constant plugging/unplugging. This one design flaw could end up costing dearly in repair and possibly recall expenses, as a significantly higher number of devices are impacted then if the system was not as modular. It is also significantly more difficult and time consuming up-front to design, build, and test a system that shares components. In a product line, tight adherence to specifications needs to be considered for future compatibility. Take for example the wireless network/Bluetooth riser cards found in many laptops. Let’s assume the bus timings are just a hair off spec, but the current crop of hardware is tolerant of it. Newer technologies coming out six months later may not be tolerant. A non-product line approach would be to make a revision of the entire system – which is required anyway; however, the product line approach requires significant expense to revise and test one or both of the components to assure compatibility.

Software is not very different than hardware when it comes to product lines. Most high-end software packages are heavily customizable so it can integrate into a variety of environments. Microsoft’s SharePoint product is one example, SAP is another. These two products are off-the-shelf packages intended to appeal to a very large market. There was heavy up-front investment by the vendor in design, documentation, interfaces, components, external training and certification programs, and more. But what if your product is very specialized with a small market? Even worse, what if your product is designed for small to medium sized businesses that typically can’t afford or will not have the resources to self-customize such a vast system? To top it all off, certainly, you cannot afford to invest in the amount of up-front work required to build, test, and debug a heavily customizable system given the small size of your target market.

Enter the concept of Software Product Lines. It is important to note that this is an engineering approach to solve a specific business problem. Using the Software Product Line methodology in a business environment that is not controlled or the problem domain of the customer is not well understood will cause you to paint yourself into a corner with no easy or cheap way out. Another salient comment is choosing this approach should not significantly change your development methodology (assuming, of course, that you have adopted a legitimate methodology in the first place). Finally, this approach is NOT a method of implementation, merely a way of thinking from a design perspective of what needs componentized. The decision to use a Service Oriented Architecture to implement a Software Product Line is off-topic – these are two different animals entirely.

Part II of this series will delve into some of these concepts deeper.

Abstractions in Design

Peter Torr from Microsoft blogged that Changing Abstractions in an Object Model is Hard. I think of system design as the "art" portion of software development. I consider a "programmer" as a person who is familiar with the technical (both normal and arcane) details of an operating system, language, or framework. The "software developer" needs to know the former, and branch out from there, thinking of object models, end-user usability, threat models, abstraction, and extensibility.

The italicized font portions below are quoted from the blog entry (some liberty with snipping was taken for readability out of context). If you are interested in learning more about solid design, this essay is a good high level overview. These are (IMHO) the salient points of the essay:

But to make a[n] object model easy to use, you want to simplify (abstract away) many of the details so that the developer has less concepts to understand and so that they can "discover" and use the features of the object model in a natural way.

...you don't want to make your system more complicated than it needs to be. Complications lead to bugs, and unnecessary complications lead to unnecessary bugs. Having lots of "pluggable" components (interfaces, abstract classes) makes it hard to reason about the system (and to threat model it!) because you can't be sure what any given extension will do.

Or, if she is just getting started with the object and starts to read the conceptual overview, there will be far too many things obscuring the basic design that she won't be able to see the forest for all the trees. This is a real concern, since documentation is incredibly hard to write and minimizing the number of concepts a developer must grasp to use an object model is crucial to making it usable.

Joel's best articles reviewed

Even though I have a billion other things to do, I couldn't help but get sucked into reading every one of the 112 (as of this writing) articled submitted to Joel's best articles on Software Development. This is a deviation from my normal content, but there is value to be gained for most all readers in the Software industry - designers, marketers, and developers.

Here are my favorites (not necessarily the best of the bunch, but ones that got me to think), I will link to the nomination post, suggest the audience type, and give my .02c. :

Church of XML. If you use XML and like sarcastic humor, this may interest you. At least, I hope it is meant to be sarcastic. XML is great for some things, but it is not the holy grail solution for everything data related. I remember in Y2k working for a company whose directors told the development staff that we must use XML. We quickly coined the phrase "buzzword compliance" to describe the requirement. There was no possible use for XML data in our application where XML was a viable alternative, much less a better one. At a later company, the value of XML as a method of integration with our customer's systems and as a communications mechanism (XML-RPC) was profoundly positive. Members of the Church of XML may want to defect after reading another few nominated articles: ant and XML, and Soapbox: Humans should not have to grok XML.

How many Microsoft Employees Does It Take to Change a Lightbulb. Any developer should enjoy it, but managers (especially ones driving deadlines) need to read it. I am a big fan of Eric Lippert's writing style. This one delves into the cost of fixing a bug. I prefer this one to the main article nominated since it is more to the point. Setup developers may want to read The anatomy of a bug as it deals with an uninstallation issue, and something you may want to think about. Both articles do not mention the cost of fixing a bug in terms of dollars (refer to your copy of Code Complete for more on this). Although you may disagree with Eric's line: "At Microsoft we try very, very hard to not release half-baked software," the point he is trying to make is if you do release bad code, it costs a bunch (in dollars and manpower) to fix it later. Almost on-topic is a 20 minute video of an actual bug triage meeting at Microsoft. Good stuff.

Plus ca change. Reading for anyone interested in how standards can be used to even the playing field for small software vendors. Or perhaps not. While I am not heavy into the web standards discussions today, at one point I was. To quote The Gunslinger, "The world has moved on." HTML's initial purpose (IMHO) was to allow me (the user) to render content as I (the user) wanted to see it. Netscape and Microsoft decided that their extensions to HTML would be the differentiators between their browser products. The content producers decided that web content should be shown to the user the way the content producer wants it to look, and with these extensions, they could. This seriously limits the accessibility of the content for people with disabilities, which was one characteristic HTML was supposed to give content producers (and users) for free. Flash and Shockwave further limited the control of content by the user. My thoughts on this today are for vendors to add their extensions whenever they want. If the extension provides enough value, other vendors will pick up on it and it will become a defacto standard. Today, implementing a standard in a web browser is not good enough to get you lined up at the starting gate. Look at Internet Explorer - massive share and not 100% compliant.

Lean Construction. Audience is general developers interested in planning. If you have read Code Complete, you will notice the use of metaphors throughout, one of which likens software development to a construction project. This article is the result of a software developer attending a class for construction foreman related to project planning. Some of the takeaways trumpet agile development methodologies. I especially like the quote: "master schedules are useless for planning work, contracting practices create islands of optimization, and there are large opportunities for productivity improvement." Is the author referring to current software development methodologies or old construction planning?

The 5 Pitfalls of Estimating a Software Project. Also see "Repeat After Me: I Am Not In the Software Business" in the same nomination. Everyone should read these. I have nothing else to add - they both have excellent points and are short enough to easily grasp it.

In the Spirit of C. Hardcore programmers. This one is fantastic. In the "managed" world of programming frameworks, it is easy to lose important roots in development. I am completely surprised by the number of programmers that do not know C or C++ well enough to code a real application. I've found that the best programmers are ones with roots in C. C developers tend to be able to learn new languages quickly, and pick the best language for any given programming task. Noteworthy quote: "In my experience there is almost no limit to the damage that a sufficiently ingenious fool can do with C++. But there is also almost no limit to the degree of complexity that a skillful library designer can hide behind a simple, safe, and elegant C++ interface. "

Ten Ways to Kill Design. Product managers are a good audience. This talks about new designs and pilots, and how/why they fail (unrelated to the design itself). For more information on the design, spec, and requirements, please check out another nominee On Reqs and Specs.

Hazards of Hiring. For anyone considering beefing up your workforce or looking for a job. It is an Eric Sink article that is very good, as usual. There are more worth reading that are related, such as programmers are not hackers.

Simple is Beautiful. All developers. Quote: "If you manage to write some code that a non-programmer can more or less understand, then you know you're there. The code should be simple and self-explanatory enough that should be a breeze to refactor in the future." Another nice quote is from Brian Kernighan (an inventor of C). I have this quote hanging up by my desk: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

We built it but no one came. Product Designers. Quote: "the thing that engineers love most about their technology is precisely what prevents them from making money." I looked at Steve Johnson's blog and he writes lots of great stuff in the development/marketing arena. Subscribed! I recommend anyone in the position of designing a product for the Average Joe to pick up a book Crossing The Chasm by Geoffrey Moore.

Growing, Pruning, spiking an architecture. Designers. Quote:"Good architectures are those in which it is considered easy to create the features desired."

What is a Web Service. Anyone. I agree with the other commentator. This is more of a definition, but summed up well. This allows me to segue into the topic of dynamic vs. loose coupling in typical service oriented architecture, although this latter link is more specific to architects.

Exceptions vs. Status Returns. Developers. The age old debate on the use of Exceptions. My position is contrary to the nominee. If you take the debate further, there is the use of exceptions as flow control. Exceptions are good when used appropriately - for the exceptional case. Too many times I have seen code that encourages or uses exceptions when simply returning a status value would be better. There are some good examples here. An OutOfMemoryException is a valid use of an exception. No matter how deep in my code I am, this is something that is highly unlikely to be handled appropriately or anticipated.

How to tell your personality from your code. Developers. Quote: The Obfuscator: "while(*a) *b++ = (islower(*a))? *a++:*a++ + ('a'-'A');" I have not only worked with each of these coding personality types, but I have been them. I wonder what my code personality type was today?

Choose your competition. Entrepreneurs. Quote: "The existence of a competitor indicates the existence of paying customers." As usual, good stuff from Eric Sink.

State of Affairs in Computer Science Education. Everyone. I was going to write a blog entry about this one. Since I'm trying to get a new sheepskin, one of the classes I am required to take uses a book "Object-Oriented Application Development using Visual Basic .NET" by E. Reed Doke. The book stinks. The fact that I must take and pay for this "capstone" course instead of one where I could actually learn something new is one problem with the system. In this book, the author uses a phone number as the primary key on the Customer table! I guess with phone number portability, this is an acceptable PK! We are teaching people this? The brilliant author creates a method in the Customer class called TellAboutSelf() that returns a string representation of the object. Wouldn't it be industry-standard and expected to override Object.toString()? WTF! This simply adds to the retraining requirement of new grads that enter the workplace. This is another segue into yet another nominee Eric Lippert's Cargo Cult Series. If you are a new or experienced developer, and especially if you are still held captive by academia, this series is a must-read.