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.

Agile methods are designed to cope with changing or vague requirements, and posit that big design up-front (BDUF) is wasteful, as the shifting requirements will make the design obsolete. Too often though, analysis and requirements gathering are lumped together with BDUF and the baby gets thrown out with the bathwater.

Certain requirements can be captured early, and indeed, should be captured as early as possible. Ironically, these are often the requirements that receive the least attention – the so-called non-functional requirements. These include such things as low maintenance, responsiveness, reliability, ease of upgrade etc. Sometimes the non-functional requirements can turn out to be the most important ones. For example, if a project is designed to replace an existing system that is always breaking, then the most important requirement from the point of view of the CTO / key sponsor may be that it is easy and cheap to maintain. Problem is, sometimes the non-functional requirements are so obvious to the customer that they forget to tell the delivery team. This is what requirements analysis aims to address.

Finally, on the subject of changing requirements, how many projects really start out as stock trading applications and turn into an air traffic control system?

Its all about differentiating the real requirements from the (to the business) incidental details.

For tonight’s XtC:

• Short methods
• Classes with personality – do one job well
• Minimise duplication
• Clearly express intent
• Test algorithms not implementation
• Code to interfaces
• Law of Demeter / Tell Don’t Ask
• Methods that return values should be idempotent
• Demarcate functional individuality with interfaces
• Understand the big picture – what problem are you trying to solve?

View image

At the risk of appearing to backpedal I’m going to point at Tim’s response to my ‘project death’ post, and then claim that what he said is what I meant 🙂

Project cancellation is just one manifestation of reality impinging itself on a project, albeit an extreme one. Reality biting is the generalisation of the specific example I was using.

Definitely an improvement, thanks Tim.

This idea is worth pursuing. Where do we go from here?

FingerWorks make what looks like the ultimate in geek input devices.