lixo.org

You’re a consultant. You got sent to this new project, and it has been around for quite a while, and lots of bright and not-so-bright people worked on it over the past few years. Lots of functionality in it, they say, and even though the project has been wildly successful in the business eyes, do you have any idea regarding what to expect from the codebase?

First, you check everything out from the insanely bad SCM tool, to find out your favourite IDE won’t have enough RAM to build the thing, and you’ll have to use something else. You also find out that most tools can’t help you anymore, because they die a horrible death when trying to make sense of all that code.

You try and follow Michael Feather’s brilliant Working Effectively with Legacy Code (PDF link), and manage to isolate a tiny bit of functionality, test it and make sure you can fix the behaviour properly. That gets you trapped in a maze of circular dependencies with some other 30 other packages.

Your vision gets blurry, and you go out looking for something sensible to do, like searching for pictures of screaming trapped babies.

But there’s more. The build is so complex Ant didn’t cut it, and using something built in-house was the best way. But you don’t want to mess with that yet, because you don’t know what else could break. In fact, breathing near some parts of the code could make them break. And it takes time to know it, cause it takes half a day to get feedback from something you committed by the continuous integration machine.

You yearn the days when Find Usages was one of the most valuable keyboard shortcuts in your IDE. When using one O/R mapper was already troublesome enough - instead of the handful you have now.

If you excuse me, I’ll go look at some more pictures of screaming babies.

Despite all the XML abuse going around these days, there are is a small, but growing, number of web service consuming applications out there, and one very neat app I found is FlickrGraph (see my Flickr profile in it).

FlickrGraph wouldn’t at all be possible without the Flickr API, which exposes many of the funcionalities in Flickr as REST, SOAP or XML-RPC calls to any developer interested in using them.

This is what Jeff Bezos points out in his Web 2.0 talk:

Web 2.0, from where I stand, is about making the internet useful for computers.

Blogs with RDF/RSS/Atom-based aggregation were only a very tiny first step to making content and services more widely available, and now everytime I think of a useful service on the web, I end up sketching out its API first, figure out a few interesting uses for it, and then decide if it’s worth or not implementing.

If you look at Flickr’s insane popularity rise, there are definitely a few lessons to learn about a great web application, and providing an API is certainly one of them. It’s an incredibly dense app, even with the apparent simplicity, so I’m sure there’s a lot more.

Just finished listening through the podcast of this interview with Alistair Cockburn over at ITConversations (approx 15 mins), a few months old now, but still well worth it if you’re wondering, like I was, how the whole agile development buzz really came from.

It turns out that my favourite quote from this interview wasn’t even related to agile development, but to ’software engineering’:

In 1968 there was this NATO conference on software engineering. And when you read the preface to that (…) it says, “We wanted to come up with a provocative term, and so we chose this term software engineering” as a provocative term. That was a big shock to me when I read it because I think, like most people, they assumed that somebody had said… there was reason to believe that software development is a branch of engineering, but, in fact, what these people were saying is, “We don’t like the state that software development is, so we will throw out this word “engineering” and suggest that it should be like engineering and see what goes from there.”

Well, having a bit too much time on my hands, I actually looked it up - the 1968 NATO Software Engineering Conference report is a very interesting read, indeed. A particularly nice quote is from Edsger Dijkstra himself:

The dissemination of knowledge is of obvious value - the massive dissemination of error-loaded software is frightening.

Followed by this gem:

There was a general agreement that ’software engineering’ is in a very rudimentary stage of development as compared with the established branches of engineering.

Except for the occasional OS/390 namedrop, the whole thing reads like last year, and I surely wouldn’t be surprised to find many people and projects working under the conditions being described as unacceptable… by a conference held in 1968. Depressing, but hopefully being aware of the problem is half the way of fixing it.