The Software Factory

The Homework Machine - A Poem by Shel Silverstien

The Homework Machine , oh the Homework Machine,
Most perfect contraption that’s ever been seen.
Just put in your homework, then drop in a dime,
Snap on the switch, and in ten seconds time,
You homework comes out, quick and clean as can be.
Here is is – “nine plus four?” and the answer is “three”.
Three?
Oh me…
I guess it’s not as perfect
As I thought it would be.

It is an old concept, but has really garnered a lot more mindshare with the nationwide financial crisis. The Software Factory. I'm not talking about the Factory design pattern, but the concept that you can have a rigid set of process, guidelines and governance such that you can feed work to the factory and get results which are repeatable and predictable.

Anyone who has been accountable for delivering business value understands the boon predictability brings to software development. Understanding exactly how long, and exactly how much a software effort will cost would mean the business could make better decisions and make promises to clients and customers which can be honored.

Developers have pushed back strongly with the mantra that software development is an art, not a science. After all, effective engineers and architects require a certain amount of creativity in order to get through roadblocks, or perform the necessary steps to troubleshoot a problem. Consistency does not come naturally within the realm of software development. Giving the same problem to multiple teams will deliver multiple solutions.

Thinking of engineers and architects as cogs in a complex factory machine is problematic. First, those with experience with the software development lifecycle understand that developers aren't universally replaceable. Seriously, Fred Brooks even spoke about this back in 1975 in his infamous book 'The Mythical Man Month', where it is mentioned that research proved experienced developers saw a dramatic increase in effectiveness over unseasoned peers.

So if the conventional model of software factories (with the analogy as developers workers on an assembly line) is flawed, is there a model which might work? Perhaps.

Some folks in my company have been speaking for a few years about a slight twist on the factory model which might have some legs to stand on. The difference is first it all starts with a highly effective team. Erase from your mind the dingy gray coveralls of a faceless interchangeable factory worker. Now picture..... the A-team. A highly effective experienced unit capable of putting their unique blend of talents to work against unexpected challenges.

I love using the A-team as an analogy of a high performing team. When some folks mention high performing teams, they think of a team in which everyone is highly skilled at everything. But I think the A-team is closer to reality. While the A-team was a high performing TEAM, the individuals all had glaring weaknesses. Individuals on a high performing team don't have to be genetically engineered specimens with god-like coding ability, as long as the team remains effective. Mr T. was a horrible communicator, you'd never find him sweet talking the team out of trouble... that's what Faceman was for.

With a high performing team, you can flip the factory model on it's head and bring the work to the team. Once teams have been given a chance to be seeded with the correct mix of people (or better said, the correct mix of strengths and weaknesses), and given a chance to gel and find their rhythm.... why tear down the team once the project is complete?

Instead, if the team has become an A-team, simply send them out on another tour of duty somewhere else in the organization. Instead of interchangeable developers, you now have teams that can be dovetailed with projects. I think it may just work, if we take the time to properly seed the teams and foster the next B.A. Baracus.