4 Comments Downsides to software factories - 01/7/09
A while ago, I was quite excited about software factories. I had even joined a small group and we were going to explore GAT, DSL, and in general: software factories.
When do you need a software factory?
When you’re making the same solution structures over and over again, when you’re copying those nice and helpfull classes from the previous project, when you feel the problem your software is solving, is always generally the same… That’s when it’s time to consider building a software factory that easens the repetitive tasks in the development lifecycle.
A few definitions
The Guidance Automation Toolkit and the Guidance Automation Extensions are tools that help you to create optimized Visual Studio templates, alter the behavior of Visual Studio on specified project types, generating a solution structure containing several projects that again contain references, folder structures, and even code.
Wikipedia defines DSL or Domain Specific Language as follows:
The term domain-specific language (DSL) has become popular in recent years in software development to indicate a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique. The concept isn’t new—special-purpose programming languages and all kinds of modeling/specification languages have always existed, but the term has become more popular due to the rise of domain-specific modeling. Domain-specific languages are Fourth-generation programming languages (4GL).
You can create DSL’s to solve a common problem. Imagine a DSL that enables you to generate the needed configuration for your fav-ou-rite IoC within Visual Studio in a few clicks?
A nice software factory
Recently, I ran into a very nice software factory. It solves different problems:
- - Create a solution structure, with a layered architecture
- - Create testing projects for every project
- - Generate stored procedures for CRUD-operations
- - Generate the needed methods to call these procedures in the needed layers
- - Generate tests that test the whole structure the factory generated
- - Implements logging, tracing, transactions, … in the code
After all this, you can manually add stored procedures, run the DSL’s again, and that way update your code. The code that was generated, is placed in partial classes, so you can extend them. If you have to regenerate the code, your custom code is not affected.
The code is well structured, documented, and easy to read. But the design of the generated package, is completely data-driven. I’m not a fan of the data-driven approach, still, I know, in some cases, it can be the way to go. But I am conviced that in many cases, you can solve your problem the OO-way and you’d be better off!
Consequences…
The developers using this software factory, are capable developers. They know the whole structure of the solution, and do know what each layer’s responsibility is. They understand and master every piece of code this software factory produces, and that’s a very very very good thing 
.
However, in my opinion, the existance of this software factory, gradually can take away the open-minded behavior of a developer. I mean, that, when starting a new project, the first thing that comes into the mind of the developer, is using the SF, and that’s where you lost me. I know… the only reason you would invest in building a SF, is if you’re going to use it in several cases,… D’oh! But it shouldn’t be taken as a general rule for all projects. An SF that solves each and every problem domain does NOT exist and can’t be built either!
I agree that the software factory created a starting point for several successfull projects. I’m not saying it can’t make further projects succeed also… I’m only saying, that each and every project is different. What if it would be more convenient to build some new project using the OO or DDD-approach? That would mean more work. Yes, It would! So what? Is that a reason to fall back to the SF (and just choose the easy way)? No!
The usage of a SF should be considered for each and every project. There are some projects where the SF will offer you what you need to make it a successfull project. But don’t think the SF will make -any- project succeed.
Conclusion
I think it would be very interesting to build a software factory (it’s interesting looking at how it’s build, so don’t even get me starting about building one 
). A software factory should solve a common problem. I’ve actually always believed in them, but I never thought of the consequences in the mind of developers. I’m not saying every developer reacts like this (if it were so, I wouldn’t be writing this post in the first place…). Let’s state I’ve seen symptoms of what I’m describing here, and it’s unnecessary to state how wrong that is…
For the last time: Every project is different, some general concepts may repeat themselves, but still, the usage of a factory should be considered case-by-case.
[...] more to say about YAGNI in combination with software factories. Not very long ago, I talked about a software factory I layed my hands on.Now, I’ve had the chance to mess around with it a little [...]
I think you’re missing a key point in software factories (and Software Product Lines in general).
As you note, the organisation should develop the factory in the context of a specific scope – to address particular types of problems.
But, the way you describe new projects arising is that they somehow just pop up and the developers have to decide whether or not to use the factory for the new project. But the reality in a factory-oriented organisation is that the business actively seeks to build products that can easily be built using the factory (and so can reuse the factory assets). If a product can’t be built with the factory then they may choose not to build it or to build it at a higher price without using the factory.
Basically, unless there’s significant commonality between the different things the organisation is building there’s no sense in investing in developing a factory. But the organisation can help ensure such commonality exists by carefully deciding what it will and what it won’t build. If you’re the type of organisation that takes on any work then a factory approach isn’t suitable for you.
@Mark: The factory was indeed created to ease the development of several planned applications. They looked at what was common, and built the SF according to that. All those apps have been developed by now, and are successfully up and running. A new project (which we have to do) came along, and using the SF looks like the obvious thing to do for the developers that have been using it for years now. And when I quote what you say, we’re thinking the same thing: “If a product can’t be built with the factory then they may choose not to build it or to build it at a higher price without using the factory.” The only difference, is that you assumed the developers would make the healthy decision of not making it or build it from scratch for a higher price. And that’s exactly what I’m missing: developers that can still think outside of the box after having used the SF widely.
A lot of the Software Product Line literature assumes you don’t have to do projects if they don’t fit the PL – you seem to be in a different situation.
We encourage [1] people to build feature models of their Product Line to see exactly what commonalities and variabilities it can support. If you had these in place it would be a lot clearer that the SF wasn’t currently capable of supporting your new project.
[1] We sell the pure::variants tool to help them do this so perhaps it’s not surprising we encourage them to do this but the point is valid in any case.