"The Factory" vs. "The Studio"

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?

Software Factory at ASU

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.

How to win friends and...

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.

Straight talk on EAI adapters

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.

Distributed (and evolutionary) version control

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.

The Road Ahead

Don Box charts the course. If they get this particular item right, there's reason for a good long party...

Contain the growth of platform surface area - it's easy to design a complex framework - it's much harder to design a simple one. Now factor in ~30-50% growth in functionality with each release and my ears start to bleed.

To mix metaphors this is a tough row to hoe. Removing production features is almost impossible. Adding new features that don't conflict with or duplicate in some way existing features is hard enough. Merging features to get more expressiveness (increasing the power/effort ratio) is an art form that few people can even comprehend.

Consider arguably the most famous software framework: Smalltalk-80. The team's focus was on simplicity and a high power/effort ratio. They began (rounding off a bit) about 1970. They remained mostly under wraps for about a decade with significant evolutions about every two years.

Smalltalk-80 really hit the mainstream's awareness with the 1981 Byte articles. By 1984 several books were published and vendors from HP to Tektronix had ported the system to their hardware. In 2003 the Smalltalk-80 system is still recognizable, and even operates, within the many commercial and open source Smalltalk implementations.

The Smalltalk platform is still yielding results. Tektronix has had implementations running in oscilloscopes. Object Technology International (now part of IBM) has had real-time implementations (which have led to IBM's real-time Java implementations). And recently a 128kb real-time implementation has become available, including a TCP stack. How does this stack up to the dotnet "compact" framework?

A tough row to hoe indeed.

There are two classic platforms available today: Smalltalk and Unix (let's say BSD and Linux). Legitimate reasons exist for not building on either of them. But every new system should begin with these questions: Should either of these systems be the foundation for this new system? Why or why not?