About
I have been a proponent of software re-use ever since I started programming in the late seventies. Often, I would find myself pulling out articles with bits of sample code and explanations of algorithms and tucking them away for later use. During my years in the U.S. Air Force as a weather forecaster, I found myself doing the same thing with examples of code to implement numerical models and data plotting routines. I still have boxes setting in my garage, filled with everything I have collected and whenever I start down a path on an esoteric programming problem; you can find me digging through them for inspiration and ideas.
After I left the military in the early nineties and became an independent contractor, I found myself using software factories before I knew what they were. I worked for a company that published software to prepare several types of tax returns. To simplify the entire product suite, we developed what would be considered a primitive software factory that provided each product team with a core set of components, which the teams customized by configuring records in a database and extended with via dynamic link libraries. We were able to significantly reduce our development life cycle time and improve our quality helping to make the company a leader in the industry and as far as I know, they still use those same strategies today.
In late 2005 while attending a training program in Redmond, WA I worked with several people who were evaluating Domain Specific Languages and Software Factories for use within my company. Realizing the great potential in Software Factories. I immediately bought a copy of “Software Factories—Assembling Applications with Patterns, Models, Frameworks, and Tools” and read it cover to cover.
Since then, I have been working on ways to apply Software Factories in my job as a global system integrator. I have written factories from scratch and modified several of the patterns & practices factories to build vertical software factories for use in the airline industry.
The entire process of designing factories is much more complex than designing applications. You need to analyze the commonality and variations across the products that your factory will create. You must develop abstractions for Domain-Specific Models and code generation. You also have to think about who will use your factory and how they will use it, what views do they need, what functions they must perform. You also need to create guidance that is clear, concise and provides the right information at the right time to complete a given task.
What I have found is there is no one single resource you can turn to when you have questions. One must resort to digging through cryptic documentation, forums, blogs and samples of code to find out how to build a factory. This is mainly because building factories requires the use of many different skills and tools. To be proficient you need to be well versed in; the Visual Studio SDK, Domain-Specific Language Tools, the Guidance Automation Toolkit, Visual Studio Automation Interfaces and Text Templates to name just a few. These are not as simple to master and takes experimentation to get things just right.
This site addresses these issues by providing best practices, tips and examples from the real world. Previous work created by the patterns and practices group at Microsoft, the greater factories community and myself are used as a basis for the topics which make up this site. I have taken what works and documented it in easy to understand steps with plenty of code examples that you can both learn from and use immediately.
My hope is that this site becomes a valuable reference for building software factories and in using it, you are able to save yourself the various bumps, bruises and scrapes I had to endure when I first started building factories. I hope that with it, you are able to help the development teams you work with, to work smarter, not harder and in doing so help to industrialize the world of software development for everyone.
Jim Lavin
