Software Factories and Building Systems
Sunday, September 2, 2007 at 10:28PM
Toby Considine

Despite all the software written in the last 50 years, the software backlog is growing. Just about everything we buy today has embedded software, and integrating that software requires more software. Software factories are a set of concepts and approaches to the growing backlog of software.

Many developers disdain any structured implementation as is required to support software factories. Too much software is still written by some variant of the lone programmer, coding everything from scratch, and scorning, often angrily, any layered architecture as inefficient. I spoke to a class on Friday at Case Western Reserve, on building interfaces and GridWise, and one of the first call outs from the crowd was on efficiency.

Maximum software efficiency matters in a few places. I want device drivers to be fast. I want database hash tables to be blindingly fast. I want network protocol stacks to be fast; I also want them to have a layered interface so I can swap them out. On my first commercial contract, I was obsessing on an efficiency issue. I was using every technique taught in the Computer Science Department of UNC. A senior programmer pulled me aside and pointed out that if the program stayed in place, unchanged, for 10 years, it would cost the data entry pool a total of between 13 and 15 minutes in additional entry time during that period. He suggested that as I was currently ready to start my 3rd day of tuning, my efforts might be inappropriate…

Keith Short has compared software development efforts to food preparation. When you go to a good restaurant, you choose the meal from the menu. The chef has designed the menu, chosen the ingredients, designed the processes, and purchased the equipment used to prepare the meal. The line cooks prepare the meal you chose from the menu as requested on your order. They may modify the standard menu item on the menu in standard variations (“Medium rare”), or to meet special dietary considerations, or even prepare a meal not on the menu.

Developing software without development tools is like going to someone’s house for dinner. The cook may never have made the dish before. A whole array of spices that may never be used again might be bought for this meal. Prep work is far from efficient. The experienced host has plenty of wine, ready to serve just in case the dinner comes out an hour late. Last minute special requests are difficult to honor; the whole party will usually eat the same thing. While the company and occasionally the food might make the evening memorable, the result rarely competes on effort, or true cost, or on predictability of result, with a meal from that good restaurant.

Keith Short has written about software factories on his site ( ):

A software factory is a product line that configures extensible development tools…with packaged content and guidance, carefully designed for building specific kinds of applications. A software factory contains three key ideas: a software factory schema, a software factory template and an extensible development environment:

By analogy, the architect sets up the software factory by performing the roles named above for the chef. The well designed kitchen is the development environment; the processes are the food line. The schema is the menu and the recipes are the software templates. The developers, then, have the role of the line cooks, following recipes, making minor adjustments to defined practices, and adding a few custom requests.

This approach sounds tailor-made for the problems of embedded building systems. These systems can be described as fitting a limited number of functional categories. Albeit with different sensors and controls in each instance, and different spaces and people supported in each installation. Each system should be properly factored systems and expose a standards-based interface. We can expose building systems as a family of applications defined around a common set of WSDL/EBXML. We can define the Web Service patterns we want to use, as well as configurations and the security policies we would like applied.

Software factories are more than just a strategy for modeling tools and Domain Specific Languages (DSLs); they are a way to think about software development using pre-defined content. They respond to the problems of rising technological complexity and expectations of users.

Do any of my readers have experience using software factories in this domain?

Article originally appeared on New Daedalus (
See website for complete article licensing information.