An overview of what my group in MS does: http://msdn.microsoft.com/library/en-us/dnvs05/html/vstsmodel.asp

Unusually for MS, “software factories” is partly methodology, as well as a strategy for developing tools around Visual Studio.

A Software Factory is an IDE that supports particular architectures. It’s tuned for work within a specific area – so that instead of writing all the code and making all the design decisions from scratch, you get a lot of code and help and refactorings and patterns and little languages and style checks all built into the IDE. All that stuff is different depending on what you’re working on – process control or a phone switch or wordprocessor, or the DB or the GUI, or whatever – so you can set it up to work differently for different domains.  Or if you’re a junior developer, maybe your lead architect team have set it up for you. So all the cross-cutting decisions that should work in common between a team of developers are embodied in the way the IDE supports their work.

“Software Factories” as a method is about evolving during a project a schema of what architectural guidance or support is required for developers in the different domains. You can do it on paper even if you don’t have tools that will support all the bits. It’s very useful on big projects, and particularly so on product line developments – where you want to pare down to the minimum, the work the developers have to do anew in each instantiation.

IDEs have changed a lot since you just had emacs and the compiler.