February 2009

Deliver or die!

I started writing this post a few weeks ago and since then been in several conversations around the same area, so thought I’d get on an finish it:)

What is the key focus of agile practices ?

To me, it is Delivery of working software.

What do we mean by “delivery” ?

Delivery is software working in production. Even stronger, software that is being used in production.

What does “working” mean ?

This may depend on the currency you have for measuring success. Usually it means improving the bottom line of the company. It might be indirect such as generating interest for a website or simply getting a product delivered at all.

My definition of “Lean” may not be entirely accurate (I’m not an expert) but from my understanding, taking a lean approach, writing the code is only part of the story.

Lean tells us that there is no point in having a backlog of artifacts in the factory if we can’t get them to the customer. We need a good distribution system so that artifacts are pulled down the pipeline as quickly as possible, right from where they are consumed.

For software this means the production environment. Really the production environment, not staging or the ci environment or a dev box.

Setting up the distribution pipeline is as important as any other part of the project. It needs to be automated, reliable and responsive (i.e. as soon as a new feature is required it can be sucked into production as soon as its completed)

Once your delivery pipeline is in place everything else becomes smooth. People stop worrying that they are not going to receive new features quickly and so they feel more able to focus on what the need right now, in smaller chunks which means the delivery system flows more smoothly and the features are produced in a more responsive way.

Share

agile
anecdotes
thoughtblog

Comments Off

Permalink

CSS Tips and tricks…

I was just working with Tom on trying to get some CSS to work properly for a project he’s working on.

The problem was divs flowing outside their parents. I was reminded of some pages I used to have up which demonstrate various div layout issues and show some fixes. I have now added them back into this site and they are here.

They key point for quite a few of the solutions there and hopefully for Toms’ solution (except its not quite finished yet) was that sometimes if you have some floats knowing around, it can be useful to have another, empty div with a style set to clear:both; this forces the floating to stop and makes the parent div expand (or should do anyway).

Oh yeah, an important resource that helped me to solve these problems was Eric Meyer’s site.

Share

thoughtblog
web
website

Comments (2)

Permalink

The future of frameworks

I have been working recently on a greenfield project, at the start of coding. It is a great place to be, you get to choose your weapons and start with a clean slate.

It also focuses the mind on choice of frameworks, wether to roll your own, package structure definition, build, etc, etc. Its interesting that there is still no standard stack that everyone just uses without question or arguments (although frameworks like Spring do tend to dominate the conversation).

We have been using a framework called Restlet as we wanted to expose a pure HTTP api to part of our application. As it turns out, we are spending quite a bit of time “restling” with restlet and have ended up writing quite a bit of framework code inside our application, specifically to isolate ourselves from the implementation of the restlet code! The obvious question here is: “What is the framework doing for us ?”

We are also doing the same thing in another part of the application which is using Struts. Although we use some of the features of struts, we want to keep aspects of the framework in our own codebase, such as validation.

Ok, so where is all this leading ?

It occured to me that whatever frameworks you use, you will end up with some amount of framework code within your own codebase, as a kind of “adapter” to the local constraints and conditions of the domain you are in.

What if ? frameworks were more about providing a platform to build your own framework, rather than trying to do everything for you ?

The Commons HttpClient library is an example; it provides some simple encapsulations for you to use how you will. Infact, the commons libraries in general offer something along these lines.

As I write this I realise I may just be talking about “libraries” of code rather than frameworks. However, the point is that the framework should have a “fuzzy” outer layer which you then adapt to your specific codebase, but should also provide you with useful set of encapsulations which save you repeatedly writing the same classes (e.g. something like HttpStatusCode).

To summarise:

In the future, the frameworks that will be most widespread are those that provide a framework for building your own framework.

In some ways this is already happening with Spring. We are, for example, using the Spring JDBC components independantly of the other aspects of the framework, and I think that this ability to pick and choose features contributes to the popularity and success of Spring.

Share

anecdotes
frameworks
thoughtblog

Comments (2)

Permalink

URI not URL (it is deprecated)

I have been asked about this a few times, I had learned from Jim that it had been deprecated but thought it would be useful to provide the documentation to demonstrate it.

This apache doc gives a good summary :
http://labs.apache.org/webarch/uri/rfc/rfc3986.html#URLvsURN

Which points you to :
http://www.ietf.org/rfc/rfc3305.txt

Basically URL is a subset of URI which

… in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network “location”)

.

Share

http
web

Comments Off

Permalink