Liz Keogh, lunivore

My friend Jim says, “Have to say, if I were a customer I would stipulate that you left me documentation. I wouldn’t buy services from a company that didn’t ;-)”

One of the responsibilities of an Agile Coach (or perhaps this the role of a ‘Business Coach’ or ‘Client Principal’ – but a role isn’t the same as a person) is to find out what it is that the customer really wants. In the example I gave, it’s maintainability, not documentation. If documentation is the only way to provide maintainability – for instance, if the customer hasn’t been able to provide any in-house staff for pairing on the project – I might suggest writing it in the weeks before handover, so that it’s accurate and up-to-date. There’s no point doing this as you go along in Agile, because you know that the customer requirements, the application and therefore any processes / documentation are subject to rapid and frequent change. A pragmatist might document the more stable aspects of the project, such as architecture or persistence mechanisms, but even they’ve changed during the lifecycle of the project I’m on.

Another reason why customers like to see documentation is because it gives them some idea of how the project is going. Agile development provides other ways of measuring this. Most particularly, the customer can see progress in the number of stories (requirements) implemented, and by sitting down and playing with their new toy as it evolves.

Some projects may not be suitable for Agile development (mission critical?). Even so, I bet my lunch that there are still Agile practices which can improve the quality and speed of code production.

When someone wants something that doesn’t make sense to me, I usually ask, “Why?” Sometimes it helps that person clarify what they really mean, and sometimes I learn something new from the answer. It’s always a fun question to ask, and often the most important one.

A request was sent round work for anyone interested in an Agile Coaching stint. “Probably requires a convincing pragmatist,” it said.

I’m trying to become an Agile Coach. I found the email confusing at first, because I’ve always thought I’ll make a good Agile Coach one day through the right mix of idealism and enthusiasm. I’m definitely an idealist, not a pragmatist. I don’t have enough experience to do the job, but I could see myself taking the role in the future; convincing the customer that there’s business value to be found in Agile practices, and matching the customer needs to past examples of Agile meeting them. I have imaginary conversations in my head like this:

So I’m not exactly an expert at matching business value to Agile practices, but I reckon I’ve got the right idea. If the customer needs to maintain the code after we’ve left, then we’ll take his people on board, even though they might not be experienced developers. I’ve never thought of myself as pragmatic, though. Wanting all practices to deliver business value to the customer is idealism, not pragmatism. If a particular Agile practice isn’t going to help the customer in any way, then I don’t think there’s any point in doing it. Changing ideal Agile practices to match customer needs… actually, that is pretty pragmatic, isn’t it?

Here’s a theory. Pragmatism is just idealism with the right ideals.

The worst thing about having a dream is when people say,

“I’m not interested in dreams. Please dream somewhere else.”

The best thing about having a dream is when people say,

“You and I have exactly the same dream. Can I chase it with you?”
“Your dream is cool. I’d like to help you with it.”
“I think I caught your dream over here last week. Want to go for coffee?”
“Did you know that there’s an Open Source Dreamcatcher?”
“You should talk to Dan about his dream; it’s a lot like yours.”
“If you have time, could you dream something for me?”
“You like dreams; what do you think of this one?”

It’s so much easier to find your own dream when everyone else is chasing dreams too.

Following pointers from my last post, I have scoured the net for clear definitions of JavaSpaces, tuplespaces and Grid Computing (ie: I typed the phrases into Google).

I have a better understanding of the subject as a result.

I still haven’t found a clear definition of a grid. Damian has suggested that the things I wrote about good grids are needed for a grid to be called a grid at all. Ian, who led the talk yesterday, has said that there are many definitions of what constitutes a grid, and that even vendors of Grid Computing software have their own definitions of Grid Computing. Add “confusion” to the Google search and see what comes back.

The definitions of Grid Computing which I found were so wide, so varied and so unclear that I gave up and wrote my own.

Today we had a lunchtime talk about JavaSpaces, which is a form of grid computing (this is a new thing for me, so if I get anything wrong, yell).

Grid computing is when a lot of computers are used to split up processing of a hard task. The SETI screensaver uses your CPU at home to form a big grid. If you want to draw a Mandlebrot fractal, you can parcel out the various bits to nodes in a grid to calculate (this is so easy that everyone uses it as an example). There are lots of ways in which grids can be implemented, and some implementations are better than others. Some of them push tasks out from an orchestrating machine. Others have nodes which pull their tasks out of memory space.

JavaSpaces uses this latter technique, and also shares the memory space amongst several different computers. While we were learning about this, we asked a lot of questions and began to form a picture of how a really good, robust grid would work.

1. A good grid has redundancy in its memory store, so that if one node goes down another has the necessary information to continue.
2. Some really good grids have nodes which work out when they’re being polled for information too often, and find another node which isn’t being used so much to share it with.
3. A good grid will work out when a given task is killing nodes too often, and flag the task as something which needs fixing.
4. A good grid will look for high-priority tasks to run first.
5. A good grid runs transactionally, so that if a node fails to complete a task, it doesn’t break the grid. Instead the task stays on the list.
6. Some really good grids accept that their nodes aren’t perfect (for instance, floating point arithmetic may differ from one hardware base to another). These grids use a voting system, so that the result of one machine is checked by others.

Can you see where I’m going with this?

There are a lot of parallels with Agile Development and collaboration between Agile developers.

1. A good team will communicate, so that everyone knows what’s going on.
2. On a good team, developers are encouraged to share information instead of hoarding knowledge. This reduces the bus factor.
3. A good team will spot problems which kill their velocity and sort them out.
4. A good team will take on the tasks which the customer has decided have the highest business value.
5. On a good team, members won’t check in stuff that breaks the build. They’ll use version control so that if they do accidentally do something which breaks the build, they can roll back their changes and try again.
6. On a good team, developers ask for help and accept it from other developers. They will pair together, and discuss possible solutions until they have an idea of which solution is best.

I wonder – is Agile naturally suited to this kind of development work? Does splitting things into manageable chunks lead to easier, more even development? Would developers communicate better if we were coding for a distributed system? If we developers lend out our brains, will we discover life beyond our world?

• Use IntelliJ to refactor a class so it’s easier to test.
• Add a suitable mock object jar to the library.
• Add unit tests for the class which we’re about to change. Make sure all functionality is covered.
• Write new test method which falls over.
• Make unit test pass.
• Write new test method which falls over.
• Make unit test pass.
• Check in new tests, new functionality, and all the tools required to do this again tomorrow.
• Sit back, look at the lovely, tidy(ish) code and smile.

There’s just something about that green bar. I remember why I love this job.

I need to invent a green bar for housework.

At some point I’m guessing that the SheepImpl I’m looking at was an implementation of a Sheep interface, which extended the Animal interface. There’s also an AnimalImpl class. The Impl classes are generated by persistence layer stuff, so there’s some logic there.

(Why couldn’t we just have called it PersistedSheep, or GeneratedSheep, or HibernatingSheep? Would that have been too obvious, perhaps?)

There are other unrelated uses of Impl as implementations for interfaces – GrassImpl for the Grass interface, MangerServiceImpl for MangerService – you get the picture. It seemed reasonable to assume that the animals followed the same daft convention.

Assumptions are dangerous. Conventions are dangerous, especially when they are conventions in sheep’s clothing, so to speak. I should have read the code more carefully.

Sheep is now also a class with its own functionality, and is extended, not implemented, by SheepImpl. Sheep itself extends Animal (also a class) but not AnimalImpl. It’s taken me half an hour to work this out, and now my head hurts. Partly from unravelling spaghetti this late on a Friday, but mostly from doing this:

*Bangs head on table repeatedly*

Note: The actual code is in a retail application and has nothing to do with sheep. Thinking about things in terms of sheep, however, is helping me to be less stressed about this. One sheep. Receipt for one sheep. Special offer: two sheep for one! I would like four sheep, please. I’m sorry, Sir, we only have three sheep in stock, but I can order a fourth sheep for you.

Dreaming of electric sheep. Hmm.

Well, more accurately, I broke X-Windows while trying to get Doom III to work.

X-Windows works (I think) by using one of the many available X-Servers in combination with some front end stuff and information about your hardware. Some time during the Warty release of Ubuntu, they switched from using XFree86 to XOrg as their X-server of choice. I couldn’t get Doom III (and the ATI drivers) to work with XOrg, though, so I tried to reinstall XFree86. Unfortunately, some change or other I’ve made prevented this. So I tried to reinstall XOrg. I think my attempts at XFree86 installation may have stopped that from working, too. So now I have no X-Windows at all.

Fortunately it’s pretty easy, even from a basic terminal, to back up everything that’s important onto my lovely server. Rather than trying to fix all the X stuff which I know nothing about, I’m just going to reinstall the Ubuntu partition on my PC.

Hopefully if I use a fresh installation of the latest release (Hoary) then I can work out what I did wrong. If I can get Doom III running it’s another link severed in the chains that bind me to Windows.

Obie wrote a post on the benefits of IM.

Marco asked, “What about the problems that an IM will bring to the company? [ I ] know that people tend to lose some time just chatting with friends, girlfriend, whatnot.”

I have a controversial theory: IM brings no problems at all to a company. If a company’s staff don’t care enough about the company to make it succeed, then not having IM won’t make a lot of difference.

This is analagous to XP explained, which suggests that XP cannot save a project where the staff don’t care about the project. Nothing can save a project where the staff don’t care about the project. Except, perhaps, things which make the staff care more, such as the joy of unfettered access to IM, and the sense of pride one feels at being trusted to use it responsibly.

is now up and running. At the moment it’s just a file server; no web or ftp yet.

It’s bizarre. It’s just a shuttle box with a power cord plugged in the back.

It doesn’t need a network cable, because it’s got a wireless ethernet card.
It doesn’t need a monitor, because I can use SSH for remote administration.
It doesn’t need a keyboard, because it’s so quiet and cool that it’s hardly ever going to get rebooted.
It doesn’t need a CD reader or floppy drive, because I can apt-get everything I need off the web.
It doesn’t need a zip disk, because I’m running RAID 1 so everything’s automatically backed up.

It’s the most stripped-down little machine I’ve ever had, beating even my Palm T3 for minimal functionality. It’s wonderful to be able to access my documents, code and music from both Ubuntu (PC) and Windows partitions. I love it. I am in newbie Linux heaven.