I’m setting up a new SQL 2005 / VS 2005 VPC. While I’m pretty excited about SQL Express, I want to experiment with some of the features in the full product so I’m installing Express’s big brother. However, there must be some weird issue w/ VPC’s shared folders feature – the setup support files fail to install. If I connect to my host across the virtual network to the loopback adapter then the install works fine. As I said, weird.

On a related note, anyone know a good, simple, free/cheap DHCP server for XP? The one issue w/ using the loopback adapter is that you either hardcode network addresses or use the “Automatic Private Address” (i.e. the 169.254.*.* address). The auto private address works fine, except that it takes a while for the DHCP to time out before assigning the private address. Plus, in XP SP2, there’s an annoying tray icon that pops up to tell you that the loopback adapter failed to get a DHCP address. If I had a DHCP server for the virtual network hanging off the loopback adapter, then I could avoid all that timeout and annoying pop up tray icon stuff.

We keep getting more and more field architects and architecture strategy team members blogging. Remember, I keep a list (I am becoming the Scoble of Microsoft Architecture). Anna Liu is a field architect evangelist who presented at TechEd Australia (but we didn’t get a chance to hang out). Anna’s also been thinking about software development as an engineering discipline.

In addition to Anna, two of my teammates are blogging: Chris Keyser and Dave Welsh. Chris is a solution architect who’s doing some awesome next gen SOA work. He’s been bloggingabout using WSE2 to manage Security Context Tokens. Chris, like John deVadoss (who has relapsed into silence), is very pragmatic so it’s great to run radical ideas past him.

Earlier this year, our team “inherited” a group of awesome vertical architects – I’ve blogged about John Evdemon before who’s from that group. Dave is also from that group. Like many of our vertical architects, Dave is heavily involved in standards bodies – in Dave’s case it’s UN/CEFACT. He’s got an great article on how Standards Development Organizations traditionally work and another on how MSFT (and our specification partners) is improving on that process. He’s shining a light on the dark corners of the standard process, which is a good thing since so many people act like standards are a silver bullet solution. I love Dave’s description of the traditional standards process:

[L]aunch a committee, politically pick a chair, generate lots of hype and expectation on how this spec will solve world hunger, stack the new committee with people who may be able to contribute, host conference calls and arm wrestle the original idea down to some compromise that seems to make sense, then hope someone’s got a number of free weekends over to write up a draft of the new spec.

You want an example of the results of a traditional standards process? How about XSD? I think XSD is the ugliest widely-used spec around.  Don agrees, according to his comments from last years SellsCon:

Nothing illustrates [the cost of standardization] more than XML schema. XML schema is the quintessential example of what happens with a design by standards body specification. Rather than taking something that worked and something that was done and that there was experience with and effectively dotting the i’s and crossing the t’s you had two from every company off doing wanton innovation and invention without implementation experience. It was a train wreck in the making, especially when you consider the fact that you had people who vehemently disagreed about what they were building. Some people thought they were bringing object orientation to XML. Some people thought they were bringing database schema concepts to XML. Some people thought they were just, you know, reliving the SGML dream. So what do we get? We get a Frankenstein’s monster that is dumber than the dumbest person in the committee. No one person on that committee could have produced something this bad. It took an army of people to work hard day and night to build something that is not good. It’s not terrible – can we make it work? Yes. But it’s going to take a lot of work from a lot of plumbers and a lot of tool vendors to make XML schema palatable to the average developer.

A great example of the opposite approach is RELAX NG. It is widely believed at this point in time that RELAX NG is a better schema language for XML than XML schema. Why? Because two guys who were really smart said why don’t we go do this and let’s get it working and let’s build it while we do it and let’s iterate it and see what works and what doesn’t work. And then when we’re done we will take it to the rubber stamp – I’m sorry, Oasis – where they will carefully vet every decision and bless it and give it UN status.

I’m with Don and Tim: I want RelaxNG. More importantly, I want standards that are built like WS-* and RelaxNG.

My inbox is getting to be reasonable again. After two weeks on the road, it got up over 300 messages even though I cleaned it out before I left. Now, it’s back down to 45 messages. I already use rules to break out messages that come to various mailing lists, that come to our team alias, or ones that I’m cc’ed on. I’ve realized that everything that comes into my inbox falls into one of three categories: shit I need to know, shit I need to do, and shit I don’t need. I’m trying to be really diligent getting all these things out of my inbox. Shit I need to do gets moved to the task list. Shit I need to know gets moved into some other folder – usually by category though I have Lookout if I need to search for it. Shit I don’t need gets deleted. Of course, once I’m done with my inbox, I’ve still got to tackle those nearly 400 messages in my cc, team and not to me folders. I’m hoping this will help me stay better organized – something I manager tells me that I need to work on (along with focusing on what’s important and improving my diplomacy). One thing that taking this job has taught me, you can always get more email, whether you want it or not!

So while I was on vacation, my trusty teammates plus our cohorts @ MSDN published JOURNAL 3 on Architecture Center. The first article from JOURNAL 3 is called The Case for Software Factories by Jack Greenfield, co-author of the Software Factories book. Jack noticed that the article, an introduction to the concept of Software Factories, was being rated inordinately low. Currently, it’s been rated 4 out of 9. To compare, Pat’s introduction to the concept of Metropolis from JOURNAL 2 rated a 7 out of 9. So a 4 is a pretty low score. Granted, I’m not going to lose any sleep over it, but it was curious. Then Jack discovered this thread on Slashdot, where most of the posts were from people who don’t appear to have read the article at all. Here’s an example comment:

The “software factory” analogy has been around before. It’s nonsense, of course. The software analogy of a “factory” is the plant that presses CD-ROMs. Pressing the 10,000th CD-ROM of a software product is the software equivalent of building the 10,000th Nissan Maxima on a production line. But writing the software which will go on that CD-ROM is the software analogy of designing the 2005 model of the Nissan Maxima. Now, some software development is not very creative. Just as tweaking the design of a car model that’s been around for 10 years, to get something a little bit new for a new model year, is not very creative mech engineering. But it’s still design, not assembly-line production. A competent software engineer will be able to do it better and faster than a bad one. And a factory worker will not be able to do it at all.
[Comment by njdj from Slashdot thread Hackers As Factory Workers?]

What’s hilarious about this post is that point of the article is that the software industrialization will not look like a factory stamping out of exact duplicates that njdj describes! The key to understanding software industrialization is understanding the difference between economies of scale and economies of scope. What njdj describes is economies of scale – where you stamp out a boatload of multiple identical instances. Economies of scope is when you create similar, yet distinct, instances. For example, in my housing development, the houses are all similar, but not exactly the same. There are three or four basic designs used for around a hundred different houses, but the different instances of each design vary slightly. Since you can’t stamp out identical copies of the house, economy of scale doesn’t apply. However, economy of scope does apply – these houses use the same basic building materials, similar patterns of construction, the windows and doors are the same size, the plumbing and electrical wiring are the same, etc. Even though the houses aren’t identical, the construction company can build a bunch of similar, yet distinct, houses much cheaper than if they built each one “from scratch”.

I know njdj (and most of the other posters on the Slashdot thread) didn’t read the article, because the article comes right out and states:

We can now see where apples have been compared with oranges. Production in physical industries has been naively compared with development in software. It makes no sense to look for economies of scale in development of any kind, whether of software or of physical goods. We can, however, expect the industrialization of software development to exploit economies of scope.
[The Case for Software Factories by Jack Greenfield from JOURNAL 3]

I don’t know how much clearer Jack could have made his point, so I’m surprised that so many people missed it (or bothered to post their opinions of an article they clearly didn’t read). However, I’m not going to lose any sleep over it. I blogged a while ago about the the Oakland A’s exploiting the inefficiencies of baseball. Jack’s talking about exploiting the inefficiencies of software development. At some point, someone will be successful adopting a factory approach and everyone else will have to adapt. Software development has to change – you can’t expect to stay in the major leagues with a .160 batting average.

I’m not sure how this happened, but I overwrote the following post from July 27th. Found the original in Google’s cache, but not before I deleted the original. So here it is again:

Brad Smith (via Chris) wants to know what kind of cars ‘softies drive. I drive a green 2002 Chevy Blazer. This picture is from Patrick’s trip home from the hospital. In the picture, you can see my old car – a purple ’97 GMC Sonoma pickup truck. That got traded in earlier this year for a Nissan Quest minivan. Those two cars take a fair bit of gas, so we’re thinking of getting a hybrid – Ford has a hybrid Escape SUV coming this year. My mom has a hybrid Honda and loves it. In the meantime, I try to carpool or bus (or hit John up for a ride) to work as often as possible.