Rob Lally : Robert Lally

Zoë Keating is phenomenal.: I hate cellos, I normally find the sound of them grates on my nerves. This isn’t the normal Cello music, Ms Keating is wonderful. Have a listen.

(Via WWdN: In Exile.)

For the last couple of months Guido van Rossum the creator of Python has been writing up a history of the development of Python hereThe History of Python. The history aspect is interesting enough, but as part of his write up Guido has been describing his thought processes, goals and design decisions; I love this sort of thing.

I’ve just heard that “Dr. Dobb’s Journal of Tiny BASIC Calisthenics & Orthodontia - Running Light without Overbyte”, AKA Dr Dobb’s Journal, has ceased printing. It makes me sad. Not sad in the way someone who is a regular reader, now deprived of their regular fix would be sad because .. well, I haven’t bought a copy in years. But sad in a nostalgic, I remember when, sort of a way.

I had a look at their web site hoping that there would be some remnant of their greatness would survive. Perhaps some old issues I could browse through. My god, that was a mistake. Their web-site is one of the worst ghetto-advertising-hovels I’ve seen since 1998. If that’s any indication of the content they’ve been putting out over recent years .. no wonder they went down the tubes.

I understand that publishing is a tough row-to-hoe, and that nobody in that world is finding it easy, but that’s no excuse for their execrable web-content.

Art and code - obscure or beautiful code?

(Via JAOO Community Blog.)

I don’t know what it is but .. I like it.

Agile development is more culture than process: “Why thinking of agile as culture and not just process explains resistance and difficulty in teaching and learning the approach”

(Via Jeff Patton.)

Jeff Patton presents a well thought out, well articulated article. But one I couldn’t disagree with more.

Jeff presents an argument that Agile isn’t a process, but a culture, and I’d agree that Agile isn’t a process but, despite the many Agile proponents who make it seem that way, Agile isn’t a culture either. Agility is just one quality that an organisation can have. An organisation can have an Agile culture, but that doesn’t mean that that their culture is Agility.

Presenting Agile as a culture is something I’ve seen many times, and it puts more people off. Agile zealots, a club I was a member of a decade ago, try to sell Agile as a culture in a way that reminds me of Mao and his Cultural Revolution; they want to come in to your organisation, declare your culture to be bankrupt and rip it out, replacing it with an idealised regime of their own. (I do not put Jeff Patton in this category, his writing is very sensitive to the existing culture of organisations.) Mao famously said that political change can only come through the barrel of a gun. Mao’s way may have changed china. But it isn’t the way to change organisations in the twenty-first century.

An organisation that wants to undergo an Agile transition is an organisation that wants to acquire a new quality. Adopting this new quality is not easy, that’s why experienced Agile practitioners can be invaluable during this process. Cultural change is not easy, it is painful for organisations and the people that make them up. I think this is why Jeff, and the rest of us who’ve been down this road, have seen push-back and pain when performing transitions.

You must be sensitive to the needs and feelings of an organisation. You must be conscious of the times when existing cultural practices, processes and artifacts are in conflict with the changes you are trying to make. You can’t steam-roll people and tell them that their existing culture is valueless, you have to show them what they have, where they can be and help them make the journey.

After the transition an organisation should have Agile qualities. They shouldn’t be Agile. An organisation that has no quality but Agility can not survive, they have nothing unique to offer the world. As someone performing an agile transition, we should strive to ensure that the organisations we work with should be strong, energetic, diverse, healthy and Agile. They should have their own culture at the end of the process, just as they did at the start. Just a bit better.

Over the last few years, I’ve moved past Agile. Not that I think it is bad, I still embrace it fully, and I still use Agile practices because I believe they work. But Agile isn’t everything, any more. It never was, I just didn’t see all the other things that I and those around me were doing. I think that Agile brought the humanity back to software development, something that had been bleeding out and something that we need to be effective. Agility recognises that it is people who write software and that by remembering that fact, we get the most out of the people.

These days I consider myself to be in favour of Humane Development. Respect people, respect their culture, challenge people to do more, to do better, reward them for successes, help them when they falter, teach them to be the best they can be and expect their best efforts from them in return. Like Agility, organisations need to have Humane as a characteristic if they are to thrive.

Social Programming A Pyramid is a fascinating video from OOPSLA 2008. If you’ve got 90 minutes, and if, like me, you find passionate people talking about their passions enthralling, then I highly recommend watching it all.

If your users can’t find the feature it might as well not exist: “The lesson here is that having a feature isn’t enough, making sure your users can easily find and use the feature is just as important. In addition, sometimes the best thing to do for your product isn’t to add new features but to make sure the existing features are giving users the best experience.”

(Via Dare Obasanjo aka Carnage4Life.)

Dare brings up a good point, if users can’t find a feature .. it might as well not exist. There are a number of related issues here, too. How many features is too many? Is there a critical mass of features, beyond which the utility of an application actually goes down whenever you add a feature?

A lot of people conflate utility and feature set. And they’re definitely not the same thing. A swiss army knife has a lot of features, and some very sharp blades, but they’re difficult to hold because of all the tools so they’re not comfortable to use. Indeed, the more tools you add to them, the harder they are to hold.

Dare also talks about the constant mass of new feature requests the Microsoft Office team get. I’m not a power user of Office by any means, but I don’t remember the last feature that was added that made a difference to me. Are MS sacrificing the utility of Office by adding more and more features? Has the experience of the average user actually gone down over time? I don’t know the answer to any of these questions.

The situation, does remind me of Goldratt’s book Necessary But Not Sufficient, where he describes a company that are swamped with feature requests from users, feature requests that come in faster and faster over time. His suggestion is that people are asking for new features for two reasons:

1. The product is not addressing people’s core problems. The users don’t really understand why they’re not satisfied so they ask for more and more features which seem like they might help .. but never do.

2. The producers of the product don’t work with the users to get them to change, they constantly change the product to suit every individual customer adding more and more ways to do everything until you have such a mass of features that you’ve lost any sense of consistency or cohesion.

I’m not advocating feature minimalism: I still don’t understand why I can’t have a right mouse button or a delete key on my Mac. But I do thing that software engineers consider the benefit of features rather than considering the total cost of ownership of them. When considering the value of a feature, particularly in shrink-wrap software, you need to remember that it’s very hard to take a feature out, so you need to be sure that you want to carry this feature forever.

Features have value. Not having features can have value too. Developers don’t get a buzz out of not implementing a feature though ..

I switched from Safari to Firefox about six months ago. Firefox had a feature that made me want to switch; if you close Firefox with open tabs, it offers to save them for you for next time. At the time I was taking my laptop with me to work each day and shutting it down during transit saved battery power. It was a pain to have to go through all the tabs and figure out what to bookmark and what to discard.

So that seemed like a good idea, and I’ve used that feature every day. I now have over one hundred tabs open, many of which I’ve not looked at in months. In fact, this article Ancient Egyptian Numbers is one I opened when Clarke linked to it in mid-october. I’ve not read it. I still plan to but …

The feature I liked so much, turns out to be an anti-feature; at least in the hands of a someone with a tendency towards procrastination, like me.

I like books. You can never have enough books. I have lots of books, but I don’t have enough.

What books should be on my reading list? What are the books that everyone should read?

Who’s Your Coding Buddy?: “I am continually amazed how much better my code becomes after I’ve had a peer look at it. I don’t mean a formal review in a meeting room, or making my code open to anonymous public scrutiny on the internet, or some kind of onerous pair programming regime. Just one brief attempt at explaining and showing my code to a fellow programmer — that’s usually all it takes.”

(Via Jeff Atwood’s Coding Horror.)

Jeff Atwood makes me laugh. He makes a valid point - he finds having someone else look at his code valuable, he feels it makes his code better. Something I think we’d all agree is true. He even pulls out statistical evidence for the efficacy of code reviews, which would add support to a well reasoned argument.

Of course, Jeff can’t leave it there, he has to back-track on his own point. Code reviews make your code better but heaven forbid the idea that a group of technologists should agree to do something that makes your code better. He rails against formal reviews and pair programming, instead he suggests ‘just have a buddy look at it’.

I really don’t understand the man, what grudge does he have against the idea, that people can agree to do things that make sense? And beyond that, if people can’t agree to do the right thing, shouldn’t their manager insist? I can’t think of any other industry where leading members of the community would speak out in favour of people NOT doing the things THEY think are right? Would Jeff approve of the idea of a leading surgeon calling for his comrades to give up on M&M reviews and just ask a buddy why their patient died?

Every morning, when I open my RSS reader, the first thing I do is scan for a new episode of Scot Meyer’s Basic Instructions. You should too.

I’ve stumbled across Cappuccino and Objective J repeatedly over the last year, and whilst they always looked interesting - there was never enough to be really compelling. That may now have changed if Atlas is as promising as it looks.

I’m not convinced that Atlas itself is going to be a great success; I don’t buy the idea that you want to be writing software in a browswer. But if you can write a drag-n-drop WYSIWYG IDE in Cappuccino then it might well have something going for it. Can Atlas be the killer-app for Cappuccino without actually being a killer-app?

Teaching CCPM in an Academic Setting: “I had a kind of slap-in-the-face moment some months ago regarding ‘on time,’ namely the difference between on time as a measurement and on time as an objective. “

(Via Robert C. Newbold’s Billion Dollar Blog.)

I think Mr Newbold has an interesting point here. People find it hard to distinguish between a measurement and an objective. When I first read his comments it took me several seconds to figure out why I would be measuring something if that wasn’t what I wanted.

In the case of software features, I want them completed as soon as possible; but I can’t measure ASAP, so I’ll probably measure what I can - compliance with a plan. It is important for everyone involved, project managers, developers etc. to understand that the plan isn’t what we want. What we want is as much value as possible, delivered soon as possible. In fact the plan is, in real terms, often a listing of the worst case scenario that we can tolerate. Working to the plan in this case is a terrible idea.

I’ve just been reading Neal Forde’s three part series on SOA. An interesting piece in of itself, but one part in particular caught my eye:

Tactics vs. Strategy (SOA & The Tarpit of Irrelevancy): “what is strategic to the business is always tactical to IT. Business people can go into a conference room and change the entire direction of the company in 2 hours. Or, the business may decide to merge with another company that has truly dysfunctional IT, but other business concerns override that. IT can never move as fast as the business, with means that IT always has to respond tactically to the decisions and initiatives brought forth from the business.”

(Via Meme Agora.)

Is it true, that, IT can never move as fast as the business?

As a technologist, it’d be easy to dismiss this claim by pointing to a single example where technology drove forward the business, thus refuting the claim that it never happens. But that isn’t really what the author is talking about and isn’t really what interests me.

Businesses have a historical rate of change, how often they’ve changed their products, offerings, pricing, strategy, structure etc. And, if you look at the historical rate of change of technology it will match it one to one.

But that’s only part of the story. Most businesses that I know, don’t have a constant rate of change. Change is lumpy. Change comes from a stimulus: a new opportunity, a new marketing campaign, market conditions, technology, the economy, science, new staff, new ideas, failure of a competitor, a new competitor on the block etc. A stimulus occurs and a business must change to meet the new demands or opportunities.

When a business wants to change, how does their IT department work with them to support that change? Do they match them stride-for-stride? Are they a drag saying, “oh, no, we can’t do that in less than eighteen months”? Or are they an asset to the company and they find ways to accelerate the change, giving the business options and opportunities they didn’t think they had?

Too often a business can only move at the rate their IT department will let them. In the year 2009, everyone in IT needs to make sure that they are enablers for their business. We need to partner with the business people in our organisations so that we can give them options. We have tools of unparalleled power and flexibility at our disposal, we need to make use of them for the benefit of the organisations we work for. We need to do this to survive, we need to to this so that IT is a profit centre for our organisations not a cost centre. Now more than ever, if you can’t point clearly to the benefits you bring to the bottom line, nobody else will. And if you can’t point to those benefits then there’s never going to be security in your role.

In many organisations there’s a culture of hostility between the business and IT. In my experience, this is often because the business have asked for change in the past and IT have been unable to deliver. This situation will not fix itself.

The answer is partnership. That’s the second time I’ve used that word in this posting .. and it is one of those words that everyone uses when they’re stuck for a more meaningful concept. Everybody agrees we should be partners. Partnership is ‘a good thing’. Nobody is going to stand up and say, “bah, partnership, bloody awful, not doing that”.

What does partnership actually mean in real terms? Sadly, it is one of those “I’ll know it when I see it” things. I can tell you where I start when I want to build a business partnership though. I start with the word but.

“Yes, I can build the thing you’ve described to me but I can do this in half the time. Would that be better?”

“No, I can’t do that by tomorrow night, but I can do this other thing. Would that do in the short term?”

“Hey, I noticed we’re doing this, but we could do this other thing. Would that save you time?”

“Hey, I spend a lot of my time doing this, but if we changed to doing things this other way, I’d have more time to help you with that. Would that be OK?”

As I mentioned in my last post, I’ve left JPMorgan and I’m now a free agent. Free agency is a term from the sports world, where it is a coy way of saying ‘you can hire me’.

I don’t really like coy so, in short, I’m available. You can reach me on rob@(domain).com if you’re interested.

Sales pitch aside, I want to use my free time productively. I intend to write here whenever I have something to say. I’m going to catch up on the giant pile of books that I’ve bought over the last few years that I haven’t had time to read.

Beyond that, my friend Clarke has been encouraging me to write. Like everyone else I feel I have a book inside me, so I’ll try committing it to bits and see how it turns out. Maybe it’s a book in there, maybe just gas.

There’s also a huge pile of technical topics that I’ve touched the surface of, but haven’t dived into as deeply as I’d like over the last year or two.

For the moment, as least, I’ve got time without commitments. I don’t intend to waste it.

After six and a half wonderful years with JPMorgan we’ve decided to part ways. I’ve had the pleasure of working with the smartest, most dedicated, hardest working group of people I’ve ever met. It was an honour and a privilege to know you and to work amongst you. We achieved some amazing things, you’ve forever enriched my life, and my time with you is something I’ll never forget.

I thank you all.