Software Factory du jour

Beat is one of the more enthusiastic Microsoft evangelists I have met. When I met him in Lillehammer in 2005, he was beating the SOA drum. Now he is beating the Software Factory drum. I think he really believes in what he is doing.

I was pretty much ignorant about Software Factories until I sat through an Open Space session on the topic in Cortina with some other enthusiasts and I really learned a lot. The idea seems to make a lot of sense for people who routinely build similar but somewhat unique applications. It seemed to me it would appeal to the Cap Gemini's, WIPro or IDS' of the world who (I am guessing I admit) tend to service vertical markets and see themselves endlessly cranking out code that looks an awful lot alike for client after client. The building trades figured this out long ago. The industry is divided between niches for the most part: residential, small commercial, industrial and large commercial buildings are all built by different kinds of companies. Materials are fairly standardized. Assembly of the materials is fairly standardized. Skills are fairly standardized.  Whole neighborhoods are fairly standardized, at least those built in the last 50 years.  Crank 'em out, like a factory.

In this comparison to a restaurant, Beat compares writing software to food orders. It's very well written and I would encourage you to read it. The idea is that you determine the products that make up your menu, and then only offer certain kinds of variations to the customer. The old Saturday Night Live skit "cheeseburger, cheeseburger, cheeseburger, coke" comes to mind but I see where he is going. I'll bet there are lots of situations where the idea makes sense. Once a certain domain has reached the level where it can turned into predictable parts like that, has it really reached the commodity stage? Do I want to be in a commodity business? Probably not. The analogy of a factory itself troubles me. You build a factory to crank out the same things over and over again. You want a factory to last a long time to offset the relatively large cost of building it in the first place. You want to preserve the market as is for the factory's products so you don' t have to retool. All this seems dubious as an analogy for an industry that is so young and changes as fast as software development does or as business itself does these days.

Domain Driven Design is about expressing the very detailed nuances of a business in verbally expressive code. It seems to me it is the antithesis of Software Factories. Sure, I can imagine factories building some components of a domain model. The bigger that toolbox is though, and the more code it cranks out, the more you may be inclined to become MacDonald's instead of a 5 star joint. Or perhaps you become just like your competition. Frameworks, and I will admit I am as guilty of building frameworks as anybody else, have the same flaw unless they are evolved out of careful refactoring over a long period of time.

I had the pleasure hanging out with Lyle Mays one weekend some years back with a mutual friend. I asked him about how he uses electronics and computers to help him compose, a reasonable question to someone who has made a career with electronic music in the Pat Metheny Group. At the time his response surprised me, though now it makes perfect sense. He said he usually worked with pencil and paper at the piano because all the tools nudged him toward writing things that were easy to write with the tools. Instead, working with piano, pencil and paper, the composition could emerge as he heard it in his head.

There seems to be a lesson in there for us developers. Now if we could only reconcile that with the effort of handwriting hundreds of thousands of lines of code! I think that the lesson is that we need tools that work for us, not visa versa.