In this post I’ll try to clarify one of the reasons why we (and the IT industry in general) need software factories. I’ll illustrate this by looking at the ongoing evolution of Microsoft .NET.
The first .NET wave
During the first years of .NET (2002-2004), it was new for every developer so we all started at the same level and had to learn the same concepts to get started. We all used the basic .NET features and the Visual Studio IDE. There wasn’t much guidance available at that time, let alone best practices and frameworks. We were just glad that we could deliver working software with this new technologie on time.
Present situation
Since the arrival of .NET 2.0 in 2005, new tools and frameworks began popping up rapidly. And now, it has become an avalanche with new stuff being released on a daily basis. It has become nearly impossible to track everything that’s going on in the .NET community. Only a limited group of ‘extreme’ developers are willing to sacrifice extra time to keep up with this. The gap between ‘regular’ developers and ‘extreme’ developers is widening very fast. Since technology doesn’t stop evolving we need to find ways to increase the productivity of ‘regular’ developers to cope with more complex software requirements. Coding horror has a fun article (and a follow-up which is even funnier 
) on the different types of developers.
Automate best practices
From here on, I’ll use our Domain Driven Design factory idea to illustrate the problem.
DDD concepts aren’t known by many developers and the learning curve is pretty steap. So how can we make it easier for developers to start building DDD applications? By automating best practices and providing guidance in context. Imagine starting a new DDD project in Visual Studio and the solution structure is rolled out for you with every reference in place. Imagine a context-bound help window guiding you through each step. Imagine a Visual Studio environment that doesn’t only give you compilation errors and warnings, but also warnings on a higher level (ex architecture-wise). And best of all, you can choose to just use the factory without knowing into detail which technologies and patterns lie underneath.
I’ve included a screenshot of the EFx factory (from Jezz Santos) to show how far you can go in customizing Visual Studio.
How to bridge the gap
You don’t need a full-blown software factory to start bridging the gap. Just start gathering all internal best practices in your company and bundle them in a document, write code snippets, save project templates, write fxcop rules (link to Dutch article), … These are all already small but rewarding steps that’ll bring you closer to working as a factory.
Greetz,
Bart
On Software Factories
Hello,
I fully argee that you should harvest best practices. And if you can translate them into “automate-able” things in your IDE…by all means. Like you said : the pace of technology advancement and the time you need to invest to keep up with things is not eveyone’s cup of tea. So it is good to “break” the dependence of code heroes a little bit … but let him or her look over your shoulder (as a figure of speak).
But technology (and I mean it in broadest sense of the word) can take you only that far. There are also the “Process” and “People” pillars that need equal attention. Don’t forget to close the “gap” there also: software methodology (light or formal) , training developers, quality assurance , Testing, configuration management, release management , etc.
Also Software development is only one part in the lifecycle of an application; don’t forget operations , the maintenance of applications and most important the business case of the application. The “Business” doesn’t care which which design pattern you used as long as they can do their job with the application you’ve build (and earn money for the company).
You see , there are many “gaps” to close. Microsoft Software factories (guidance, abstraction,code generation) are only one facet that can help us delivering applications to the business that are cost-efficient, reliable and effective.
Best regards,
Alexander
[...] a few actually master most of the available technologies or as Bart calls them in his article ‘The developer gap’, expert and regular [...]