The Ancient Art of Programming

On Wednesday afternoon at the Cortina Software Architecture Workshop, Erik “it depends” Dörnenburg started a session entitled Developer Productivity. We’re all looking for ways to increase the productivity, but what works and what doesn’t?

Frameworks

Everyone present at the session agreed that frameworks can offer a gain in productivity. A good framework allows one to focus on writing business logic, instead of writing plumbing code. This improves developer efficiency.

However, a bad framework can decrease productivity. If a framework does not offer the required functionality, every developer will create their own solution. If it forces a certain way of working which is impractical, workarounds will be created. Sometimes, developers are forced to use a framework, because it was developed by the project architect, or because it is part of the Infallible Reference Architecture. While a reference architecture can help less experienced developers; it can frustrate the more experienced.

In conclusion: a good framework helps you. If a framework does not help you, stop using it¹.

Capturing Abstractions and Intentions

If a tool can capture a set of concepts and build an abstraction over it, it can increase productivity. Also, productivity can increase if a tool can capture out your intentions, if it “knows what you want”.

An interesting example put forth in the session was that of GUI builders. GUIs mostly consist of labels with fields that are tied to variables. If the variable is a string, a edit box should be shown; if it is a boolean, a checkbox. One would imagine that GUI builders gain a lot by adding an abstraction which captures this combination. In practice, few GUI builders have it. Perhaps this isn’t such a great abstraction after all, and the Law of Leaky Abstractions applies here.

1 - Political and business decisions complicate things.

On Thursday morning at the Cortina Software Architecture Workshop, Erik Dörnenburg held a session entitled Annotations/Attributes: How do they help us? Since I’ve written about these types of class metadata before, I was very interested in this session. Especially since every JSR that comes out of the JCP nowadays seems to add an annotation or two.

Configuration

One of the questions we covered during this talk was whether it is OK to use class metadata for configuration, as for instance a Spring bean definition file is used today. The obvious downside to this approach is that the class requires a recompilation for a configuration change. Because a class may undergo many configuration changes as it goes through its life-cycle from developer environment through testing environment to the live environment, you may need to recompile it quite often!

Martin Fowler pointed out that it is quite alright to use the metadata for configuration defaults, as long as you can override it using some other configuration mechanism. I agree with him on that one. However, it might be a bit unclear how a class is configured exactly in a particular environment: is the class metadata used or the XML configuration file?

Entity Mapping

Another usage of metadata we covered was that of Entity Mappings. Using EJB 3, or Hibernate with Annotations or XDoclet, one can define the entity mapping using metadata. I imagine .NET ORM frameworks like NHibernate have similar functionality.

The question that arises from this is: Is a entity with metadata still a POJO? The consensus in the session was that that it isn’t, since it is tied to a specific framework. This is especially true in .NET, with its strict reference resolving mechanism¹.

Domain Specific Language

The final usage was suggested by Mats Helander. He suggested using class metadata for class intent, as a Domain-Specific Language of some sorts. If I remember correctly, the idea was to define one’s own metadata, and to map that metadata to the frameworks you use. The advantage over the previous approach is obvious: you are not tying yourself to a particular framework anymore, you are expressing the semantics of your classes, and map that to the frameworks you use. Obviously, the metadata could also be used for other purposes, such as DSL tools.

I find this way of using metadata really interesting, and I’m looking forward to trying it out in a project some time.

Update 2006-02-14: Erik is going to speak about Domain Annotations at the Software Practice Advancement Conference this March. Looks interesting!

1 - In .NET, if you use a attributed class, you must also add a reference to the assembly containing the attributes, otherwise you get a compilation error. In Java, with looser reference resolving, this does not appear to be the case: the class is simply not annotated if it cannot find the annotations at runtime.

One of the sessions in the Cortina Software Architecture Workshop was entitled What’s so hard about SOA? In this session, Dan North tried to find out whether there is any substance behind the hype that is SOA. During this session, I had an epiphany when Dan explained the perfect SOA metaphor. Basically, it goes something like this:

Imagine you’re an employee at a large company, and you would like to take a holiday. You fill in the standard holiday form with your name, department, employee number, signature of your boss, holiday date and other stuff. You will probably fill in only half the fields, because the other fields don’t affect you, or you don’t have the information necessary to fill them in. You send this form to the Human Resource department, who take the request into consideration.

After a couple of days, you’re probably wondering whether your holiday has come through. So you call the HR department, and ask them how things are progressing. They tell you that they are working on it right now: the request has been granted. They want to know whether you want to use the company’s travel department for the trip you have planned during the holiday; you tell them no since you’ve made your own arrangements. You put down the phone, and wonder what Hawaiian shirt to wear in Barbados.

For you, the thought of your upcoming holiday made it a nice experience. For the HR department, your form resulted in a lot of work: all in a day’s job. If your worked at the HR department yourself, processing your own form, you probably had both experiences, even though it is just one form you worked on.

Now here’s the analogy: a Department in a company stands for a Service: the HR department in the example could be seen as a Holiday Service. Employees within a department are components or classes. You requesting your holiday stands for a class that uses the Holiday Service. To make the request, you follow the Service Contract: the holiday request form. The specific form you filled in for your holiday is a Service Message. You submitting the form to the HR department is an Asynchronous Request. You calling them is a Synchronous Request. Both types of request have their value, depending on the context.

The great thing about this analogy is that you can expand it further. For instance, you could add a little post-it note to the form, telling the HR department that you would like to be called back when they have more questions. Since the post-it isn’t part of the standard form, the HR department could ignore it all together. If a lot of post-its are added to form, they will probably create a new form that adds fields for all the info people have been putting in the notes: a new contract. This could mean that the old forms aren’t valid anymore, but HR will probably still accept them.

I love analogies like these, because they show that SOA shouldn’t be so hard. It’s just a form for a holiday.

I have just returned from Cortina d’Ampezzo, Italy, where I attended the Software Architecture Workshop. The idea behind this workshop is basically to get a bunch of software architects/developers together in a room, and let them talk for an hour about stuff¹ in an environment in which ideas and opinions can circulate freely. This year’s edition was hosted by Andrea Provaglio, who did an excellent job.

It was an amazing experience. All attendees were extremely knowledgeable, smart, and interesting to talk (and listen) to. My head is still spinning from the experience, and it will take a few days to write up all of the notes I made. In addition, I made some interesting new friends there, who I hope to see again soon.

Paul has posted some nice pictures, which show that the surroundings were quite inspiring as well.

Stuff is a registered trademark in the UK and other countries, exclusively licensed through Dan North.