Quality without a Name

Richard Gabriel is generous enough to offer one of his books online, Patterns of Software. Written over 1 binary millenia ago (1101 years), it is a philosophical look at software development, heavily influenced by Christopher Alexander, the inspiring architect.

Alexander's works are on my reading list, but Richard does a reasonable job of pulling out key principles related to software.

However, the most inspiring and poetic essay thus far has been Alexander's foreword. He reasoned for perfection and beauty in software, whereas so many of today's pundits argue for speed and turn around. Of course getting software done fast is important, but it must be done right - especially if you're building a platform to last for years to come.

All too often there is no beauty in what we ship. Our standards for architecture and design are below the bar, and our customers bear our disgrace. For example, on one project I worked on a few years back, I gained access to a software vendor's code. Low and behold, in the mist of their main algorithms where huge conditional branches based on customer IDs where they had tailored the software to each particular client. The code was painfully unapproachable and poorly performant.

An important principle stated by Alexandar is key, "In my life as an architect, I find that the single thing which inhibits young professionals, new students most severely, is their acceptance of standards that are too low... Gradually, I show the students that they have a right to ask this of themselves, and must ask this of themselves."

My experience is consistent with his; that when you push the standard, the work is more gratifying, it is more fun, and it has a deeper meaning. 

One of Alexander's points is about finding that "quality without a name". I'm still thinking about what that means to me for software. I'll let you read and ponder Richard's discussion on the topic to find meaning for yourself. 

In Christopher Alexander words: "If the heart of human existence, what matters most deeply to man, woman, child, really can find its way into computer programming, and into the programs, and into the meanings of those programs, and into the actual code and substance of those programs, and into their effects—then the future world will be changed immeasurably."

Foundational work on DSLs

Over the holidays I've been doing lots of reading and coding. It's been great.

I re-read Martin Fowler's writing on language workbenches. If you want a well written, crisp definition of language oriented programming, read it. Or, if you're struggling with what Oslo is all about, read it. Martin's work is foundational at describing what I believeto be  the future of programming and application building - what some have called language-oriented programming.

Oslo is here to enable this vision. Our language work brings a simple, easy-to-use notation for writing the abstract model that Martin talks about; we call that part of the language MSchema. Our language also enables the writing of DSL grammars over that model; we call that MGrammar.

Pay attention to fact that we do not talk about them as different languages - but as One. That's a key concept  that has yet to be exploited by our blogging community and by us, partly because we haven't yet done the work to integrate MSchema with MGrammar. But just wait. That's our longer term goal - to integrate both abstract model and DSL definition languages making Martin's inspiration a reality in a very easy to use way.

Add in a great tool like Quadrant to do textual and visual editing of both model and DSL, and the horizon of that vision is much closer than you think.

We'll be talking more about the integration of the language in the coming months.

Busy busy busy

I miss blogging about technical stuff, but alas I don't much to say without thinking.

I haven't had time because we're way busy getting organized for our next milestone, and planning out the schedule for V1 Oslo.

But - I hope to get some good stuff out later this weekend.

Calibration of the Calibration

I just sat through (and left early, thank goodness), an HR meeting to calibrate the calibration model.

I was praying for a natural disaster.

I use to work for a large automotive company (no names), and it felt like I was in one of those meetings. BTW - have you seen their financial position lately? I hope that's not a prophecy of things to come.

Now, you may be saying, "Jeff, why didn't you fix the meeting?" My fix is don't have the meeting. Get back to work!

Seriously, IMHO, calibrating people is learn-by-doing/watching. People are just so individualistic, and projects are so unique. You need a basic framework (we have one of those). Then with the help of your manager and peers, you develop your own intuitions and experiences. 

As a geek, I generally love recursion and meta, but in this case "Death to calibration calibration!"