The Erlang experience

I've spent a few hours bashing away with Erlang now, and things have certainly come a long way since 2007 when I last devoted any time to Erlang.

Actually, not everything has come a long way. The only platform that you can get binaries for on is Windows. I was working on Windows the last time I poked at Erlang so I probably didn't notice this last time round. Compiling from source isn't a huge deal but ... this is 2009, if you want people to try something, forcing them to compile from source before they can try it out doesn't seem like the path of least resistance.

After compiling I looked around for an editor and many fingers pointed to Erlide. I must admit, I wasn't expecting much - I haven't been pleasantly surprised by Eclipse plugins for off-the-beaten-path languages in the pase. I must admit, I've been pleasantly surprised by Erlide. It has all of the basic functionality I'd want and a little extra that I wasn't expecting with some refactoring functionality that was released today. The one piece that doesn't seem to be there is a code formatter, which surprises me as that's normally one of the first things to get done. There may even be one in there somewhere and I just haven't found out the incantation to get it going.

So, I have Erlang installed, and I have an editor/IDE. Next stop, some educational materials. I have Joe Armstrong's book Programming Erlang which is a pretty good text, but I'd like to warm up with some shorter pieces, whet my appetite going and get me back into the flow of things. The main Erlang site has some pretty good tutorials here.

After getting back up to speed on language basics I need look through the libraries that are available. In 2007 there wasn't much beyond the OTP stuff that ships as part of the Erlang distribution. That's changed, there is now a plethora of libraries and frameworks, in various stages of maturity, that I'll need to look into before I really have any sort of handle on Erlang development.


Who watches The Watchmen? Well, me for one.

I watched The Watchmen on Friday, and it was truly splendid. I was going to write more but ... I think I've covered it.

A civil debate

I got involved in a discussion a few days ago in the Scala mailing list. I made a statement based on an experience that was related to me, rather than something I'd tested for myself. Alexis Richardson disagreed with me and the commends I'd made about Erlang and RabbitMQ strongly, and said so.

None of the above is noteworthy, people disagree about things all the time. What is noteworthy is that Alexis remained calm, measured, polite and considered all through the discussion. This is such a pleasant change from the usual mailing list pattern that I thought it was worth mentioning.

As a tribute/thankyou to Mr Richardson and his well-mannered ways, I've decided that I'm going to give Erlang - a language that wasn't on my list - a second chance, and try it for the personal project I mentioned a few days ago.


Correlation doesn't imply causation, but it does waggle its eyebrows suggestively and gesture furtively while mouthing 'look over there'.


I read this and laughed. Connected? Hard to say.


File Compression in the Multi-Core Era

I gave Jeff Atwood some stick last week when he wrote something I thought was ridiculous, so I thought it was only fair to throw him a 'good job' when he wrote something I found really interesting: File Compression in the Multi-Core Era.

For .NET developers, these guys seem OK

Learn, Share, Grow: "I am sitting here at the opening of ALT.NET Seattle. I look around and see the words 'Learn, Share, Grow’ on a poster...

What it means is that we recognize the value of the sum total of our experiences. We recognize that we all have something to give, and to take.  Benefitting, doesn’t come for free, but the cost is a worthy investment.

(Via CodeBetter.Com - Stuff you need to Code Better!.)

Sometimes the tech community makes me very proud.

Recent reading

Last week I said that I'm using the time I have free to catch up on my reading - getting to all those books I've been meaning to get through.

First on my list was Eli Goldratt's latest book The Choice. It'd been a while since I read his other works, so I decided to re-read them first. In the last few days I've re-read The Goal, Necessary But Not Sufficient, Critical Chain and It's Not Luck. Every time I read these books, I get something new out of them. If you've not read Goldratt's work, I heartily recommend it.

I said that I was re-reading Goldratt's earlier works in preparation for reading his latest book. I haven't got to that yet, that's next on my list. I got distracted when a friend tried to explain something to me by referencing Seth Godin's Purple Cow theory and, since I haven't read the book, I didn't know what he was talking about. So I read ordered a copy from Amazon and read that last-night and this morning.

This is the first book I've read that just focusses on the 'getting the message out' end of marketing. I'm surprised that I got as much out of it as I did. In retrospect, this is a field I should have spent more time reading about. I need to work to fill in my knowledge here. Anyone with pointers towards the 'right' reading material feel free to drop me a line.


Only fifty-percent efficient

For the last couple of days, I've been chewing over an experience I had about a decade ago. I'm trying to understand the underlying thought processes that led a problem.

About a decade ago, I worked for a project manager that I'll call Mr D. He was (and probably still is) intelligent, wise, kind and dedicated. A genuinely decent human being. I learned a great deal by working under him.

I worked for Mr D at a company that was having some problems, Mr D was brought in to try to fix things. One of the problems we had was a slavish dedication to a development process that didn't work. Mr D saw this, and took my recommendation to bring in an Agile coach and migrate from RUP with all the trimmings to XP. We worked through this process change and things picked up, they got a lot better in fact. But not better enough.

At the time, I was too inexperienced to see all the other mistakes we were making as an organisation. In the end, it didn't really matter what we did, by the time we started making changes the project was years behind schedule and the writing was on the wall.

Here's the incident that has bothered me for the last decade.

Our team was following a classic XP process, we were pair-programming most of the time and we decided right at the start to estimate in 'pair-hours' rather than in hours to keep things simple. Our velocity fluctuated wildly over the first few iterations and eventually settled to a consistent level. Our estimation unit was hours - that was what we started with, but over time we had come to think of them as arbitrary units, we could have changed the name to 'arbitrary work units' but it didn't seem important. Everyone was working hard all day, distractions had been minimised and people were feeling good about our progress. We knew we could be better, we knew we could improve and we were. Every week were getting a little better.

Mr D, who I realise in retrospect must have been protecting our team from tremendous outside pressure, came in one day and announced that he was changing things again. It was his call, I don't have a problem with that. It is his reasoning that bothers me. He had totalled up the estimates of work accomplished for the last few weeks, totalled up the available man hours and calculated that we were only fifty percent efficient. He wasn't even complaining about the pair-programming, he was calculating things in pair-hours rather than hours. When people tried to point out the basis for our estimates wasn't hours, he became enraged.

In summary:

He knew the basis for our estimates wasn't hours.

He worked in the same room as everyone else, so he could see with his own eyes that people were working hard all day every day.

But still he came to the conclusion that an efficiency calculation he'd used in the past was telling him something was wrong and that he had to make a change.

Why, despite the evidence of his own eyes, did he come to this conclusion? He didn't need an excuse to make a change, it was his house and his rules. It don't even think that he was trying to justify his decision to the team: nobody agreed that his justification made sense, but he kept insisting that we were, at best, only fifty percent efficient.

Was it pressure and panic that made him turn to something he knew, even if he knew it didn't make sense?

Was it a rejection of the methods we were using, trying to turn the team towards a structure he knew and had more faith in?

Did he really believe that we were only fifty-percent efficient?

I wish I knew.

Over the years, there have been many times that people have made decisions I didn't agree with, but at least I understood their reasoning. In this case, I don't disagree with the decisions Mr D made, I just wish I could understand his reasoning. Deep down, the fact that I don't understand scares me. How can I stop this happening again, if I don't understand what happened the first time?


I saw Aliens at a local cinema last night. No I didn't fall through a hole in time/space. No, I don't just live so far into the ass-end of nowhere that 80's cinema is just getting to us.

I'm not sure why they did a special showing, but they did, and I'm very glad. Aliens is a film that is ageing very well; much better than I expected in fact. I think that it passes the test of time because, whilst it is sci-fi, it is a plot driven piece with memorable and distinctive characters.

I don't know how the economics of the movie industry work, but it seems to me that the simple expediency of having a plot is giving Aliens the ability to sell out a cinema 23 years after it was made. That must be good business.

Zoë Keating IS phenomenal

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.)


Paint along with Guido

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.

Art and code - obscure or beautiful code?

Art and code - obscure or beautiful code?

(Via JAOO Community Blog.)

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

Agile is a characteristic, not a culture

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.


assert: (Egyptology + Programming) == Interesting

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.

How many features is too many?

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 used to think it was a feature .. now I'm not so sure ..

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.

What should be on my reading list?

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?

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?

Step aside Dilbert

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.

Atlas and Cappuccino

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?