I wonder who thought this up.  I've seen what happens when developers try to write reusable code.  Most of the time they end up with a maintenance nightmare.

The first problem I've seen is the "framework" problem.  The customer needs to write 5 enterprise web applications, so the architect talks them into building their applications on a "framework".  By framework, I mean an underlying, shared services layer like a printing services layer or a communication services layer.  The problem with this approach is that your 5 applications become welded to the underlying services layer, and now instead of being able to maintain each application at its own pace, you have to maintain them all together.  If you make a change to one corner of the environment you have to test and potentially upgrade the entire set.

The second problem I've seen is the classic big ball of mud.  The architect states that copying code is a lazy hack, and therefore we will write code once and reuse it everywhere.  They write a simple little java batch job, but because of their policy, the project now has 15 external dependencies.  And, if you look at each of those external dependencies, they each have multiple external dependencies of their own.  Now, when you try to load the the project in Eclipse you have to load half the enterprise in order to get the code to compile.

This is a surprisingly common problem in legacy code, and it's the reason you hear a lot about loose coupling these days.  But, do we really want reusable code?  I don't think so.  I think what we are after is the ability to create replaceable code in a way that is repeatable.

Let's explore the first concept.  Replaceable code is by nature reusable.  If I were going to write a communications service I should be able to swap it out for another communication service and still be able to use the one I have on another system.  Web services tries to solve this problem by hiding implementations behind a clearly defined interface.  What does it look like at the function, class or package level?  log4j is a good example of a library that should be easily replaceable but is often surprising difficult.  SLF4J is an improved logging framework that facilitates better replace-ability.  The key difference here is that log4j was created to provide easy logging whereas SLF4J was created to provide easy logging and replace-ability.  In other words, replace-ability was a design goal for SLF4J, whereas re-usability was probably the key driver behind log4j.

So, if reusable code can get you into trouble in ways you don't expect, can replaceable code do the same thing?  Sure it can.  Imagine a world where machinists all made their own screws.  Of course, this was the case in the early days of replaceable parts, and it was only when screws and drills became standardized that the situation improved.

Do customers care about replace-ability?  Customers don't care about a lot of the things we do as software designers and developers; they just want working software.  But, we should care about it.  It's easy to stand up in front of your development team and say code reuse will be one of your design goals.  It's another thing entirely to say code replace-ability will be one too.  Think about it.

How do we achieve repeatable assembly in software development?  Domain specific languages are programming languages that sit atop a framework and use the language of the problem domain.  I won't go into all the details (Martin does a much better job than I ever could), but for our discussion the important point is that DSL's can be used to generate code.  Code generation went out of fashion awhile back, but there have been renewed interest lately which I think is very encouraging.

Let's use our imaginations a bit here.  Imagine you are in an auto junkyard and your task is to assemble an automobile.  It's quite likely you could find enough parts and bolt them all together, but it's unlikely your creation would work very well, if at all.  Software frameworks represent the parts inventory; they are the things you can assemble to make a working application if you know what you are doing.  The problem is that even though we have the same goal, the car you assemble will likely be wildly different from the one I assemble.  I believe the answer lies in what I call Domain Specific Contracts.

Before we go any further, I want talk about this phrase.  I toyed with the idea of calling these things Domain Specific Templates since the term "template" is analogous to the term "die" from tool and die making.  I felt the term "Domain Specific Dies" reflected exactly what I was after in this design, but I wasn't sure how well that phrase would work in the community.  I did get a hit on the the "template" version of the phrase so I was a little disappointed and a little hesitant to overload their use of the phrase.  Then I thought Domain Specific Schema Templates was a better term, but this suggests you are making templates for creating schemas, and that's not quite what I'm after.  Finally, I settled on Domain Specific Contracts because I liked the interactive nature of the term and the way it is suggestive of "behaviors" as they are defined in Erlang where objects have expectations of each other in order to work together.  I'm not the first to use the phrase Domain Specific Contracts either, since Chan and Paige used the phrase in the title of their paper which I haven't read yet. (I have read it since this original post, and they are bang on.)

The reason I am telling you all this is because I wanted to give you some sense of what I was after and to let you know the name is a bit problematic.  When paradigms are about to shift, as I believe they are in software development, it is common to see ideas like this expressed in various forms under various names.  It's only after the shift that these things settle down.  We really are running out of words in this industry.

Now imagine that you are working in your favorite IDE.  Your IDE is "framework aware" such as when you are using the Java EE edition of Eclipse.  IDE's often have graphical editing frameworks that allow you to drag and drop objects into the editor pane, and the IDE will generate the corresponding code for the object.  The goal of these generators is to improve productivity and standardize the code we produce; all good things and we're heading in the right direction.  Let's take this a step further.  Let's say you decide to drag a console object out of the namespace browser and the edge or boundary between the browser pane and the editor pane detects the drag event.  This causes the IDE to load up a set of DSC's and prompt you to chose which one you want to apply to the object.  Let's say you want to apply a passive monitoring DSC to the object.  Now, when you finish selecting the template and submit your choice to the IDE the "drop" operation creates the graphical object in the editor pane and "punches out" the object code with the behaviors specified in DSC.  You get a console object that expects to receive event messages from components that it will display.  Alternatively, if you had chosen an active monitoring DSC the object would have been generated with not only the monitoring behaviors but the ability to send start and stop messages to the event generators.

Stay with me.  Now let's say you wish to add an event generator to your application.  You drag one across the editor pane and because you already have a console DSC in place (active, overlaying) the event generator gets the send event behavior, and the IDE prompts you to chose additional DSC's like the ability to read hardware sensors.  When you submit your selections, the object appears in the graphical editor and the code is generated such that the console and the event generator can now talk to each other.  The event generator would have the, as yet unfulfilled, contract to read hardware sensors, which is a domain problem that can be added later, and the ability to talk to the console object we already created.

What we have created here are two interchangable parts for a sofware application.  If we were to take another application built on the same framework with the same set of DSC's our two components would work perfectly there without modification.  Our console might show ouput in red (a domain specific detail) whereas their console might show output in blue, but our console could display their event generator data without modification.  Our event generator might monitor temperature (again, a domain specific detail) whereas their event generator might monitor battery levels, but our event generator could talk to their console, again, without modification.

Let's step back to the design phase where we are planning our architecture.  Now instead of simply choosing a framework for our application we also chose a set of DSC's that we want to apply.  The beauty here is that we can give this design to two different groups of developers and they will produce identical sets of code with interchangeable parts.  The two applications would differ as domain specific details are added (blue output vs red output, temperature monitor vs battery monitor), but the essential structure of the applications would be the same.

Domain Specific Contracts become part of our software design.

Let's come at it from the reverse.  When you approach the finished application, if you understand the DSC's used to construct the application you will have a very good idea of what to expect when you start browsing through the source code.  We know what our design expects from the implementation.  In other words, our design "pulls" the implementation out of the framework based on the contracts we have applied.  We don't have to worry about all the parts of the framework we left out of our design as long as our contracts are in place.

Let's say we want to "mod" our application much the same way we like to modify our automobiles.  If we make a change to the event generator such that it can receive start-up and shutdown commands but the DSC we chose didn't specify that behavior our IDE can warn us that we are deviating from the original design.  The correct behavior would be to chose the new DSC, punch out a new event generator, add our domain specific details, and test it out.  What if a specific DSC doesn't have the behavior we want.  We can go back and make a new DSC or modify the one we have, just as a tool and die maker would.  This way the design changes we make are not "lost" in the code but are available for the next team to use.

Code generating templates are nothing new, but what's different about this idea is that the domain specific contract stays in place.  Code templates, the way they are used today, are discarded once they are used.  Domain Specific Contracts stay active. When I save a project, the set of DSC's I have applied stay with the project.  When you move the code between repositories, you move the set of applicable DSC's as well.

Another way this design differs from current code generating templates is that only the behaviors you want are generated.  A console might have the ability to receive events, start and stop generators, and send alerts.  Code generating templates typically give you all or nothing, and you are forced to "mill" or chop off those behaviors you don't want.  Domain Specific Contracts would work together to give you only what you need.

As Martin points out in his excellent book on Domain Specific Languages, this area of software design is new and changing rapidly.  I certainly don't claim to have completed an exhaustive survey of the field, but I hope the ideas presented in this post will help provide the catalytic zap, if you will, that I believe we need to provide more repeatable design and delivery of software applications.  The task remains now to think about how we might create Domain Specific Contracts. What do they look like, how do they fit together, how can they be applied?  In other words, we need to start thinking like software tool and die makers, and that sounds like a lot of fun.

A large bank in the US declared $4Billion profit last quarter.  What did they say?  "Oh, the housing market has turned around."  Bullshit.  The banks cannot be allowed to declare that kind of profit when everyone is going broke.  The top 5 banks in Canada declare on average $20Billion profit every year.  Where did last year's profits go?  Where will this year's go?

It's time to sort this out.

You create a mobile application, where if you like the music you are listening to, the artist gets, let's say, 5 cents.  That's a good price.  No, I don't have to pay to listen to your music, but if I like it I will give you money.  NO ADVERTISING.  Get that?  You play our music on the internet, and I listen to it.  If I like what I hear, I touch a control, the song goes on my playlist, and the artist gets 5 cents.  I can manage my playlists, any way I want.

That'll do it.

.ps The bank that transfers the money holds it for 2 days.  No more, no less.  If, at any time, the value of the money to be paid out is more than the money on hand, the bank goes broke.  The bank that can stay afloat, wins.  Next.

Travel by car involves a large number of stops that are small in duration.  As for the mode that has the largest total amount of waiting, I would estimate it is air.  I wonder if we were still doing air travel by dirigible would we be required to strap ourselves down in seats and not move for hour after hour.  On the rail trip that I made as a child we certainly didn't sit still for long.

How would you design a transportation system without waiting?  Well, for air I would try to minimize the time spent in airports.  Think of the stages of air travel.  You travel to the airport.  You travel to the gate.  You board the plane.  Time spent waiting happens mostly before the gate stage.  Imagine if you could proceed directly to the plane without waiting.  How might that be accomplished?  What if air schedules were like bus schedules, and planes ran every hour?  What if you were not allowed to check your bags but were allowed to bring it on board the aircraft with you?  What if there was room to walk around in the aircraft.  You might stow your bags, stroll over to the restaurant, have a nice meal, walk the promenade, collect your bags, and debark?  Perhaps you might have a small desk in a private area in which to work.  I would choose dirigible travel over airplane travel every time if it involved no waiting.

What are the prerequisites for such a system?

I don't quite remember when I started my career in computers.  I recall a friend from High School, whose Dad was a teacher, brought home a Macintosh (or an Apple, whatever they were called back then).  I had never seen anything like it in any of the books or magazines I had read.  I just had to have a piece of that machine so I could start learning how it worked.  I asked him for a diskette.  He had a box of those blank hard-shelled diskettes that came with it, and he gave me one.  That was the beginning.  Somewhere around 1984, I think.

I started learning about PC's right after that.  By the time I got my first IT job it was 1989.  I got a job, part time, in the control room at the local liquor distributing organization.  I ran the batch jobs and printed off the picking lists for the warehouse.  I got an offer for a full time computer operator job in 1990 at a large financial services company.  I started out mounting tapes and running an ancient batch system in 144vse.  I learned print operations, and finally I moved to mainframe console operations.

I already had my first degree in Canadian Studies by that time.  I decided I wanted to go back to University to learn more about the theory behind all this.  I was already a Systems Analyst when I started my second degree in Business Computing.  It was a 4 year program, but I did the 3 year version.  I had no interest in the Business Administration courses.

Around that time I was handed the job of automating the data center.  I am a child of the automation age -- lights out operations.  It can't be done, by the way.  You can't work with the lights out.  That was a marketing ploy.  However, automation did do a lot of good things for operations. It was, essentially, the beginnings of system integration.

I started off with message suppression and one button IPL and shutdown.  Once I got that down I went to work on tying all the backups and batch systems together.  That's when things started to really get creative.  I discovered there was a way to talk to the alphanumeric pagers the support teams where carrying.  So, I wrote a system that dialed into the paging company mini-computer and started sending error messages from the mainframe to the support teams.  Then I thought, wouldn't it be cool to open the trouble tickets as well.  I wrote another system to take the errors from the mainframe and assign tickets to the appropriate support groups. When an error happened on the mainframe, during batch or whenever, my system would open a trouble ticket and page the appropriate support person. You could even walk up to any console in the control room and type, "page operations time to start printing", and the message would appear on the operations pager. It was a beautiful thing. None of the big vendors had these kinds of integrated systems to offer at that time.  This was the early 90's.  The framework was built in Prolog, and my code was in REXX.

I got outsourced in 1995.  Around that time I started learning about more complex systems.  Games.  Artificial intelligence.  Flight simulators.  I tought myself Python by writing a small AI for a combat flight simulator.  It was a simple little thing.  Finite state machine. That's not hard to do. The real challenge is how to be in two states at once.  Sub-states.

I don't recall when I started playing around with linux.  Slackware was one of my first, then Gentoo for a long time.  I learned about communities by watching that one implode.

Around 2003 I fell into performance testing.  When I think about it this was a natural progression for someone born in automation and integration.  I was really good at it.  The big, ugly vendors would write these messed up applications, and I would come along and get the engine running smooth.  I liked it.  I learned a lot about enterprise software.  Somewhere around 2005 I wrote a full performance testing extension for RUP using Rational Method Composer.  I gave it to the Rational team, but I don't think it ever made it into the offering.  RUP is dead anyway, but it was a beautiful thing.

This is a bit of a ramble, I know.  The thing is, when you are making these things you get lost in the joys of craftsmanship.  It's only when you look back on it all that you see what you've been a part of: the early years of computers and software.  Fun stuff.

My presentation focused on Formula One race cars and how performance testing software was a lot like testing a Formula One car.  Those cars are state-of-the-art when it comes to wheeled vehicle design, and they are also hand crafted.  It occurred to me that craftsmanship is a desirable thing.  Would you rather have a car that comes off an automated assembly line or would you rather have a hand-crafted one?  Software and automobiles are not the same class of objects.   Ford invented the assembly line in order to produce large numbers of dependable automobiles at a reasonable cost.  The assembly line churns out copy after copy of a car design, and they are all identical.  With software we make it once and copy it over and over.  In other words, we have no need to create the software from scratch over and over again.  Once we've made it, we don't have to make it again.  It's a different beast.

With automation, everything we make is an exact copy of the one we made before.  With craftsmanship, everything we make is different from the one we made before.  There will be similarities, but they will not be identical.  With automobiles, all the dependency is on the designer.  A good designer can turn out an automobile that is a work of art or a total lemon.  We can start out with a good design and end up with a total lemon if our assembly process is flawed.  Herein lies the key to successful software creation.  We need to begin with a good design and marry it to a repeatable assembly process.

I recall watching a news clip of the pilot of one of the joint strike fighter competitors right after he stepped out of the cockpit after the first test flight.  He said, "It flew just like it did in the simulator."  That statement struck me.  They designed the plane using Computer Aided Design software, and then they built a simulator to test the design before they even started on the prototype.  Imagine if we could do that with software.

• All decisions we make must be in the best interests of Canada.
• All debate will occur in public, and only in public.
• Debate on a decision will continue until everyone agrees.

Let's examine the principles.  First, acting in the best interest of Canada makes perfect sense.  This is our home, and we should look after it.

The second principle comes from some thinking I've been doing about the art of speech.  (I'll blog about that later.)  In the art of speech there can be only one kind of debate, and that is friendly debate.  Debate that occurs behind closed doors smacks of collusion or espionage or gossip and is unacceptable in an enlightened community.

The third principle has the effect of forcing us to really take our time with decisions.  Debate on a decision can go on for years, and in fact, some debates may never end.  I'm making a value judgement here in saying that taking our time with decisions that affect every part of our community is a good thing.

Would that be enough?  Would you join?

At this point store owners may say, "Ya know what?  Handling coins is expensive and time consuming, and we would rather not do that anymore.  From now on we only accept plastic."  Not a problem, say we, the people, we like only having to carry a small plastic card around with us.  Heck, even the coin operated devices will be "swipeable/chipable" soon.  Get rid of all the money!  Our lives will be simpler.  Prosperity for everyone!

Hm...sounds wonderful.  What could possibly go wrong?  Let's say that the banks and the insurance companies merge.  They're doing that now, so it's not much of a stretch.  (Gambling and money lending have always gone hand in hand.)  Now let's say that these new "credit authorities" discover that injuries from skateboards are costing them lots of money in insurance claims.  They could say, stop using skateboards, but people would just laugh at them.  They could try to make skateboards illegal, wait, we did that once already, didn't we?  They could make all the skateboarders wear helmets and wrap themselves in foam, yeah, that'll work!

But, what if you couldn't buy a skateboard?  What if your little plastic card wouldn't let you buy something that was unsafe, that was undesirable?  If you have money in your hands, you can do whatever you like with it.  If all you have is plastic, you can do only what the computer at the bank will let you do.  Think about it.