How many of you are software developers working in a location which is referred to as "the factory" by senior management, sales, and marketing? Maybe even by engineering management, since they tend to align more with the rest of the company?

This label always (and I have been hearing it and commenting on it for the last 20 years) struck me as odd and indicated more of a misunderstanding if not a misguided wish on the part of management. The last time I had a sit down discussion with someone on it was 10 years ago. Since then I just shrug it off and work on the bigger issue from other angles.

When I had that discussion I was talking with people who came from Tektronix, a manufacturer of oscilloscopes among other things, including then X Window terminals. (Does anyone remember those? Are they still sold?)

The analogy I made went like this...

TV designers get together in the lab and iterate over ideas. Those ideas take shape, and eventually are ready to be produced on an assembly line. The activities in the lab are design-time. The assembly is factory-time.

Software designers get together in the, well, cubicles, actually. Those ideas take shape, and eventually are ready to be copied to tape. (Remember shipping software on tape?)

The cubicle activities are design-time. The copying to tape is factory-time.

What's the significance? Factory-time is something step-by-step repeatable and can be treated and "optimized" as such. The cubicle time is repeatable in the sense that a carpenter uses basically the same tools and materials every time he builds a kitchen cabinet. But each time the kitchen is a different shape, the wood has different features, and the customer has varying tastes. What gets repeated each time is a creative activity.

The TV lab and the software cubicle are really studios. The only organization I know of that treats software as a studio process is Ken Auer's Role Model Software. The XP bull pens aren't talked about in these terms, but they should be.

Do I need to add that Ken comes from the creative Smalltalk community of the 1980s where software has long been seen as a collaborative, creative set of activities?  ¶ 7:41 AM

Although the name is horrible, the idea is commendable. Arizona State University has an organization called the "Software Factory". Their mission...

Here, as at other universities, software development is becoming ever more crucial to research. Researchers typically develop software by “ad hoc” methods, hiring students to do their programming. This works out in some cases, but more often than not the students lack experience in software development and the faculty lack experience in software engineering. This leads to a sub-optimal learning experience for the students and poor software products for the researchers.

The software factory idea, then, is simple: Gather these part-time student programmers in a common facility, put them under professional management and mentorship, and use sound software engineering techniques in the development process.   ¶ 7:25 AM

Mark Pilgrim writes of the launching of a new MSFT web service...

I’m going to repeat that, in case you missed it: the documentation for the web service is wrapped in a Windows installer which will only install over Visual Studio .NET.

I'd cry if I wasn't laughing so hard that tears are already streaming down my face.   ¶ 5:20 PM

Sean McGrath gives us the business on EAI adapters. What a breath of fresh air. A truly useful economics of integration that lines up with the EAI vision if your intent on taking proprietariness out of the picture.

Here's how I interpret his hints toward an alternative for 80% of the cases a proprietary EAI solution might be purchased:

• A standards-based exchange format (like XML).
• A commodity TP monitor for simple transactions (like Apache, take your pick) (with a simple means of exchange).
• Commodity persistence (and perhaps some caching) (take your pick based on your budget, needs, and assorted risks).
• Finally a simple set of rules for coordination.

The hard part is already proprietary to your legacy applications and ERPs. Sometimes the term "adapter" seems intended to imply "easy to implement". Unfortunately customization, vendor quality and the "stovepipe" nature of EAI products themselves get in the way.   ¶ 1:25 PM

The build instructions make this system seem a bit fresh yet, but Ted Leung points today to a very interesting version control system, especially for distributed open source evolutionary systems. In particular...

• defining different "acceptance criteria". monotone's update algorithm permits sorting and filtering by certificate; this means you can tell it to ignore changes until someone you trust is willing to attest to their quality, either by code review or test results. simply committing code does not force any other end-users to run it. (this feature is only partly finished -- the UI for it is still wired to one setting).
• decentralizing trust. monotone's operations are all based on checking RSA certificates. there is no central authority to which you must appeal to participate, or to be granted "commit access". on the other hand, nobody has to trust or accept your certificates, unless they happen to like you.