At last: FreeBSD announces Java support.

My favourite OS officially supports my primary software language. Woohoo.

Put more correctly, why do we use agile methods? Why do we use any methodology? What is the purpose of RUP, XP or Waterfall? Seems to me that the ultimate purpose for using any form of process is twofold.

• To maximise production of value while minimising waste.
• To minimise variation and increase repeatability.

In agile terms, ‘production of value’ could be translated as velocity, usually measured as ideal days per actual days. This is the value that tells you how efficiently you are delivering functionality in terms of developer productivity. Any activity that occurs that doesn’t produce value must be producing waste.

Minimising variation essentially boils down to trying to reduce the effect of random chance and unforseen circumstances on the outcome of the project, and increasing the accuracy of estimation and planning.

Seems to me that agile methods like XP tend to emphasise the first point, while high-ceremony methods like waterfall tend to focus more on the second one. Interesting.

Ask only this of every action, tool, process, event, technology or change on a project: How much does it increase velocity?

Had a very interesting conversation today with Tim where he recounted a disussion he had with Joe about persistence.

The gist of their discussion as I understood it was:

-Why do we use databases?
-To store data.
-No, why do we really use databases?
-To produce reports.
-Yes.

Its a very attractive idea. Much of the complexity (ie. Object-Relational mismatch) of enterprise applications stems from a need to run reports on the data. But are we as an industry guilty of confusing our need to have durable data with our need to run reports on that data?

Getting Agile for a moment, what if we assumed we don’t need a DB (as opposed to most projects, which pretty much from day 1 assume they do need one). What if we also assumed that persistence was easy, which is essentially what projects like Prevayler have already demonstrated.

Dipping briefly into history, Smalltalk essentially did have free persistence, almost 10 years ago. Smalltalk is image-based, where your classes and objects (and the runtime classes and objects) are all part of the ‘image’, which could be saved and retrieved at will. Products like Gemstone supplied the robustness and high-availability needed by enterprise applications.

Back to the story. Assuming that we had no database, and that our objects were all durable (meaning they outlived instances of the JVM), how would that affect the development of the application? For a start some method of reaching all our objects would be required, so the object graph would need to be navigable from some root starting point. Nothing a map or list couldn’t solve.

Serialization is one obvious means to achieve object durability, and is really all Prevayler does under the hype. This does have the drawback of breaking if you add or remove fields from classes, but there are ways to solve it. Simplest solution is probably to extract the class into an interface, and provide a mechanism for migrating the implementations as they are deserialized. Compared with the effort of changing a database schema once in production you are still winning big time.

Allowing ourselves to wear the Pragmatic hat instead of the Agile one for a moment, we’d probably realise that persistence isn’t totally free, and that some means of ensuring object consistency would be needed, so that things that needed to happen together or not at all could be handled, but that is complexity that can be delegated behind a facade and doesn’t need to clutter the plain old object model. ‘Runnable’ looks like a reasonable starting point template for how to encapsulate a single transaction.

Of course, sooner or later a requirement for reports will be raised. Now we need a database. So we need to migrate all our objects into it and throw away our nice simple persistence in favour of a complex O-R layer right? No! We just put into the database the data needed for the report. Job done.

There are whole areas of thought yet to be considered, such as updates, ad-hoc reporting, distribution, messaging etc. but I really do like the idea of making the database just another facet of the system, rather than the crushing behemoth it seems to turn into on many projects.

Writing this entry on my new Fingerworks Touchstream keyboard. This thing rocks! Its slow going at the moment, partly due to the sheer wierdness of typing on one large flat surface, and partly because I went with the Dvorak version and am still learning the layout. The mouse controls and shortcut gestures are brilliant though. Cut and paste still makes me grin every time.

A few weeks ago I asked my colleague Paul Hammant about GUID generation in java, specifically whether there were any open-source utilities to do it. He told me about a pair of little known classes called java.rmi.server.UID and java.rmi.dgc.VMID.

The UID class can generate identifiers that are unique over time within a JVM. The VMID class is even cooler – it provides uniqueness across ALL JVM’s. Why a class as generally useful as this is relegated to java’s distributed garbage collection package escapes me.

For the detail heads, UID consists of a unique number based on a hashcode, system time and a counter, and a VMID contains a UID and adds a SHA hash based on IP address.

Cool.