Intentional Software

Learn more about Intentional

This fall you will have two opportunities to learn more about Intentional. We will be presenting at two major conferences, JAOO and OOPSLA. At both conferences we will give an update on our technology and also do a sneak preview of the software.

First at JAOO, which is in Aarhus, Denmark, October 1-6, we will be presenting Intentional Software in the “Domain Specific Languages, and Beyond” track. This track is bringing together some interesting presenters to highlight practices around DSLs. Just based on the session descriptions Intentional is probably the “...and Beyond” part ;-).

Then at OOPSLA, which is in Portland, OR, USA, October 22-26, we are presenting a paper on Intentional Software in the Onwards! track. We are honored to be included in this track which, to quote the OOPSLA description, “…is the place to reveal the revolutionary, air the provocative, and expose the subversive.

Both JAOO and OOPSLA have a strong reputation on bringing together thought leaders in the software space. These conferences are often the first to highlight new and emerging technologies. These conferences are typically where you will hear about new developments, before they show up in trade magazines. We are very honored to be invited to both of these world class conferences and look forward to meeting many new and old colleagues, perhaps including you.

A Process With the Right Degrees of Freedom - the Lagom Process?

We have discussed a few times earlier the need to use the right abstractions, or the right degrees of freedom, to solve a problem. The best solution is something that exactly fits the problem domain, being it the right size screwdriver, a software platform or a programming language. Often times our languages, tools and platforms have too many - or even worse too few - degrees of freedom and we have to put in extra work to compensate for the superfluous or missing degrees. To quote from our earlier posts:

So to generalize the “harmfulness” theory, we need to refer to the degrees of freedom in the problem statement, in the domain intention. A programming feature is harmful in proportion that it has more degrees of freedom than in the domain intention that it is used to solve. By degrees of freedom we mean the potential parametrizations (arguments, properties, attributes, or parameters) for the abstraction and the gamut of their values. This latter is determined by the parameter type: the range of possible parameter values can be small for enumerated types, or very large, for example the “parameter” is a statement list as in a loop. Harmfulness is related to excess degrees of freedoms: more parameters than necessary, or larger parameter types than necessary for the purposes of the problem intention.

We can expand this idea to also apply to the actual process being used. If a process adds more steps, tasks, deliverables – in summary more work – that is required, we think of the process as getting in the way and not helping. The process is causing extra work, it causes errors, and it adds complexity. In fact a lot of the processes that are popularized today is actually compensating for missing degrees of freedom in other areas. We need to work around the lack of power by copying information, reworking and repeating. For example, because we have no good way to transfer the domain intentions between the domain expert and programmer, the industry has come up with many ways to compensate for this problem in the process. Examples include modeling, customers on site, prototyping, iterative development, storyboarding, meetings, specs, use cases and user stories to name just a few.

What are the right degrees of freedom for an ideal process? It could be something that helps make the right tradeoff of change and progress. In other words, when a change is needed, we not only allow the change, but also implement the change in a way that ensures progress. Here we use “a change” fairly broadly. From the dictionary:

A transformation or transition from one state, condition, or phase to another

A change early in a project could be from an idea of a new product to something tangible, for example a prototype. A change later in a project could be to refine the functionality of a user interface. The tradeoff between change and progress is important because we need to organize the work so that every change also ensures progress. We wrote earlier about a process idea from Christopher Alexander that is now surfacing in a different field, namely architecture. Alexander suggests a new type of process he refers to as “making” where the customer, architect and builder are collaborating during the entire process and refines the degrees of freedom continuously to make something that exactly fit the customer’s needs.

Jimmy Nilsson has some similar ideas. He argues that Extreme Programming is sometimes perceived as too rigid or too extreme. Rather, he suggests a “Lagom Process”. (Lagom is a Swedish word that means something like “just right for this situation”. He describes the process as “It's probably influenced by Agile, but it's built up of the pieces that together form a mix that is lagom for the team and project at hand. That's it.”

On a similar topic, Jeremy and I met with Ivar Jacobson last week. Ivar described how he is now rethinking the whole Unified Process approach into something completely different. It is clear that over the last few years it has been a challenge to separate the domains, or concerns, of the Unified Process. Per Kroll, who is responsible for the Rational Unified Processes, and his team is also trying to address this. Reading the current process is like reading source code. We compared source code in a previous post to encryption – contributions from multiple separate domains are intermingled together in the description – and the result is very hard to read, understand and maintain. Ivar has some new ideas that separate the domains of the practices from each other. A practice is described using a set of process cards each including activities, competencies and artifacts. It is great to see that separation of domains is also finding its way into process thinking. And hopefully as we strive for radical simplification in the way we build and use software, our processes will also be radically simplified.

A Story of Four Benches

Hi, my name is Shane Clifford, and I am a developer here at Intentional Software Corporation. The following story is inspired by the work we are doing at Intentional, as well as an experience related by Christopher Alexander in Book 3 of The Nature of Order, at the end of Chapter 11.

---

Once upon a time, there was a village with four neighborhoods. Each neighborhood had a little park that its inhabitants enjoyed, and there was a bit of competition amongst the neighborhoods to have the best park in the village.

One day, during a neighborhood meeting, one of the neighborhoods decided to add a new bench to their park. Before the next meeting, the head of the neighborhood association sent requests to three world-famous bench manufacturers requesting proposals based on their latest designs. At the next neighborhood meeting the three designs, which were the height of fashion in manufactured benches, were presented to the members of the neighborhood. After some consideration and debate, it was put to a vote, and one of the benches was selected with 45% of the vote. Many of the neighbors were unhappy with the selection, but clearly the most popular bench had prevailed through this democratic process. They now had the best park in the village!

Well, one of the other neighborhoods observed what had happened, and they thought, “Surely, we could do a better job of getting a bench we are all happy with, and then we will have the best park in the village!” The head of their neighborhood association found a different bench manufacturer that offered mix-and-match bench components, so you could order a “customized” bench to meet your specifications. The neighbors began to select their favorite components from the various pages of the catalog, but soon discovered that the wood seat slats that they liked did not come in the right length, and the back with the pretty scrollwork did not work with the green legs they liked most. Eventually, they chose some metal slats and different legs; because most people thought they would have the best bench if it had the pretty scrollwork. The bench was installed and the neighbors were very proud of it (but they didn’t sit on it very often.)

A third neighborhood observed what had happened in the first two neighborhoods. At their next meeting, one of the neighbors said, “I bet we could have the best bench in the village if we built it ourselves! Surely, we can do at least as well as the other neighborhoods did, and we can do other things with the money we save.” Everyone thought this was a wonderful idea. A team was put together and—even though no one in the neighborhood had ever built a bench before—they set out collecting the raw materials and putting it together. Occasionally, the team went back to the entire neighborhood to get suggestions on paint color or the height of the back. Eventually, they unveiled a simple, but very beautiful bench in their park, and all of the neighbors were very proud. Their hand-crafted bench was clearly superior to the other two benches. (If you ignored the fact that it wobbled a bit when you sat on it, and didn’t think about the spot on the back where some mistakes had been patched up during construction.)

Now the fourth neighborhood was very unsure about what to do. They did not feel comfortable building their own hand-crafted bench, but also wanted something much better than either the manufactured bench or the mix and match, manufactured component bench they had seen in the other neighborhoods. Finally, at their next meeting, one of the neighbors said, “I saw an ad in the newspaper for a new company that is offering a new bench making experience.” The neighbors were very tentative, and skeptical, but decided it was worth taking a chance in order to outdo the other neighborhoods and also to keep their park a beautiful and special place. They contacted the new bench maker and he asked to attend their next neighborhood meeting.

When he arrived, he had a flat-bed truck with several machines in the back. The bench maker took the floor and immediately began asking questions. “What is the most important feature of this bench for your neighborhood?” Eventually, the neighbors agreed that it needed to be comfortable. “Ok, what is the next most important feature of this bench?” After a lot of discussion, they decided what was really important was that it face toward the most beautiful view in the park.

These questions went on for a while, and soon, the bench maker began arranging his machines in the back of the truck into a new sequence after each question; later, after each question was answered, he turned knobs or adjusted levers on individual machines. Many of these later questions covered somewhat more detailed subjects such as material, shape, color, and height. After about 20 questions, an image of their bench, positioned where they had decided was best, appeared on a large screen on one of the machines. The image changed as each subsequent question was answered. Sometimes, their answers changed after seeing the latest image, and they would backtrack a bit.

Eventually, they discussed much smaller, ornamental details of the bench. Finally, after a few hours, the 50^th question was asked, “What should the shape of the feet be on this bench?” After some discussion with the bench maker and going over several options he presented, the neighbors agreed a particular claw foot complemented everything they had decided up to that point. The bench maker thanked them all for their help, and pushed a button at one end of his series of machines.

The machines hummed for a short while and eventually a beautiful bench that matched the one in the image emerged from the machines. The neighbors installed the bench in the exact place they had selected. They all felt very proud to have taken part in making their bench, and enjoyed visiting the park much more from that day forward.

How is this story relevant?

Christopher Alexander’s A Pattern Language provided well known inspiration for the concept of patterns now widely taken for granted in the software industry. Alexander’s patterns of course were specific to architecture and construction of buildings, but the parallels to software development are easily drawn.

In The Nature of Order, Alexander describes a new fundamental process for architecture and construction that has already inspired new work in software. A good example is Organizational Patterns of Agile Software Development by Jim Coplien and Neil Harrison.

Alexander’s fundamental process is generative, iterative, and transformative. It adheres to a tenet that the owner of a building must be involved in all phases of its design and construction. The same applies to the architect. This does not mean the owner and architect do all of the work. It simply means that they are aware of what is taking place, and are making the major decisions. In his fundamental process, the design of a building neither begins nor ends with drawings. Planning, design, and construction must be intimately intertwined in order to implement a generative approach. This combined activity is called making. Alexander acknowledges that this will also require "ultra-high-tech” materials and equipment and advancements in construction techniques in order to be cost-effective in today’s environment.

In this definition of making, it is theoretically impossible for a successful building to be built from a set of drawings which specify every detail, because that would cripple the capacity of feedback to help shape the elements and details as they are built. […] our 21^st-century techniques allow details to be fitted exactly to their positions in the whole through some new form of almost “biological” process.

–Christopher Alexander, “All Building as Making.” The Nature of Order, Book Three: A Vision of a Living World. Berkeley: CES, 2002.

I see many similarities between Alexander’s fundamental process and the fundamental process Intentional Software enables. When making Intentional Software, the domain experts’ intent is captured in the system in their own domain terminology. The programmers contribute their own expertise both to enhance the expressive power available to the domain experts and to generate an executable system. The software is made through the combined effort and knowledge of domain experts and programmers working on the structured code.

In many ways, we software developers should be better off than building owners and architects. Making software, by its nature, is more readily adaptable to a fundamental process of this sort than is making physical things like buildings. Unfortunately, the software community has not had the technology or process necessary to take advantage of that fact.

We are hiring!

Currently we have openings for a select few outstanding programmers. If you would like to work on a new breakthrough product that will transform how software is used and developed, this is your opportunity. If you are bright, highly competent, willing to take risks and enjoy having fun working together in a team, you will fit right in. Your specific background, your number of years in the industry or the specific technologies you master are less important.

To learn more about Careers at Intentional Software Corporation, click here. And make sure to check out our recruting video!

Petzold's April Fool's Joke

Hope you enjoyed the link to CSAML in our News section.

I think this is a very funny joke. Generally when a joke has to be explained, it is not considered funny, so I am not going to explain it but I’d like to discuss its significance because it relates very much to domain specific languages and to what is wrong with the current implementations.

It is important to realize that Charles Petzold’s examples are nearly real – they employ current techniques that people have to use for domain specific languages out of sheer necessity – but he applies them to the C# language where a highly usable but expensively developed syntax is already available. The contrast between the two - the luxurious C# and the cheap XML - is appalling and we find that funny in a kind of cruel “Upstairs, Downstairs” way – this was the British TV drama where the upper-class household upstairs was in contrast with the lower-class servants downstairs.

With projective systems you can have both great looks and inexpensive implementation. But there are two additional fine points: the source, no matter what is the notation, should not contain information that is computable from the rest. It should contain only things where the user is the only authority – that is the user’s intentions. For example, by this rule we could omit including the information that in the statement A=5/(B+27*C) the operand 27 is a multiplier, unlike in Petzold’s XML statements where an extra <Multiplication.Multiplier> tag was given. That information belongs in the definition of the multiplication, not in the source tree. Otherwise all we have is another hoop that the user and language transforming programs have to jump through.

The other point is that is that the awkwardness of XML and the lack of projections causes the language designers to intermittently fall back into text syntax.This happened, for example in the “Type” attribute of the joke: <Literal Type="{x:Type Int32}"> ; or in the XPath expressions of XSL in real life.

Here is how a similar example looks as an Intentional Tree:

Assign(A, Div(5, Plus(B, Mul(27, C)))

In this instance the Mul definition already knows that the first argument is the multiplier.

When we project it in the Intentional Editor the editable screen looks like this:

Of course many other editable projections are also possible, here are just a few more for fun:

Or:

The interesting point is that even the “not-projected” representation is not at all terrible; it looks a little like LISP. It is not intended for normal use by people; it is a projection of the binary internal representation. The main reason that it looks better than the joke example is that it does not include any information that should be in the schemas, or which is part of the general domain knowledge, in other words it is Intentional. Of course, if you want the real XML syntax, like Petzold joked about, it is just another projection where the schema information is included. And with that you can say you are a real XML programmer with all the scars!

Space News

While I try to keep my private life (such as it is) separate from work, we are getting a lot of hits because of the announcement of the contract I signed for an orbital flight on a Soyuz spacecraft and a visit to the International Space Station (ISS).

For the full press release see Space Adventures.

I want to re-iterate that my main focus before and after the flight remains with Intentional Software. We did not expect to make the space announcement at this time, but the story broke in Moscow so we had to scramble to get some material together. The actual flight assignment has not happened yet, but in any case the flight is not expected before the fall of 07.

I am very excited and feel privileged to participate in this adventure. The engineers and cosmonauts in the Soyuz program are truly an impressive bunch and their booster and spacecraft are marvels of system engineering, meaning that with modest means they created a reliable and still valid design. I am very fortunate to be able to study this system in detail.

Of course I could not resist looking at the components from the Intentional point of view. Look at the following snippet from the checklist:

It has been produced by the Russians using Microsoft Word! While I am delighted of that, I can see that checklists are a very interesting domain which could be generatively connected to the actual flight software; but even just for consistency checks and other configuration reasons, an intentional encoding would be much better than a Word file.

The syntax of the notation is very strict and is used consistently in the over 200 pages of normal and off-nominal (meaning emergency) checklists. In this example, the first line means: Start the timer, turn on KVD BO-SU (docking unit pressure equalization) valve using command C3. Observe light on, if light off (the dark rectangle), we have off-nominal condition (dotted border), action is to communicate with (Dpo) ground control (UZ). The next line is to be executed 1 minute after the first line, and the same valve is turned off. As you can see, it is a very precise domain specific language.

Appropriate Levels of Abstraction - Follow up

Thank you all for the great comments on the blog entry "Appropriate Levels of Abstraction". We all seem to acknowledge the general solution of finding the right level of abstraction to express our intention. Still, we recognize the issues with current coding practices. As Refux said:

Let’s face it, the code is dumb, there is no higher level picture.
We need to figure out how to encode real useful and actionable data so code path decisions can be made at runtime.

This is exactly right - it is only the code in its context, with its generator or compiler - that gives it meaning during execution. But still, there is a higher level picture - it is just not recorded. Even for the sort example, the domain description of what the data is likely to be like, could be useful to decide which way to go. And we can go even further - why do we sort? Is it for presentation to the user, is it for merging, is it for searching?

Separating these two issues are at the core of the solution. By changing what we put into code to be more intentional information that captures more useful and actionable data (our intentions), we separate the source code from the execution of it, which is controlled by the generator or the runtime components. Code therefore needs to get refactored into one part that is the generator and runtime components, which obviously can not be as static as they are today. The more intentional code will then be what these components operate on.

And as Paddy points out

Often parts of a problem could be better solved in a different language, if there were easier ways to develop in multiple programming languages then savings could be made.

So true! Our tools and languages are simply not designed to mix very well. Still, it is getting to be the rule rather than the exception that languages like SQL, HTML and XML gets embedded into C++, Python or Java, and this is often very clunky with limited semantic and syntactic support from our tools. Today language design is out of reach for most programmers (and managers). As Scott points out:

... we tend to get stuck in the mind frame of using general-purpose language for domain-specific problems (and this idea is usually enforced by management).

So how do we get unstuck from the current use of languages? Obvioulsy new technology is required.

The software engineering community has aspired to new more powerful languages for decades, and often very domain specific languages. Indeed, the first higher level languages - Fortran and Cobol - were designed with the goal to be used by domain experts directly, mathematicians and business people respectively. They had many domain specific abstractions in them. As we know, they were not fully successful in reaching their goal - still professional programmers were required to use these languages properly. Interestingly, the first programmer oriented programing language - Algol - actually came AFTER these first higher level languages. And as we know, essentially all general purpose languages today, including C, C++, Java, Python, Perl, Ruby and C#, are all direct or indirect descendants from Algol.

So not only do we need to revisit new language designs, but also the dominant paradigm of how languages are used and what they represent. Wes gives us a good example:

In my experience, systems that work to permit one to move between abstraction layers seamlessly have also made it extremely difficult to make unanticipated changes. Conversely, source code is easy to understand and edit, and as a form it has flourished in the face of many efforts to replace it, notwithstanding the lack of seamless abstraction layers. I'm hoping that Intentional Software can make a form that accomodates the evolution of software and lowers the cost of making unanticipated changes.

First thanks for your support, Wes! We certainly recognize that moving between abstractrion levels to make unanticipated changes is troublesome although sometimes required. Many current DSL, model driven and even aspect oriented tools simply work best when you stay at only one level of abstraction. And of course this vastly limits the value of these type of approaches. Intentional Software has a unique approach to resolve this that centers around unlimited parameterization and unlimited projection. We will discuss more about this in a future post.

Computer Languages Multiply

In the 2005 December 14th issue of Wall Street Journal (requires login) there is an interesting column by Lee Gomes under the headline "Computer Languages Multiply, Pleasing Many - but Not all". The following qoute summarizes the column well:

Languages are proliferating in the computer industry these days, and software programmers couldn't be happier about the choices they have. For their bosses, though, it's often aggravating.

The article goes on to discuss the proliferation of languages and systems like Perl, Python, PHP, TCL, JavaScript (AJAX) and Ruby (on-Rails) and states that “these languages seem to come out of nowhere”. Now, of course, all of these languages have been around for many years, but the fact that they now have made it into the Wall Street Journal is important in that they start to be relevant for business people.

We blogged about this proliferation earlier and noted that “the more specialized a language is to a domain, the better it fits to solve problems for that domain. These niche languages trade off generality for efficiency in a domain and they are simply better and more efficient tools for that domain.” The  domains for the languages above happen to be web applications. As we have discussed here, complexity is reduced when the degrees of freedom is aligned with the problem domain.

But the article then takes a new twist on this phenomenon:

All of these new approaches to software also rankle the chief information officers of the world. Usually, an executive responsible for managing technology tries to limit the number of software (and hardware) systems that are in house, if only for simplicity’s sake. These days, though, programmers are likely to whine, beg and plead to be allowed to use the hot new language that everyone else seems to be using.

So, according to the article, CIOs want simplicity, but programmers want something to the contrary. How can we explain this perception that the desires of management and the desires of the programmers are in conflict even about simplicity?

Here’s what’s probably happening. Simplicity – or lack of entropy – is like the cold within a refrigerator. This is what the programmers like – the “cool” language (even though the article called them “hot”...) that reduces the complexity that the programmer sees locally. But just as a refrigerator is a net energy user and heat producer, from the manager’s point of view the total complexity may have increased: the additional languages raise many organizations issues: legacy, training, maintenance, testing, build procedures, and so on.

The challenge still remains to reconcile the systems and reach a better overall optimum.

Code and Contracts

To introduce myself, I joined Intentional Software as VP, General Counsel in January, 2003 after a career practicing business law in a large law firm.

Since then I have become intrigued by many interesting parallels that I see in problems that affect writing software code and problems that affect writing contracts. Technological innovations are steadily resolving more and more of these problems in the software domain, while the contract domain seems to remain mired in human piecework.

My fundamental approach has always been to maximize predictability of the future for my clients by minimizing uncertainties in each of their legal and business relationships. I believe a similar approach can be helpful in discussing some of the basic problems that affect both code and contracts.

I thought you might enjoy considering a few things about contracts and legalese that you may not have known, and judge how closely they compare to writing code.

Enforceability

I am learning that in order for code to be compiled and run, every literal in the code must be precisely written in accordance with rules of syntax and semantics of the programming language used. The same is true for contract language in order for a court to enforce a term or condition of a contract.

On the surface, just like writing precise code, writing clear contracts and following rules of syntax and semantics would seem to be relatively straight forward tasks. But as I am also learning, writing code is fraught with uncertainty and prone to human error. I know from experience that writing contracts is too.

Of course today there are compilers that enforce precision, and there are tools for testing and debugging code that reduce many other uncertainties in writing solid code. Similar compilers or tools do not exist for testing or debugging contracts, and the problem of reducing uncertainties in writing enforceable contracts remains unresolved by existing technology.

A contract author can reduce uncertainties in contracts at least to some degree by using objective standards to eliminate as many potential contract interpretation disputes as possible. For example a court can speedily enforce an objective standard for determining a breach or for triggering a right to terminate, such as “pay X$ on Y date” or “aggregate collected purchase price of products shipped (excluding returns, rebates, discounts, allowances and other credits, and excluding freight, insurance and other charges) less than X$ deposited by bank wire transfer in seller’s bank account number 12345 at XYZ Bank, Branch No. 38 in Bellevue, Washington, in any 365 day time period”. In cases like these where no material fact is in dispute (i.e. where the objective amount paid or deposited is not in dispute), you can end your uncertainties within 60 to 90 days after suit is filed by asking the court to enter a summary judgment.

In comparison, a court cannot speedily enforce subjective standards that you often see in contracts, such as “sales revenues less than X$ per year”. Uncertainties inherent in that example include whether “sales revenues” means the total (or net? and how is net calculated?) amount (of what?) invoiced, shipped, collected, deposited or something else, and whether “per year” means calendar year 1/1 to 12/31, any 12 calendar months, any 365 day period, or something else. Other typical subjective standards include: “material adverse change” (IBP v. Tyson Foods) and “misfeasance, malfeasance or insubordination”.

Even the meaning of a seemingly objective term like “derivative works” has been disputed in a court battle entitled Progress Software Corp. v. MySQL AB. Other examples of disputes over the meaning of many commonly used terms appear in a current lawsuit between Sprint Nextel and Nextel Partners. These include disputes as to whether “most recent unaffected public market stock price” excludes historical stock prices after merger speculation arose, and as to whether “willing buyer/willing seller” may properly ignore future risks in the wireless telecommunications industry.

Additional uncertainties arise from the fact that courts often interpret the same word differently when used in different contracts and in different factual circumstances. In cases like the MySQL and Nextel lawsuits where a material fact is in dispute (i.e. where the meaning of a subjective term is in dispute), uncertainties often continue for months or years until the trial and appeals process finally sputters to an end.

And worse, as every law student learns: “no contract can make an opera singer sing on key” – just as I expect you know there is no magic formula that will make a programmer write great code.

So even if your contract is written as objectively as possible, there is still no technology or practical way to make absolutely certain that a court will order the other party to perform its obligations in a timely manner to your own satisfaction.

Use Cases

Our resident geniuses tell me that well written code should cause a program to behave correctly in all use cases, and in special cases with minimal errors. A similar general requirement applies to well written contracts because they should minimize loopholes (error cases) too. Years ago a revered mentor and friend gave me an insightful quote by Judge Solomon:

“The legal draftsman must write for unidentified foe as well as known friend. He must write so that not only can a person reading in good faith understand but a person reading in bad faith cannot misunderstand.”

This all seems so simple.  But how can anyone possibly identify, much less implement, every single use case in a universe of potential use cases in a software project - or every single loophole in a universe of potential loopholes in a contract?

In software projects, the programmer needs to identify as many of the primary and special cases as possible and cover each of them specifically. The programmer also needs to identify as many categories of other potential unidentified special cases as possible and handle each of those categories in a more general way. Obviously such a subjective human process to avoid error cases is not capable of absolute certainty.

For contracts the writer also needs to identify as many categories of loopholes as possible, and eliminate each of them either specifically or in a general way.

My personal method is to think like a jailhouse lawyer, someone who has 30 years in prison to look for loopholes in whatever documents landed the person in the clink in the first place. But the problem of identifying and eliminating contract loopholes remains a subjective human process. We still have no technology or practical way to make absolutely certain that no one will be able to find a “get out of jail” loophole in our contracts.

Implementing Contracts

Similar to a program, a contract’s value depends primarily upon the extent to which it is useful to the contracting parties. In turn, usefulness depends upon how well the contract implements all of the terms and conditions necessary for timely enforcement of all of the intentions of all contracting parties. And logically, how well those terms and conditions are implemented in the contract surely depends in large part upon how thoroughly and clearly each party’s intentions are communicated to, and understood by, all contracting parties and their attorneys.

Unlike programs implemented in code, however, courts often allow contracts to be evidenced, construed and interpreted (implemented) not just by objective, clear and unambiguous words on the face of the contract itself. Courts also allow just about any other evidence the court deems relevant at the time of trial, with the benefit of 20/20 hindsight.

Depending on the facts of a particular court case, relevant evidence could include writings and oral statements made before, during and after the contract is formed, and actions and statements of the parties during performance of the contract and at the time of alleged breach or termination. Other variables could include things like the relative bargaining power, education or “sophistication” of the parties, “public policy” considerations and evolving societal pressures, all as seen in the eyes of the beholder.

Courts also impose requirements that each contract be negotiated “in good faith”, and be “fair” and “equitable” and not “unconscionable”, judged subjectively from many unpredictable and different points of view (again with 20/20 hindsight). These sorts of subjective “fairness” uncertainties are so pervasive, in fact, that the late Yale law professor Grant Gilmore even wrote a book about them aptly titled “The Death of Contract”, first printed in 1974. Buy it here. As professor Gilmore wrote, pp. 94 & 98 (10th ed. 1981):

“Indeed the decline and fall of the nineteenth century idea that tort liability is, or should be, based on negligence or other fault matches the decline and fall of nineteenth century consideration and contract theory…. The two stories are, of course, halves of the same whole and the same ‘explosion of liability’ has manifested itself, perhaps even more dramatically, on the tort side than on the contract side. … We are steeped in the idea that law is process, flux, change; our relativism admits no absolutes.”

Obviously it is extremely difficult if not impossible to predict or control what variable, subjective “facts and circumstances” and other considerations the court may, or may not, deem relevant “outside the four corners of a contract”.

And a court only brings an end to a dispute based on whatever evidence the court deems relevant. So, unlike programs implemented in code, you can never predict whether or not a court will interpret a contract fairly from your own point of view.

In conclusion, I’ve had some fun articulating a few of the interesting similarities I am discovering between code and contracts, and I hope these thoughts have been interesting for you as well.

Maximal Fun Programming

Mike Koss just wrote an insightful essay about one of his most fun experiences as a programmer. Mike has been around the block and has worked on products like Excel, Outlook, and Sharepoint at Microsoft. He tells a story about the time he incidentally built a domain specific language using XML into Sharepoint and used that to drive the implementation. Mike says:

Then, the real fun began - the fun of being able to wear two hats - and switching between these roles. On the one hand, I was thinking of the specific web site collaboration solution I wanted to build and imagining, if I had a domain specific language (in XML) to describe my particular application, what would I want it to include to give me the power and flexibility to realize my goal? Then, I would switch to language implementation developer, and add features to my language to meet that goal.

This approach turned out to be so useful that it ended up in the product as CAML. The CAML language also turned out to be used in a surprising way – as the specification language for the product. Mike again:

Another unintended benefit was that the CAML language became an interface between people in the group. Our program managers (at Microsoft, generally the people tasked with the end-user application design) now had a specific way of asking for features from developers – they could ask for extensions to the CAML language to fill an unmet need.

I think this example shows that we end up using and building Domain Specific Languages (DSLs) more often than we realize. We might not think of them as formal languages, instead calling the technique  data driven programming or the use of meta data. In fact we might not call it anything fancy at all, just thinking we are using good design techniques to keep policies and features compact, local and intentional so that they are easy to change and maintain.

I will not give away all of Mike’s story – go read his essay here.