April 10, 2005

...Learn TDD with Codemanship

Software Factories

I get asked every week about model-driven architecture, domain-specific languages and the whole notion of "software factories". There's a lot of buzz in the industry, a lot of hype, and a fair amount of confusion.

Some managers mistakenly believe that it means taking an assembly line approach to software development - where they employ small numbers of highly skilled, highly paid architects and analysts to create models and then use larger teams of less skilled, lower paid programmers to "assemble" the finished product - just like the way they make TVs.

This approach is fundamentally flawed - assembling a TV and building software are worlds apart in terms of the levels of knowledge and skill required. To assemble a TV, you pass it down a line of highly specialised low-skilled workers who only know enough to do their bit. Then they pass it on to the next person, who does their bit, and so on.

Software just isn't like that. When you write the code, you're not assembling software from a design. The code IS the design. When you write code, you are doing design! So you need to be skilled enough to make design decisions. In that sense, all programmers are software designers. You can't get around that fact.

But what if we could give programmers models of the design to work from? Ah, the promise of Model-driven Architecture. High-level, platform-independant models that contain all of the logic necessary to generate a working piece of software. Surely, with MDA we won't need programmers any more? Hurrah - the ultimate goal is achieved. A handful of highly paid people building models, and no need for lots of horrible, expensive, nerdy programmers.

At least, that's what some of the tool vendors would have their customers believe. There's just one snag: who's going to be building these executable models? Who has the skills needed to capture logic in a formal, executable language? Well, let's look at the candidates. Will it be the analysts? Sure, if they learn about logic and programming, then they can create executable models. But, hey, wouldn't that make the analysts PROGRAMMERS? Don't you need to think like a porgrammer to create executable models? Short answer - YES. Hoisted on their own petards... When MDA becomes a reality - and I'm sure one day it will in some form or other - it's the analysts who'll find themselves on the scrapheap as the programmers move yet another step closer to the business. You may need slightly less programmers if you're working at a higher level abstraction, but there's not much evidence for that. Did the advent of 3GLs lead to companies employing less programmers? No. The systems will just increase in number and complexity as they get easier to build. I predict even more people writing software as a result of MDA, and they'll cost more, too - because the closer you get to the core business, the more reliant they will become on you.

I think MDA will have the reverse effect that some are intending, but hey, that's just my opinion.

Anyway, back to software factories. According to Microsoft's web site, they view software factories as being very programmer-oriented (and team-oriented).

http://msdn.microsoft.com/architecture/overview/softwarefactories/

This seems a much more sensible message to be putting out. rather than selling the idea that model-driven development (which, in their case doesn't necessarily involve UML) will reduce reiance on programmers, they're pushing the idea of using MDA tools to make programmers - people who write the code - more productive by automating as much of the boring, repetitive stuff as possible.

I like the Microsoft line. They paint a future where programmers get more done. I don't like the MDA line. One, because I think they've got their thinking wrong about who will be doing the modeling, and two, because it feeds the very damaging myth that building software is like assembling TVs, and further reduces programmers to the rank of mere functionaries who only need to know about their little bit and pass the code down the line to the next micro-specialist. This is very bad for business. More and more I consult on projects where the perception is that analysts and architects rule, and programmers are just "painting by numbers". It's no wonder the people at the front of the development process are so keen to build on that myth - but they're mistaken if they think that in 10 years time it'll be they who are indespensable.
Posted 15 years, 10 months ago on April 10, 2005