Software Factories and Packages

I read Alan Wills’ blog about his domain-specific languages tutorial at UML 2004, and it reminded me of some thoughts I had about the difference between a Software Factory and a Package.

A Package is a chunk of software that is designed to encompass a set of situations within a domain. There are mechanisms for customizing the package to suit a particular situation. These mechanisms are domain-specific languages.

So what’s the difference with a software factory? Darrell Norton raises this exact issue in his blog.

It’s actually all about early vs late binding, openness, effective integration of people into the process, and how many dimensions of variation are involved. Usually, a package predefines the runtime engine and runtime environment, and provides customization points only for functional variations. People who have worked in a systems integration house know that most packages believe that they are the centre of the universe, and getting them to work together can be something of a pain. In contrast, a Software Factory can enable variations at all points in the lifecycle: non-functional requirements, deployment requirements, environmental requirements, security requirements, integration requirements, etc.; and provide tailored environments for the people who do the work.

Last year at workshops about model driven development I kept bumping into people working in robotic space exploration. Building the software for a robotic space vehicle is an extremely painstaking business. It has to fit in tiny amounts of memory, make very complex optimizations, and never crash. Even the compiler is custom built. I am no expert, but I am sure these people would not dream of using a package. What they did want to do was build models of all of the functional and non-functional requirements of their robot, and generate the executable code. That would be an interesting software factory.