In this post I address, and clarify, the top 5 myths that I often hear about Software Factories, especially in regards to small software development projects and organizations!
When talking to friends, colleagues, and customers about Software Factories within smaller companies, I often hear very similar objections why Software Factories seem not relevant to them. In reality however, many of those reasons are actual myths and in this post I will bust the myths that I hear most commonly.
· Myth (1): Software Factories are heavy weight and complex.
Software Factories are all about systematic reuse, development automation, and guidance in context. While the four basic concepts of Software Factories (Software Product Lines (SPL), Architectural Framework, Guidance in Context, Model Driven Software Development (MDSD)) can be overwhelming, in reality some (or all) of these concepts are already used in a practical approach in smaller development teams. The Software Factories approach is only trying to build on and extend these concepts to provide a structured and coherent paradigm for software development. Like all paradigms this is not a silver bullet and it requires deep domain knowledge, technical knowledge, and common sense to successfully implement it. Actually I saw implementations of teams between 2-10 developers that cover around 100 function points in a Software Factories style approach. Interesting enough the developers didn’t know that this was basically the implementation of a Software Factory. For them it was an efficient approach to systematic reuse based on their knowledge of the domain, software architecture, and the software development process for their products.
· Myth (2): Software Factories promote a Waterfall process.
No, absolutely not. Software Factories are usually (and should be) developed in an iterative process. Software Factories do not promote any specific process as such, it is up to you to define a process that fits your project and organization. What it does mean is that usually after producing multiple similar, yet distinct products you would take a step back to think about systematic reuse. In Product Line terms this is called commonality and variability analysis. The key task is to start identifying common parts and, even more importantly, identifying points of variability. These variability points will be filled in at the most appropriate time (e.g. design, time, implementation time, compile time, configuration time, start-up time, runtime,…) of the systems. This analysis helps us to extract functionality from the existing systems and to refactor to reusable assets that can be used as components by the product developers. We are not just looking to reuse source code pieces, but also requirements, the architecture, configurations, scripts, test code, documentation, etc. and we do all this in an iterative fashion. This enables us to grow the reusable assets over multiple iterations and to stay agile in order to learn and adjust our development to changes that become necessary.
· Myth (3): Software Factories are only for large scale development projects and not applicable to smaller product development teams, as they are often found at Independent Software Vendors (ISVs).
Software Factories are often realized in small development teams consisting of only 2-10 developers. While the paradigm supports Software Factories to also scale to larger organizations and teams, in reality the implementation today is done in small teams. As mentioned I know many small teams that successfully implemented a Software Factory. Many times the team does not call it a Software Factory, but the implementations have the typical attributes that define a Software Factory such as: Systematically reusable components (not just source code), automation of repetitive tasks, Domain Specific Languages (e.g. for configuration, scripting) and guidance provided for the developers.
For example, in the last Software Factories implementation I worked on we were between 1 to 3 developers involved in the implementation at any time. We successfully implemented a Domain Specific Language (DSL) and some Guidance and Automation Packages to support development of a team of 8 developers.
· Myth (4): Software Factories need very large scale up-front investment.
This myth is closely related to myth(3). As I mentioned in many cases the Software Factory implementation is fed by already existing implementations and components that can be refactored into reusable components without much effort. Even if that is not the case, the investment should be fairly small if a iterative development approach is used. For example in the Software Factories implementation discussed in our article at http://msdn.microsoft.com/en-us/library/cc496679.aspx the initial investment into the Software Factory was only 20 staff days and we could have split this effort into two iterations with 10 staff days each.
· Myth (5): Software Factories do not provide a ROI that justifies the investment.
This is something I was fighting and deliberating with for many moons. Nevertheless, in the article published on msdn http://msdn.microsoft.com/en-us/library/cc496679.aspx we show that there can be substantial ROI. The ROI is obviously project specific and we can only achieve a good result if we make sure we provide reusability and automation for projects and areas that are in fact reused. Only then there is a ROI. I believe there is still a lot of repetitive code that we write for each of our products, and if we can define similarities in our products we have the chance to provide a substantial ROI when using the Software Factories paradigm. In our results we achieved ROI’s between 80% and 300% because of carefully choosing the project as well as the scope of the Software Factory.
After all the good news a word of caution at the end ;-): There is no silver bullet and Software Factories, like all software development paradigms come with opportunities and liabilities. Finding the right balance for your project, and selecting the best possible paradigm requires an objective analysis of the products, requirements, technologies, and environment. I will pick up on these topics in my next post….