Software Factories at the MVP Summit

I’ve been dubious about software factories for a long time, but I’m coming around a little bit.  I see factories mostly being useful as just a bit more than what people already do today with things like CodeRush.  I think it would be a helpful mechanism for small scale skeletal code generation for things like Model View Controller generation and automatically creating a test class to match any new concrete class (basically, Scaffolding in Ruby on Rails).  The big hangup that I have with software factories is that I think some atrociously bad systems are going to be created by blindly following the “guidance” from the software factory.  Also, *who* is building the guidance in these software factory thingies?  Are they really good enough to do that?  Is my system really suitable for a generic set of patterns? 

Many of the worst blunders that I’ve seen have been a result of choosing a complex pattern too early on and motoring ahead without reflection.  Software factories is going to promote this behavior.  I think the inevitable Achilles heel of software factories, and planning for reuse upfront in any sense, is what happens when you get a case that doesn’t fit the previous pattern?  In that case following the model leads to bad code.  Plus that little “the model needs to change” thing that happens from feedback and learning.  There are always edge cases that will break the model.  You cannot ever stop thinking, dammit!

  • In so many words, somebody in the Software Factories talk brought up Case Tools.  Jack Greenfield handled it fairly gracefully, but still…
  • Jack Greenfield is really smart and well spoken.  I’m still iffy on factories though.

Jeremy’s prognosis:  The useful parts could probably be done with CodeRush.  Everything else, we’ll see.  I’m not jumping up and down in excitement.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Dida

    Software Factories is an emerging discipline and to just answer a few questions that you have posed…

    *who* is building the guidance in these software factory thingies?

    Guidance is built but by experienced people who have domain and solution expertise and not by everybody. If you consider in normal development guidance is given by architect and in SF case its not just one architect but experienced SF Team.

    If the guidance is built by the above people it should be better than the knowledge of normal developer.

    And regarding the code generator tools…

    Sf consists of code generation but not general code generation. Meta data is captured in various models and code is generated specific to that domain (this is like you use IDE’s for visual controls…)

    Any ? regarding SF you can mail me…

  • labu

    It would be nice to see below every doc which comes out of P & P MS

    Author: Name
    Last Production Software Date:
    Unit tests written to cover :
    Highest CC score :
    Lines of Code:
    Last Public Software Written Date:

    Same for testers (Clickers are not counted as testers)

    Out of every product which comes

    Used by Company:
    In Project :
    Software in use since:
    Microsoft software which uses the product (other than demo, please):
    Reusability Statistics:

    Sometimes, I think P & P just there and write stuff in isolation.

    (The above is just my personal opinion which has been more erroneous than correct in the past).

  • gene

    hey,this is nice to read article which is related to software .really i agree that software problem should be detected in a good manner.similar…software

  • dhayden

    I think we need to see the Software Factory as another tool in your toolbox that you can apply to a problem when it makes sense. The Software Factories put out by patterns and practices list key scenarios when you might want to use the factory and when you would not want to use them. Even patterns and practices don’t think of them as a silver bullet and as a solution to all applications.

    We also have to be careful of disregarding a tool because it could be used incorrectly. A hammer is a useful tool even though in the wrong hands it could be used to kill someone. Just because some developers may blindly think of the tool as a solution to every problem doesn’t mean the tool is bad.

    Although not perfect, I think the software factories are a step in the right direction – a combination of developer productivity and proven practices. The factory may not be the best solution for a given problem, but a lot of the concepts and proven practices that the factory promotes will help developers think about how to properly use those ideas using other solutions, etc.

    Sounds like you guys are having a blast :)