Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

One periodical I will not name (okay, it ends with "world") seems to run an annual story on the potential for software factories.

What is a software factory? Why, it's a set of components that enable developers to assemble programs, instead of writing them by hand.

I suggest that the majority of software departments around the world are already software factories and the gurus pushing the software factory ideal have completely missed the bus.

The Software Blacksmith Shop

Before examining real software factories, I will have to define the small smidgen of people who are not. One such enclave still exists; a small segment of the computer science department of Hood College.

In 1993 I took a class in assembler at Hood. For one of the assignments, we had to take a half-dozen instructions in machine code.

A sample problem might be to convert the following assembler statement into hexadecimal notation:

     MOVL Ax, 10;

Turning MOVL into Hex means looking up the assembly command, marshalling the operands, adding buffer for the third operand (this command doesn't have a third operand, but ADDL VAR1, VAR2, VARr3 would, and all operations took the same space, so I had to pad it), then doing an endian conversion and possibly fiddling with parity bits.

Hex is ugly. Really bad. Seriously, you never want to write code--or anything else--in hex.

Of course, you probably don't have to. Today that kind of work is only done by theoretical computer scientists, hardware engineers, and struggling college students.

The next step up from hex is an assembler--coding the MOVL Ax, 10 commands.

In class, we wrote a lot of assembler--so much that we learned how to write functions and procedures in assembler, or mimic them using the stack. Eventually I could paste all my functions into a new program and then, for the most part, write a main routine that called those lower-level functions.

You guessed it--that's a programming language. The next step up is C, which is great. Typical C programmers have access to thousands of functions, like atoi (converts a string to an integer) and sprintf (which formats a string.) It could be argued that C programmers aren't really writing source code as much as assembling components and adding glue--which sounds a lot like our definition of the software factory.

But wait, there's more ....

Can't We Automate Our Automators?

Ever since C programmers began flipping pointers, management has been trying to find ways to cut costs by eliminating programmers. The goal has always been to program at some higher, more powerful level of abstraction. Eventually, this level would get high enough that typical business users could sit down and write programs, and the need for programmers goes away.

To do that, companies needed more powerful languages. The dream of the 1980s was SQL. A Structured, (English) Query Language was going to be so simple that "business people" could do the work directly and remove developers. It was wonderful; no more messing with pointers.

Things didn't quite turn out that way. SQL is code; code is specific and must be parsed by a complex grammar. Writing code takes analytical thinking. People who think analytically are, well, programmers. In the rare case where a SQL job did transfer to an "analyst" in finance, that person found that programming took up his entire day job. Often those jobs transferred right back to the IS department two years later.

Then there was Visual Basic, which was supposed to make client/server programming so easy anyone could do it. Then Graphical Database software was going to make database design so easy "business people" could do it, again eliminating programmers. Then Microsoft FrontPage was going to bring professional web development to the masses. Today it's business intelligence tools that are going to eliminate programmers, or maybe web services. I can't tell.

All of these technologies are great and helpful. On the other hand, all of them promised to eliminate the Software Engineering department and utterly failed. Instead, the Software Engineering department absorbed the technologies, had a great productivity increase, and found that the business found dozens of ways to exploit these new technologies. The productivity didn't make the department smaller; instead, it enabled more aggressive and more complex projects.

Now, I am not against those new technologies--I'm all for them. In skilled hands a chainsaw is unimaginably better than a handsaw. I would never want to code in C when I had Perl available, or write my own modules in Perl when there is the Comprehensive Perl Archive Network (CPAN), the largest set of freely available code modules in the world.

Now every time you read "module", start to think "components."

The Economic Argument

The fear which I alluded to before is that the job of programmers is to automate things, and all those Oracle, Microsoft, and Business Objects developers are out making software that is so productive that the number of programmers will decrease.

Hogwash and rubbish. Yes, developers will be more powerful--that's great. We should be, and it will increase the value of the goods and services we provide. At the same time, I submit that the need for developers will remain constant or grow. The "secret" reason is no secret--in the next 10 years, companies will continue to gain competitive advantage through technology. The way to do that is through investment.

That suggestion deserves more detail. The Internet, e-mail, cell phones, TiVo, and other technologies all create opportunities to drive revenue that just did not exist 20 years ago. Gas stations, restaurants, credits cards, and hotels all have rewards programs good for merchandise, money, or college tuition for your kids.

Every one of those programs requires a web site, a systems integration, automated e-mails, security, programmers, managers, and technical support. That is just one example.

For another data point, consider what positions companies are creating and how they are competing. INC Magazine publishes an annual list of the 500 fastest growing privately-held companies--The Inc 500". If you look at the list, go to each companies homepage and click "careers" an incredible percentage of those companies are hiring technologists. Those technologists are writing the software that gives those companies advantage--data mining, systems integration, and often new product development.

When an insurance company needs to create a product, who does the work? The IS department. When the sales office needs to implement a CRM package, who do they call? The IS department.

What's Really Going On Here?

I started this article talking about software factories--the idea that software development could be made predictable, stable, and repeatable by the use of higher-level constructs, such as domain-specific languages and code generators.

These things are all well and good; in fact, I applaud anyone who wants to use sharp tools to be more productive. But predictable and repeatable? No, I am afraid if we could just do the same thing over again, we'd burn a CD and be done--the software development process will continue to consist of doing things that have never been done before. The challenge in that environment is to constantly communicate with the customer, putting him in the driver's seat in deciding what to do, and to deliver enough value fast enough to be a good investment.

No one talks about evolving creative writing to be more stable, predictable, and repeatable. Better, sure, absolutely, but not more stable, predictable and repeatable. The reality of business suggests that writing projects need to have some deadlines and deliverables. Those deadlines and deliverables may change as the scope of the project changes, and it is always possible to cut planned chapters.

Software development and software testing are creative processes, much like art or writing. There are schools that teach people with little talent how to churn out works of fiction--the romance novel is perhaps the ultimate example. Romance novels are often template-able, stable, predictable, and repeatable.

They just aren't very good. Oh, and when your software isn't very good, at best, you go bankrupt.

At worst, people die.

The Software Factory of Today

I am not suggesting that the "software factory" people are off course; I am suggesting that they are completely and totally grasping at straws. The current software factory that is in vogue is a vaguely related collection of buzzwords that somehow involve a system that automatically generates the application for you. The fact that that UML and the wizards in most 4GL languages have been doing this for years doesn't seem to enter the equation, nor that the inevitable "customization" of the generated app is the same thing as hand-rolling business logic--the very problem that software factories are supposed to solve.

While most software shops meet the pure logical definition of a software factory, the environment is not stable, predictable, and repeatable. It's also not going to be; that's the nature of the work. Software development organizations are engineering organizations at best, craftsmen most often, and manufacturing organizations about never. Software development isn't the plant floor; it's the prototyping group and the engineering group. The software guru probably just doesn't get it.

Next time some talking head suggests that we "need" to move toward software reuse, a service-oriented-architecture, or that "tomorrow's software factories" will be assembling components instead of building systems, don't feel intimidated. Let's stand firm behind our functions, our code libraries, high-level languages, 4GLs, interpreters, and object-oriented-code, and politely point out that we've been working in a software factory for decades, continually shifting to ever more powerful tools.

When the concept of software factories come up, we shouldn't feel bad about ourselves, and certainly we shouldn't feel motivated to "catch up" to a bag of hot air. No, No, feel sad for the gurus. After all, it must be terrible to have so many interviews to do but so little to actually say.

Matthew Heusser actively develops working software and also writes and speaks on systems improvement. He can be contacted at Matt.Heusser@gmail.com or Excelon Development.

RELATED ARTICLES Logging In C++ : Part 2 OutSystems Updates Agile Platform SDK, .NET Controls Released for Communications Enabling Web Pages Welcome To the World of Cryptographic Voting recls 100% .NET		TOP 5 ARTICLES No Top Articles.