The "Rules of the Garage" were codified in a 1999 HP "Invent" add campaign. Recently while out of my home office I went looking for the original magazine spread on the web but the HP page that used to link to the PDF version has been retired. Searching through my archives I found a copy I saved a few years back.


Rules of the garage.

Believe you can change the world.
Work quickly, keep the tools unlocked, work whenever.
Know when to work alone and when to work together.
Share -- tools, ideas. Trust your colleagues.
No politics. No bureaucracy. (These are ridiculous in a garage.)
The customer defines a job well done.
Radical ideas are not bad ideas.
Invent different ways of working.
Make a contribution every day. If it doesn't contribute,
it doesn't leave the garage.
Believe that together we can do anything.
Invent.

HP Rules of the Garage (PDF) Download

I just started a 12-month contract assignment for Cylant Inc. in Lexington, Massachusetts working on the Windows port of their Linux-based security / network management product, CylantSecure. I'll be splitting my time working onsite in Lexington and remotely via VPN from my home office here in Maine.

Reference to Charles Simonyi's response to The Edge Annual Question - 2005 : "WHAT DO YOU BELIEVE IS TRUE EVEN THOUGH YOU CANNOT PROVE IT?"

Simonyi's response is of course about the future of software engineering.

My response / question:

Up until the last paragraph, this seems like the Intentional Software mantra. However, in the last paragraph he states:

"... Next, empower the programmers to program not the problem itself, but to express their software engineering expertise and decisions as a computer code for the encoder that takes the recorded problem statement and generates the code from it. This is called generative programming and I believe it is the future of software."

What encoder? A team of implementation engineers? Or a true general purpose generator that can transform the intention, whatever it is, into runtime code?

The assertion "... This is called generative programming ...." seems to me to be a redefinition of the term. At least so far as I understand the canonical definition given in Czarnecki/Eisenecker that characterizes GP as " ... modeling software families such that, given a particular requirements specification, a highly-customized and optimized intermediate or end-product can be automatically manufactured on demand from elementary, reusable implementation components by means of configuration knowledge."

The disconnect for me is that in the purest sense, one's intention should not be constrained by the existence of some objective or semantic mapping to reusable implementation components that can be programmatically actuated to affect the transformation. In fact, the right components might not exist. Or the appropriate mapping may not be defined and can't be programmatically inferred for lack of information.

That's not to say that building a system to help capture intentions is of no use. In fact it's quite useful. But I don't see how it's a generative programming system unless the set of intentions that can be expressed is constrained by the set of available components and semantic / objective mappings required to programmatically transform to runtime code.

I had a discussion recently about the mutable and volatile type qualifiers in C++ and realized that I really couldn't explain volatile despite the fact that I use it occasionally. Looks like I need to use it a lot more than I thought I did. Generally, I've worked under the assumption that if I explicitly synchronize access to shared resources between threads, then everything is cool. However (and this is really important), without explicitly qualifying shared resources with the volatile modifier, there's no guarantee that the compiler will not choose to cache a reference / pointer to the shared object in a CPU register. If cached, then regardless of the fact that I've explicitly synchronized access to the resource, then there's a non-zero chance that the data accessed within the synchronization scope will be invalid (because it may have been modified within another synchronization scope which will modifiy the uncached, memory-resident representation of the resource without updating the cached version).

Andrei Alexandrescu has a good article posted on CUJ that details a scheme for dealing with this situation using the volatile type qualifier and a simple smart pointer he calls LockingPtr.

Reference: Generic: volatile — Multithreaded Programmer’s Best Friend Volatile-Correctness or How to Have Your Compiler Detect Race Conditions for You.

I've posted a plan update to the News and Status section of Hyperworx.org.

The most significant point is that I've backed off my plan to publish this work under the GPL and will instead publish the source code under the Boost Software License - a move designed to better align the Hyperworx Project with C++ Boost and broaden the project's appeal to C++ programmers generally.

The first call for paper submissions for the 4th International Conference on Generative and Component Engineering (GPCE'05) went out today. This year's conference will be held September 29th through October 1rst 2005, in Tallinn, Estonia.

IMPORTANT DATES:

* Feb 25, 2005: Submission of workshop and tutorial proposals
* Mar 18, 2005: Notification for workshop and tutorial proposals

* Apr 10, 2005: Submission of abstracts (only for papers)
* Apr 15, 2005: Submission of papers and demos
* May 30, 2005: Notification for papers and demos

* Sep 27-28, 2005: GPCE workshops and tutorials
* Sep 29 - Oct 1, 2005: GPCE papers and demos

Received the good news that our friends Adam Platti and Felicia Fehey who were visiting Thailand for the holidays are safe and will be returning to the U.S. shortly.