Tuesday, April 01, 2008

Software Factories and Battery Programmers

batteryHen

A while back I had a client who was moving to a Web Service based ESB architecture. They had a number of Visual Basic 6 developers that they wanted to bring up to speed developing .NET web services and at the time I was getting interested in software factories, especially the P&P group's GAT. Their lead architect suggested that I write a software factory based on a standard web service architecture. Her intention was that she could get her VB devs to build web services without having to have a deep level of understanding about how they work. I had a great deal of fun building it, even though it was very early days for the GAT, and I learnt a lot about component based development by reading the P&P code. These days I look back on that job as one of my most enjoyable.

But how would I feel if I was one of those devs asked to use my GAT product? I'd hate it. Where's my joy? Everything I love about programming would have already been done by someone else. Not only that but I couldn't learn any lessons or move the architecture forward because it's all been locked down.

Every time I start a new project I tend to architect it in a different way. I learn new stuff all the time, recently it's been IoC containers, MVC frameworks and LINQ. If I was somehow constrained to do things the same way I would be far less productive and happy than I am (and I'm not that productive and happy in any case :P). The industry is too young, too fluid and too diverse to allow you to lock up your architecture without paying an awful price in lost opportunities.

I don't want to go into it now, but I don't like the architectural patterns imposed by a lot of the publicly released software factories from the P&P group. I think data transfer objects are a total waste of time in 90% of applications for a start. I would be mightily depressed if I had to work in a shop that had adopted them... oops, I did go into it...

And what about those legacy skilled VB developers. Well, you can guess... the software factory didn't allow them to quickly build web services without understanding the basics about .NET, XML and SOAP. They needed extensive training and hand holding. There's no replacement for skilled developers no matter what the tool venders tell you.

So Software Factories will go the same way as CASE tools, visual tools and code generators. After wasting lots of people's time and money they'll be cast into the void of software evolutionary dead ends.

2 comments:

Anonymous said...

I just read your article and happen not to agree.

I think a common mistake when talking about software factories is that they will enable the use of technology without any knowledge of that technology.

The way I view them is as a means to capture knowledge and experience and make them available to others. It's a bit like the industrial revolution: people, craftsmen, got replaced by machines.

Does this mean that the person who is handling the machine doesn't have to know the basics of what the machine is doing? I don't think so. It does mean that the machine enables him to do things faster and easier. It also means that the machine is able to produce the majority of required products it is supposed to produce in a fashion that is generaly accepted is "being ok for us".

Does it mean that you don't need craftsmen anymore? No, because some stuff can not be produced by machines. Likewise, it does not mean that if you want to produce some product you can always do it using that machine.

So I think your customer got the wrong expectations of the software factory.

I happened to write a bog entry about it on my blog.

Maybe Microsoft should stop using the words "Software Factory" and should use "Software Machines" instead. That way it would be more clear the programmer is an operator of it, and not a part of it.

Anyway, it must have been a great experience programming it.

Mike Hadlow said...

@sdesmedt Great comment.

I still maintain that the main problem with software factories is that they set a particular architecture in stone. Each time I start a new application I do it in a slightly different way. That's not just because I'm fickle, but because in the months since I started the last one my views on good design have evolved.

Frameworks and components are a far better way of reusing software than software factories IMHO.