Software Factories Skepticism
I'm no expert on Software Factories but frankly I am a skeptic. I have spent a day or so reading about them on the InterWeb at the behest of one of my colleagues. There are several very well written articles on Software Factories out there. I particularly like the Jack Greenfield articles on the Microsoft site (Parts 1, 2 , 3 (where's 4 BTW?)). There's no doubt the Software Factory proponents are very articulate and maybe that's one of the things that makes me skeptical?
There is no conflict between Software Factories as a basic idea and Agile. Indeed Jack Greenfield acknowledges, "modest gains in productivity have been made over the last decade, the most important perhaps being byte-coded languages, patterns, and agile methods". I'm not sure about the first two, but I'd agree with the 3rd.
Where my skepticism starts building is around the following points:
- The Software Factory arguments sound a lot like the old Object Oriented/Reuse Library ideas. I used to be part of the Reuse Library effort at Morgan Stanley in the "early days" of adoption of objects in finance, so I am am familiar with the pitch. The issue which arose was that as much as you ended up with tools, frameworks and configurable components the productivity only came in when the users of the libraries and tools really understood the whole kit and could apply them. This required a lot of learning, which meant a lot of time before becoming productive. Forget "big design up front", this is "big learn up front". Clearly this can be solved by having "domain" experts learning on somebody else's penny before having to pay for them to build your system. But isn't this just reducing the accounting cost of a single project by ignoring the cost of the learning hump?
- On a similar vein, I find it curious that a lot of the people from the early days of Objects and Reuse Libraries are the same people involved in DSLs and Software Factories (e.g. Steve Cook, Alan Cameron-Wills, etc). Same arguments and ideas, different century? Are better tools and larger distribution the answer? Maybe there is a flaw in the model that made it not live up to its promise the first time around?
- Part of the argument for Software Factories is "the progress of the level of abstraction" that developers use to create systems. In my experience increasing abstraction often leads to reduction in productivity. The quote Jack Greenfield uses is from Smith and Stott's OOPSLA paper: "The history of programming is an exercise in hierarchical abstraction. In each generation, language designers produce constructs for lessons learned in the previous generation, and then architects use them to build more complex and powerful abstractions.". My problem is that the more abstract you become the more strongly defined (and smaller) your context must become in order to maintain a productive level of relevance. Without narrowing the context, the more abstract you become the more meaningless the artefacts become. My experiences with abstract frameworks and developers trying to use them led me to question abstraction. The XP approach of "create the value then refactor" was a better approach IMHO which still recognised the value of abstraction but maintained a practical grip on the scale of the context. I was also influenced by a quote from Joseph Joubert:
"How many people make themselves abstract to appear profound. The most useful part of abstract terms are the shadows they create to hide a vacuum."
- The value in Industrialization in manufacturing came mainly from the change in the practices associated with creating goods. New tools were created to match the new practices and definitely increased the productivity too, but ask the question in reverse. If the specialized machinery for creating components had been created and applied with a craftsman process, would the productivity have increased as much as happened through purely changing the practices to production-line?
- I believe these tools are emerging from the Agile community at the correct level of abstraction required for necessary productivity. IDEs with refactoring tools, Open Source frameworks for persistence, messaging, etc. Are these not the same elements of a Software Factory? There is a way of looking at APIs and scripting as DSLs.
- An Agile team I believe they create their own Software Factory for there own domain through disciplined practice. This may appear to support the Software Factory argument, but there's a big difference: the people. Tools and documentation by themselves are not sufficient without the people who share and build the context the abstractions exist within. I would suggest that a manufacturing factory without people is pretty useless - indeed a manufacturing plant without people who have some idea how to use the tools is not much better. Possibly the term 'software factory' would be more appropriate for refering to a team of people who can produce systems using tools?
- Where is the demonstration of Software Factories improving productivity? I am struggling to find evidence. If someone has good data please show me! I find plenty of opinion. I find plenty of confidence. But I find no evidence?
I have no doubt if they achieve the essence of Software Factories in a coherent, understandable way then combining Agile Development with Software Factories will produce productive software delivery. But I currently believe its the Agile rather than the Factory that is the productivity boost.
I recognise my own skepticism is not necessarily useful. I am reminded of George Bernard Shaw:
"Every person who has mastered a profession is a skeptic concerning it. "
There is a strong possibility that Software Factories may be a better way of looking at IDEs, APIs and Frameworks. And maybe I'm the wrong person to measure the effort having been in software so long - but I don't see the evidence that this will help software development productivity or quality.