Day: June 13, 2006

Stacked

I don’t normally blog about other people’s blog entries, but this is fascinating.

I’m a big fan of using a lot of delegation, with small methods and small classes, and I can understand when you’re sitting on a bunch of libraries that think the same way you can end up with these kind of stack traces.

Part of me wonders whether this is actually a problem. Modern IDE’s (e.g. IntelliJ, Resharper, Eclipse) make navigating abstracted delegation chains pretty easy (I’m forever pressing Ctrl(+Alt)+B or Ctrl+Alt+F7 in Resharper), and I would hope that the Managed VMs we use do clever stuff too. That said, I wouldn’t expect to have to understand library code more than a couple of calls outside of my own code, so libraries would have to make sure that their abstractions don’t leak too much.

Thanks to Simon Stewart for the link.

The axiom of Agile

I’m putting together an ‘introduction to Agile’ presentation this week. I’ve done them before, but I like going back and writing these things from scratch since it allows me to think about what I’ve learned since the last time.

One thing I’ve added this time around is the first principle from the Agile Manifesto, which states:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

I’ve read this statement before, and even blogged about the business value slant it has, but I’ve never thought before how much overall it underpins everything I believe as an IT professional. Don’t tell anyone, but I don’t really care about test-driven development, stories, refactoring or even continuous integration. They’re just tools I use in order to fulfill the actual goal of delivering value early and often. At the moment they’re the best tools I know of for doing so, which is why I practice them, talk about them and even spend my own time writing open-source software to make some of them easier.

But they’re not the ‘axiom’ of why I do what I do. Getting useful, valuable, software in front of a real user; seeing the smile on their face when they see their professional lives are going to be easier (if that’s the value they gain); and having a conversation about what we can deliver next, and soon, is actually why I do what I do.

When I talked about this statement before, I focussed on the business value phrase, i.e. figuring out what the monetary benefit of a feature is. If you just take the word valuable as meaning ‘something which somebody values’, then this principle can be applied to any prospective customer in the business IT world.