Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
In manufacturing settings, a factory is set up to produce one specific kind of product. You won’t see factories where on Monday the workers assemble cars, Tuesday they build dishwashers, and so on throughout the week changing products. The most variety you’ll see produced by a typical factory might be four-door sedans and two-door sedans on the same line. Likewise, most workers in factories are trained to assemble very specific subsets of their product. While some companies have found efficiency in a small amount of worker cross training, an auto factory assembly line worker is unlikely to be both a welder and a skilled machine operator, although the frame welder might be trained to weld sheet metal too. The most visible things an outsider will probably notice in a physical assembly line are the specialized tools. You don’t build cars with wrenches purchased at the local hardware store, or even weld with the same equipment a local repair shop might use. Every tool in an assembly line is custom-built to the specific product the workers will build, and usually incorporates a large degree of automation. Another thing you’ll notice in most factories – they are assembly lines, they don’t manufacture all the components themselves. So the auto assembly line will have long lines of trucks and trains bringing pre-built doors, engines, brakes, and other parts to the receiving docks for the line works to assemble into cars.
These general concepts from physical production lines – product consistency, specialized workforce, specialized automated tools, and componentization – can be applied to knowledge workers and even software development. Microsoft has dubbed the application of the principles to software development a software factory. Let’s look at how each of these factory concepts is applied to software development.
First comes product consistency. We’re already seeing that as there are many specialized development providers that have their preferred area of expertise such as health care or banking. Even within larger development consultancies, you’ll often find formal or informal area specializations set up. Health care development is a perfect example of the need for this. With all of the government regulations and inter-related systems driving spending in healthcare development, the more experience a person or company has in health care projects, the more efficient they’ll be on each new project. A developer who has primarily worked in banking many understand in general that regulations will impact his work on healthcare projects, but the developer won’t be familiar with the specific regulations or business processes that are common to all health care providers and that’s a steep learning curve for a new comer.
Next think about developer specialization. This is probably something you already see first hand. On any sizable project, you’ve probably got a person or team responsible for the UI, another for data storage, one for business logic, one for communication, and so on. Developer specialization simply notices that the same developer or team who built the UI for project A is probably the best suited to develop the UI for projects B, C, and D too. In many settings, this happens informally anyway, a software factory just codifies it.
In a software setting, the specialized tools part of the formula might not be familiar to everyone. The idea here is that instead of developing with off the shelf boxed languages and IDEs, you’ll be more efficient if you build your own custom tools and languages for your areas of specialization. Those specialized tools themselves may be built originally from know languages (maybe a specific XML schema) or tools (a unique custom add-in for your IDE) but the point is that once you’ve built the tools, the tools will help you build each future application faster. We take a lot of the automation these tools provide for granted – with IDEs that build GUI components automatically or that provide drag-and-drop interfaces to connect to a database for example.
The last part of the software factory I’m going to look at is component reuse which is nothing new. And in a way, this is a recursive look at other principles at work here. But whether you are reusing components that you’ve built for other projects, buying pre-built components from another vendor (the factory-supplier model), or even using Web services to hook into someone else’s pre-built parts on the fly, the idea is that you aren’t building them yourself from scratch for each project. This embodies the other principles if you use the factory-supplier model because it says there’s some other factory that’s more skilled in building that component and rather than recreate their wheel, you’ll just rely on their specialized factory and workers to buy the wheel from them.
There are some immediately obvious drawbacks to this model, and many of these carry over from the factory floor. Many assembly lines have taken to cross-training workers to alleviate boredom (and boredom leads to lack of attention and product quality and efficiency drops). Software factories will need to do the same thing as few developers will want to build similar UIs for similar industry applications for years on end. Likewise, attrition with lack of cross-training can lead to a hole in a key competency. A key supplier going out of business can be very common in the software industry and could lead to the equivalent of a parts shortage for a software factory.
That is the barest essential look at software factories in a few hundred words. The full theory is much more sophisticated than my rough analogies and involves subtleties I won’t get into here. The principal architects of this theory, Jack Greenfield and Keith Short, have written this book about software factories. (Disclosure: This book is published by Wiley, my employer, although I had no direct involvement with the book or authors.)
For further reference see:
Jim Minatel is a freelance writer for Developer.com in addition to working with Wiley and WROX publishing.
