What criteria have you used to determine whether or not to implement a Software Factory?

Question

I was discussing with a co-worker the other day the similarities of implementing a Software Factory for your development organization vs. using more of a scaffolding solution like active record. We both thought that implementing a Software factory may be considered by some to be a good idea when you have a larger group of developers and you want to maintain a certain level of consistency and convention within your code base.

Thinking about it a little more, I realized that I really like the idea of Software Factories for personal use, because they make it easier for me to code up the projects that I work on for fun as they save me a lot of headache in writing "boilerplate" code. That being said, I would bet that enforcing the use of a Software Factory in larger organizations might cause some strife within the team because some developers may think that it would be an infringement on their ability to be creative?

So what I'm wondering (from those of you who have been part of an organization that has implemented factories) is what criteria would it take to dictate the use of a factory within an organization, when the risk may be a bunch of unhappy developers?

Answer 1

In the spirit of SO, IMHO there is no organisation large or small that would get more out of a Software Factory compared to a good framework (Spring, Windsor, Active Record).

Software factories are only fun for those who build the factory, the factory analogy is very apt. Within an SF environment coding can become repetitive and boring, you're essentially telling your team, BTW you're actually too stupid to figure this out so we're going to make sure you can't make any mistakes. I know that sounds harsh, but that's how it pans out (and yes I was on the fun side of the equation when we tried it). Consistency and convention can be encoraged (I hate enforced) by all kinds of means, code review is best, but hard to do, code analysis (FxCop et al) are the worst but they do cover the basics.

Another problem with the SF approach is when the factory doesn't meet a particular need, then the coders are lost, they've been insulated from the underlying tech to such an extent that they have no conceptual model of what's going on. It's like asking a production line drone to build an engine, they don't know where to start. On the other hand a decent mechanic will know what to do (or where to go). You should be empowering your team with great tools, not restricting them with an unnecessary factory approach.

Answer 2

I suggest that it depends on what your factory is producing. There are certainly many examples of "cliche" code whose production can be automated, allowing the development teams to focus their creativity on the parts of the code that really take human intelligence.

It is also important (and entirely possible!) to organize the constructed artifacts with call-backs or other extension points; again the key is to make sure that the developers are able to see that your work is supporting them, rather than displacing them.

The above mean that you (and your teams) will be forced to do more up-front planning to achieve the coordination with a minimum of friction and "oh-we-forgot-that-we-also-need..." events. That will likely produce a bit of grumbling. However, if you do it right, you'll get to step up at some point and handle some external demand by tweaking the factory, with no interruption to their own work. At that point, more of them should begin to see you as an ally.