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 :)

Today, the "breakout" sessions begun. In other words, we started drilling down with the product

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...<a href="http://keenzo.com/showgroup.asp?ID=102">software</a>

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).

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.

Guidance?

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...