So while I was on vacation, my trusty teammates plus our cohorts @ MSDN published JOURNAL 3 on Architecture Center. The first article from JOURNAL 3 is called The Case for Software Factories by Jack Greenfield, co-author of the Software Factories book. Jack noticed that the article, an introduction to the concept of Software Factories, was being rated inordinately low. Currently, it’s been rated 4 out of 9. To compare, Pat’s introduction to the concept of Metropolis from JOURNAL 2 rated a 7 out of 9. So a 4 is a pretty low score. Granted, I’m not going to lose any sleep over it, but it was curious. Then Jack discovered this thread on Slashdot, where most of the posts were from people who don’t appear to have read the article at all. Here’s an example comment:

The “software factory” analogy has been around before. It’s nonsense, of course. The software analogy of a “factory” is the plant that presses CD-ROMs. Pressing the 10,000th CD-ROM of a software product is the software equivalent of building the 10,000th Nissan Maxima on a production line. But writing the software which will go on that CD-ROM is the software analogy of designing the 2005 model of the Nissan Maxima. Now, some software development is not very creative. Just as tweaking the design of a car model that’s been around for 10 years, to get something a little bit new for a new model year, is not very creative mech engineering. But it’s still design, not assembly-line production. A competent software engineer will be able to do it better and faster than a bad one. And a factory worker will not be able to do it at all.
[Comment by njdj from Slashdot thread Hackers As Factory Workers?]

What’s hilarious about this post is that point of the article is that the software industrialization will not look like a factory stamping out of exact duplicates that njdj describes! The key to understanding software industrialization is understanding the difference between economies of scale and economies of scope. What njdj describes is economies of scale – where you stamp out a boatload of multiple identical instances. Economies of scope is when you create similar, yet distinct, instances. For example, in my housing development, the houses are all similar, but not exactly the same. There are three or four basic designs used for around a hundred different houses, but the different instances of each design vary slightly. Since you can’t stamp out identical copies of the house, economy of scale doesn’t apply. However, economy of scope does apply – these houses use the same basic building materials, similar patterns of construction, the windows and doors are the same size, the plumbing and electrical wiring are the same, etc. Even though the houses aren’t identical, the construction company can build a bunch of similar, yet distinct, houses much cheaper than if they built each one “from scratch”.

I know njdj (and most of the other posters on the Slashdot thread) didn’t read the article, because the article comes right out and states:

We can now see where apples have been compared with oranges. Production in physical industries has been naively compared with development in software. It makes no sense to look for economies of scale in development of any kind, whether of software or of physical goods. We can, however, expect the industrialization of software development to exploit economies of scope.
[The Case for Software Factories by Jack Greenfield from JOURNAL 3]

I don’t know how much clearer Jack could have made his point, so I’m surprised that so many people missed it (or bothered to post their opinions of an article they clearly didn’t read). However, I’m not going to lose any sleep over it. I blogged a while ago about the the Oakland A’s exploiting the inefficiencies of baseball. Jack’s talking about exploiting the inefficiencies of software development. At some point, someone will be successful adopting a factory approach and everyone else will have to adapt. Software development has to change – you can’t expect to stay in the major leagues with a .160 batting average.

Is it obvious that I’ve been rounding up bloggers on my extended team of architects and architect evangelists? Here’s another: Raj Wall blogged the first of what appears to be several posts about Patterns of Successful Software Projects. I like this as it really starts to expand the idea of what is a pattern. If you look at EASOT, you’ll notice a “Development Architecture Viewpoint” that has the following description:

The development architecture viewpoint is concerned with implementing the other architectures. Applications must be built and maintained in a systematic, efficient manner. The development architecture is composed of elements related to this effort, such as design and development tools, repositories, build master utilities, test suites, tracking tools, and other tools.

In my TheServerSide.net Tech Talk, I pointed out that Test Driven Development is a pattern. I know there are a lot more development architecture patterns. Raj’s post starts to define the terms in this area of the pattern space. Can’t wait to see what Raj has to say about project context – the more I work with patterns, the more important I realize context is.

Sure has been quiet around here. Standard end of the fiscal year craziness. Plus, I had some dogfood issue w/ XP SP2 RC1, Office 2003 SP1 beta and NewsGator. Upgrading to XP SP2 RC2 seems to have solved the problem. Regardless of the cause, I’m way behind reading which in turn leaves me way behind writing.

I’ve blogged about Software Factories before, but from under the mountain of unread blogs I see Keith blogged about how VSTS will support software factories. He posted an excerpt from an article he’s working on.

A software factory is a product line that configures extensible development tools like Visual Studio Team System (VSTS) with packaged content and guidance, carefully designed for building specific kinds of applications. A software factory contains three key ideas: a software factory schema, a software factory template and an extensible development environment.

It’s been around a while, but I only just noticed the Microsoft Solutions Framework website because they just published their whitepapers on the Download Center (RSS feed for Download Center provided by ThunderMain – thanks guys!)

From the overview, MSF is:

Microsoft Solutions Framework (MSF) is a deliberate and disciplined approach to technology projects based on a defined set of principles, models, disciplines, concepts, guidelines, and proven practices from Microsoft. This white paper introduces MSF and provides an overview of its foundational principles, core models, and essential disciplines, focusing on how their application contributes to the success of technology projects. Finally, the paper provides references for further information about MSF and references for guidance in implementing MSF within an organization. In an appendix, the paper briefly compares and contrasts MSF to other industry methodologies and standards and describes how MSF can be used in combination with them.

MSF includes two models – team and process – as well as three management disciplines – project, risk and readiness. They also have a bunch of MSF templates you can use in your own projects.

One of the nice things about MSF is that it works with other methodologies. I.e. you don’t have to give up RUP/XP/TDD/<insert your favorite methodology here> in order to use MSF.

Update: Lorenzo has compiled a list of MSF links you can check out.