Software Factories..is it worth it?

Last week, I read an article published by Microsoft in cooperation with Siemens that discussed the business case of investing in software factories. In the conclusion, the writers claim that a well-designed software factory can improve your productivity by a factor of 10. However, they also stated that you need to complete somewhere between 10 and 20 projects to get sufficient return of investment. Since software factories are a major part of my job as a Microsoft consultant, I have developed a strong opinion on the approach that companies should take. Unfortunately, the ultimate answer is… "it depends".

Unfortunately, the term software factory is not well defined. I clearly remember a discussion that Don Smith (Patterns & Practices), Olaf Conijn and I had in Barcelona while preparing for our presentation at last year's TechED Europe. It appeared that when Microsoft uses this term, they usually refer to the wizards, project templates and DSLs that P&P ships as part of their Software Factory packages. On the other hand, we at Aviva Solutions usually include all the aspects of a typical software development lifecycle process. In other words, we include not only the tools, but also the process methodology, coaching & training, architecture and infrastructure.

I often run into customers that think that a software factory is something you deliver in a box. But unlike popular believe, introducing a software factory is really a project on its own. Because of its scope, it requires careful consideration of the culture, configuration, and experience of the team that intends to use it. Moreover, it's not a one-off investment. Typically, the request to introduce a software factory at a customer site usually co-exists with a pilot project that is used to prove the choices made. In order to gain maximum efficiency from it, you need to be prepared to make adjustments while executing the first few projects.

An essential decision in the process of introducing such a factory is the level of automation and/or customization you desire. It is tempting to build the perfect factory that automates every aspect of your software development lifecycle. But many architects forget that every customization may add a considerable amount of maintenance overhead. It may seem easy to automate yet another cumbersome manual task, but you'd be surprised how seldom you actually gain from that on the long run. As an experienced developer with a tendency towards a pure architecture, I know from first hand that the dark side of engineering lures around every corner. Nonetheless, if you really plan to execute between at least 10 to 20 projects with (more or less) the same factory, then investing in a decent factory can really boost your team's productivity. I don't believe in the huge factors mentioned in the opening article, but an increase of 30-50% should be feasible.

On the other hand, I've recently received signals from the .NET community that more and more customers get fed up with their highly customized factories . Every self-respecting IT service provider is offering one these days. But as soon as that architect has left the building, the customer is stuck with a factory that offers no upgrade path whatsoever. To solve that, some have considered offering a standard off-the-shelf software factory that allows no customization at all and offers supported upgrade paths to future releases. Though a welcome promise, up until now I have not experienced a customer whose software development lifecycle did not require extensive customization. In fact, thinking that you can compare one customer with another may be interpreted as an insult.

So what about Aviva Solutions? What do I do to overcome these dilemmas? Well, in fact, again the answer is 'it depends'. But I believe that using what's there and make sure you're being pragmatic is a good approach.

For instance, Microsoft Patterns & Practices offers a lot of free tools for architecting web and windows applications using a service oriented architecture. The Web Service Software Factory is one of those, and we have been working closely with the P&P team to include many of our best practices. Moreover, they provide lots of guidance on building properly secured and high performant systems. Since experience made me a bit conservative, if and in what way I do customize, depends entirely on the company culture, experience and involvement of the team executing the project.

I also restrain from forcing a particular process guidance, but instead, I gradually introduce elements of MSF, TDD and SCRUM that work for the team. On the other hand, I always suggest using Team Foundation Server to allow integrated support for work item tracking, project reporting and source control. And I'm really fond of using UML for describing functional requirements. I've seen many customers fail while trying to use tools like Word, and use cases and business class diagrams proved to be very understandable for all stakeholders.