Noting an interesting article by Scott Kirsner in the Boston Globe entitled "It's the 'pure entrepreneur' who often leads the way".

Kirsner writes:

"Pure entrepreneurs are loopy and obsessed. They have a vision of the future, and while others are casting their lines into the water to see what will bite, pure entrepreneurs are jumping over the gunwales and swimming after the white whale.

Pure entrepreneurship, by my definition, is often driven by a belief that a major shift is coming -- and thus it's hard to find customers who already understand that they need the product a pure entrepreneur is developing.

Venture capitalists haven't yet started their inevitable lockstep sprint, racing to put their money to work. It's too early.

Pure entrepreneurship is often a solo enterprise, funded by credit cards, consulting projects, and second mortgages. It sparks revolutions and spawns big companies."

Of course I love to read stuff like this. The sobering reality is however that the ratio of successful "pure entrepreneurs" to disillusioned cranks approaches zero

This is an open response to Martin Fowler's recent blog posting MetaphoricQuestioning in which he states "... I'm very suspicious of using metaphors of other professions to reason about software development. In particular, I believe the engineering metaphor has done our profession damage - in that it has encouraged the notion of separating design from construction."

Martin, to a large extent I share your suspicions about applying metaphors from other engineering disciplines to software engineering. Employing the wrong metaphor limits one's thinking to an artificially narrow subset of possibilities. However there's one branch of engineering that I believe is a rich source of metaphors and nomenclature for discussing software systems and the tools and methods required to build robust and flexible systems. Specifically, I believe that electrical engineering (more specifically digital hardware engineering) is a valuable source of appropriate metaphors for discussing software.

Consider the task of designing a new CPU. Very little is left to chance due to the extremely high cost of creating even a single physical device suitable for test and verification. Digital design engineers rely heavily on standard cell libraries to reuse time-tested-and-true intellectual property, employ high-powered hierarchical design tools, and subject their designs to rigorous simulation and verification prior to taping a new device out for fabrication. The hardware industry has proven the utility of their methodology by consistently delivering high-quality devices of enormous complexity.

A hot topic in the hardware design industry these days is so-called System on Chip (SoC) designs - custom ASICs composed of reusable IP subsystems. There's a significant effort in the EDA and CAD tools industry to motivate better specifications and tools to support the exchange and sharing of reusable IP. One effort that's quite interesting is the Open Core Protocol (OCP) that is working to define and refine a hierarchical specification for hardware IP exchange.

At a high-level of abstraction, a SoC is really not too much different than a software application. Both ideally leverage reusable IP. Both require significant amounts of glue logic. Both need to work as advertised. Casting software engineering in terms of digital hardware design metaphors makes a lot of sense. There's a rich nomenclature already established and it's clear that their methods work well. Why go off and reinvent the wheel? We should just copy the hardware design community and adopt their formalisms as our own.

What's required is a high-level, platform and language agnostic, way to describe reusable software IP that can be leveraged to automate software application integration, verification, and deployment. Software Circuit Description Language (SCDL) is set of XML specifications motivated by my work on the Hyperworx Platform Project that leverage a hardware metaphor to describe reusable software IP and software applications composed from reusable software blocks. Just an example of how metaphors from other engineering disciplines are not necessarily a bad thing.

Just ordered my copy of "C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond" by Dave Abrahams and Aleksey Gurtovoy from the Addison-Wesley website. I'm very much looking forward to diving into this book and trying to understand the boost::mpl. Enlighten me guys

Just noting the first snow flakes of the season falling slowly outside my office window as I sit here writing code. This afternoon's walk in the woods with the Huskies should be enjoyable as they get really pumped up and comical when the snow flies.