Software Factories - doesn't anyone besides me think this is crazy??

The boys at Microsoft are at it again. The architects of Visual Studio Enterprise tools, Jack Greenfield and Kieth Short, are talking about Software Factories.

The concept behind software factories is full of the hypnotic song of the Sirens. We IT geeks automate everyone else's processes... why shouldn't we automate our own? Yes, that's right! We can reduce software production to recognizing patterns of requirements and then write factories that generate code to satisfy the requirements pattern. Simple. Heck, even a monkey could do that. Why hire IT professionals when you can get a high school student who will work cheap!!!! Watch your IT costs spiral down, cuz high school students will work for beer money.

We Have Seen This Wreck Before

Wake up Dorothy. This ain't Kansas! And all you mythology buffs will recall what actually happens to sailors who were seduced by the Sirens' song (with respect to Odysseus, the only recorded survivor). The whole concept behind software factories is misguided, and a yet another example of how a good idea (patterns) taken to an extreme can be extremely non sequitur.

Those of us old enough to recall programming in the early to mid 90's recall well the last time Microsoft tried to 'dumb down' programming. In the heady early days of Visual Basic programming managers rushed to apply the simple form application building framework to every application from garage based mail order systems to multi-national corporation asset management megasystems. Tech schools filled to the bursting with kids getting a 4 month diploma on how to program in VB, and CEOs smiled looking at whole office floors full of eager kids, all working for 25 bucks an hour, no benefits.

And at first the screens rolled off the factory floors with smooth regularity. I recall one MS pundit proudly showing me how he could create an application and deploy it in 12 mouse clicks. But the bloom fell off the lily around the same time the second round of requirements rolled in. The simple bump-n-squirt applications that read from one or two tables and threw them up on a form were done, and now the wild eyed guys from accounting were asking for things like reconciliations from accounting tables... yes all 586 of them - including the daily transaction log, complete with its 1 million row (per day) detail records.

It was a great time to be a consultant. I spent about 3 good years moving through failed VB project after failed VB project, replacing cookie cutter VB forms having miles of domain logic embedded in button click handlers with conventional C++ (and eventually Java) programs. Yes they were more work to do. But they WORKED.

The Seven Percent Solution?

The funny thing about all this isn't that MS is going to try this again, 10 years later. Its more that people still fall for the Sirens' song. Software Engineering Process Techology estimates that roughly 25% of the cost of software across its lifecyle is spent in development activities, and only 7% in actual coding and unit testing.

What does that mean? It means that you discard your qualified IT staff for cheap and poorly trained replacements, you lose your ability to write mission critical software that is 'outside the box', you generate reams of hard to maintain code that cannot easily be changed, and you bind yourself irrevocably to MS products (since you no longer have the expertise to change to anything else).

All this to save up to 50% on your development costs. Sounds good eh? Worth it, right? Only till you find out that you reduced the total cost of your software by a whopping 3.5%.

Crazy.