niksilver.com

I’m amazed and disappointed that it’s still acceptable for people who run major companies to show wilful ignorance of technology. And I don’t mean what firewalls do or how to get wifi working on your laptop. I mean what it means to the companies they run, how it impacts their people and their customers, and how to make sure it’s an asset rather than a liability. And there was an exemplary demonstration of this on last week’s edition of The Bottom Line on Radio 4.

The programme is a straight discussion of business issues with Evan Davis and a number of business leaders. It’s not dumbed down (any more than it has to be edited down) and is a consistently excellent listen. Last week the guests were Luke Johnson, chairman of Risk Capital Partners, Vincent de Rivaz, chief executive of EDF Energy, and Jacqueline de Rojas, UK and Ireland vice president of McAfee. And they dealt with two major topics: organic growth versus acquisitions, and problems with IT. Luke Johnson in particular seemed to really have problems with technology, and to me there was overwhelming evidence that some of the causes might be rather closer to home than he might like to think.

Coming up is some criticism of what Luke Johnson and (to a much lesser extent) Vincent de Rivaz say, but don’t mistake it for a criticism of them as individuals. The point of what follows is that their attitude is representative of so many board leaders. Even though there are many board leaders who have a very confident grasp of technology issues it’s still remarkable there are so many others who handle technology as if they were wearing boxing gloves.

Problems with technology

As the resident IT expert it was Jacqueline de Rojas who was asked first about her own experience of IT problems, and in particular the bad software update that her company issued in April which disabled many of its customers’ computers. Notably, she responded to a technology-related question with a positive and human answer: “The key in a crisis like that is how you respond; that’s how you’re judged”. Then Vincent de Rivaz was asked if he had ever had any IT disasters, and before he could finish his response (along the lines of “no actual disasters, but we have had problems”) Luke Johnson cut in:

LJ: “Every business I’ve ever come across has always been having problems with [its IT].”

VdR: “We have to invest in our IT and we have to develop our IT systems which we are doing at the moment [with a new online system to help our customers with their bills.]

ED: “What sort of problems have you had with your IT?”

VdR: “The problem is to control the costs. That is the permanent challenge for me, to be sure that we are spending the right amount of money on the IT systems.”

LJ: “All my experience of IT systems is they are always overdue and over budget, and I think it’s a built-in part of the IT industry that they deliberately under-quote and then they may get up on the extras.”

Now there are many problems board leaders could have with IT: We aren’t getting the best out of our technology investments. Our technology portfolio isn’t broad enough to help us in a constantly-shifting market. We don’t have the people who really understand how to manage and change our technology infrastructure.

These are all problems that require board-level investment and oversight. And they are also all questions that, if you substitute “financial” for “technology” all boards do deal with. But sadly it’s okay to ignore those matters if they’re technological, and so the top-of-mind IT issues for our token CEO and chairman are (1) cost control, and (2) IT people are sharks.

Indeed, Luke Johnson seems to have something of a chip on his shoulder about technologists. Jacqueline de Rojas goes on to explain a bit about the difficulty of  turning “woolly and aspirational” IT demands into concrete deliverables, but that doesn’t stop him:

LJ: “I think the IT experts blind clients with science, and I think very often they themselves overestimate the benefits, and overcharge for what they do. And the fact is there isn’t another industry, except perhaps pharmaceuticals, that makes the returns on capital and margins that software does. Huge margins.”

JdR: “The level of investment we have to make to stay ahead technologically is also huge. So where do you think that money goes? It goes right back into making sure we stay one step ahead of — in our case — the hackers and cyberterrorists and the competition”

ED: “Let me challenge you, Luke. Is there something different about IT from other areas of company purchasing? Is IT unique in being difficult and awkward for a company?”

LJ: “No, I don’t think it’s unique, but I think it is mission critical, and unquestionably we are all more dependent on IT than ever. I accept all that, and it can deliver huge values, and the very nature of it is it’s constantly evolving. But the truth of the matter is, what other sort of project or product, rather, do you buy that requires these perpetual upgrades and offers such super returns? I was involved with a retailer once, Whittard of Chelsea. We spent, many years ago, the best part of half a year’s profits on building a fully-integrated website. This was in the early days of the web. Within two years we had to throw it away. Because it just didn’t work. We used the wrong suppliers and we made a lot of mistakes.”

To him IT is a homogenous  blob, and he transfers his anxieties freely between commodity software sales (”returns on capital and margins… perpetual upgrades”) and individual business change projects (”a fully-integrated website”). Maybe he’s just exploiting the opportunity to have a go directly at a software vendor, because when Jacqueline de Rojas highlights how technology change really does improve our lives he’s having none of it:

LJ: “What are the cost of goods in software? What are the cost of goods? How much does each new program cost Microsoft? Zero.”

Which is silly, because he knows perfectly well that software (like pharmaceuticals) costs a lot of money to create, and Jacqueline de Rojas has already explained the cycle of investment, return, and re-investment that her market demands.

Where the problems lie

I’m not for a second denying that Luke Johnson’s frustration is unfounded. It’s clearly borne from many hard experiences: this is a man who’s job is to cast his net widely across many, many companies, to look into them seriously, and having done this he finds that “every business [he's] ever come across has always been having problems with [its IT]” and he’s witnessed one of his companies building one costly system only to have to replace it unexpectedly early.

But from where I sit a lot of his problems are of his own making. If you treat IT primarily as a cost then the best you’ll achieve with it is cost control, whereas the best you should get out of it is business transformation. If you think IT contractors under-quote on the basics and expect to make up for it on the extras, then you probably want to structure the next deal differently and be prepared to make it more of a partnership — if you can be confident of being able to act as a partner. If you think IT experts blind you with science then you’re talking to the wrong people — and if you don’t know who the right people are then you need to start filling that gap in your personal network. If you think IT experts overcharge then you’ve created a relationship with conflict at its core and the best you’ll get out of them is the minimum they’re contractually obliged to deliver, whereas you should be getting them to apply their creativity and rigour to help propel your business forward.

The thing that’s really shocking to me is that there are many company leaders like this, who are unashamed of their blunt handling of technology — which is undeniably mission critical — and yet the same people wouldn’t stay a week in their jobs if they demonstrated the same disregard for, say, legal matters or finance.

Which is rather ironic, because earlier in the programme it was Luke Johnson who was called on to be the resident expert on organic growth versus acquisitions, and one insight he provided was this:

LJ: “Many studies suggest that even perhaps a majority of all acquisitions fail to deliver shareholder value. So it’s important to put it into perspective and say if we can achieve returns through organic growth, but perhaps a little more slowly, then maybe that is the more sensible way to proceed.”

Let’s take a second to understand what we’ve just heard: possibly more than half of acquisitions fail to deliver value to the owners of the business — which sounds very similar to his problems with IT. And acquisitions are a significant part of his company’s business — mission critical, even. Just like IT. But in that conversation he wasn’t remotely upset or bitter about this, he just treated it as something to deal with. He could do that because he was comfortable with working in that sphere and, I suspect, because while he might have had his share of acquisition failures they will have been outweighed by his successes.

It seems to me that if board leaders were obliged to grasp technology to the same degree as they are obliged to deal with financial or legal matters then their companies — and their companies’ technology — would be in a much better place.

Two final things

A couple of parting thoughts.

First, some not-at-all-serious observations about Risk Capital Partners. While confirming that indeed they don’t invest in any IT or software companies, I found they do have an interest  in InterQuest, “a fast growing IT recruitment business”. So if Luke Johnson is concerned about the high cost of IT professionals then he might want to have a word with them. Also, I couldn’t help but think if software really is the fantastic high-margin business he thinks it is then RCP really should start making some investments there. I don’t know if they really will make a lot of money, but I do know they’ll learn a huge amount.

Second, a much more serious note. Earlier I said that if these sorts of leaders had IT problems then some of the causes were close to home. But it’s also true that some of the causes lie with us technology professionals. If technology really is seen above all else as a cost to be controlled, and if we are finding ourselves in unbalanced, conflict-driven relationships, then we really do need to do a much, much better job at explaining what we do. And then we have to carry that through into our actions. Technology in business is about making the business more effective and people’s working lives better. We ought to be able to find routes to even the most sceptical business leaders to explain that, and get a positive reception.

Agile comes with tons of literature on how to organise work at a very detailed level. How much of this treadmill is activity for activity’s sake, rituals, and religious manifestations of an ‘Agile Sub-Culture’ aimed at integrating a growing workforce? Can this relentless ‘heart beat’ and this esoteric jargon stifle innovation and alienate the very people Agile purports to help? Could more slack benefit a discipline which ultimately relies on people’s intelligence and creativity?

That’s how we set the scene a few days ago when I led a discussion among some peers from different companies entitled “The Agile treadmill: Command and control in disguise?” It was organised by IndigoBlue as part of their Second Wednesday series, under the Chatham House Rule. This is summary of what we discussed, with fictionalised initials for each participant.

In this article

• Origins. How the question arose.
• How useful is Agile process? It’s not all bad.
• Religious Agile, variable results. Examples to demonstrate that religious Agile is somewhat independent of project success.
• So what is Agile, anyway? To be best understood, agile working should be seen not from the development point of view.
• Seeing the vision, from top to bottom. The importance of all stakeholders seeing the whole picture.
• What did we learn? That religious Agile is independent of project success, that agile is a business methodology, and that the vision must be shared.

Origins

When people talk about how Agile they are I find this usually coincides with how rigorous their processes are. Some of the largest, most successful Agile projects I know have an exhausting hothouse atmosphere, where everyone’s role is tightly defined and cannot be deviated from.

Have we created a kind of Animal Farm, where a system designed to set us free has actually enslaved us? Does it make a difference if Agile has been introduced by developers or management? Is effective Agile synonymous with a hothouse environment?

Between us we had an awful lot of experience to help answer these questions.

How useful is Agile process?

There was a general agreement with TC that there is some real value in having standard processes and practices:

• Rewriting the rulebook every time you start a project or programme is wasteful if you can capture the processes and practices that are known to work;
• It’s easier to bring in external resources if well-known language and practices are being used in the team.

But practices can be unnecessary, and there was recognition that many practitioners have a near-religious attachment to them, and to particular ways of working. As people managing programmes of work we often don’t have the discipline to recognise what the right level of discipline is… and isn’t.

There was also concern that Agile created an alienating language. NA indicated his particular discomfort over the word “customer” because that was often not how people saw themselves or their relationship with the tech teams.

Religious Agile, variable results

So no-one was anti-process (nor anti-Agile process), and we know it has produced good results. Our own major rebuild and redesign at the Guardian is one example of that, with a very highly regimented process and an outcome that at least met the aims and expectations. There are plenty of others.

On the other hand we collectively had experience of strong-process projects which weren’t delivering.

FC talked about Agile projects in his organisation. Most of the smaller ones were fine; these were projects with just a handful of developers. But the company’s most significant piece of work was having serious problems. It was now in its third year — nothing necessarily wrong with that, we said, after all some projects are just very large. And what had been delivered so far? Not much. Ah, we see the problem. And yet, he said, to the people on the ground this was a successful Agile project, because they were doing all the right things: daily stand-ups, rigorous unit testing, prioritised iterations… all the paraphernalia of an Agile project. They couldn’t see there was a problem.

AS reported a similar experience. “When I walked into the organisation they proudly walked me through their very rigorous process. ‘But nine out of your ten projects are on Red’, I said, ‘What is that process doing for you?’”

So what is Agile, anyway?

“Is Agile a process?” asked AS, rhetorically, “No. Is there process in it? Yes.” Process helps a project fit into the overall programme, added FC.

BJ went a bit further: successful Agile is about business change, not about what happens in the software team. The Agile approach to a large project is to get just enough clarity to embark on it, which probably isn’t every last detail. The stakeholders need to have the confidence to deal with uncertainty, and that sufficient uncertainty will continuously be resolved as the project progresses.

[And with that I'm going to drop the capital A from Agile unless I'm referring to by-the-book developer-level Agile.]

RN then came in with his take on this. He works in a highly bureaucratic company where technology is driven by heavyweight specs, a focus by high level people on low level details, and delivered entirely by specialist (external) suppliers. Yet his board are continually wanting things delivered faster, to greater quality, and he sees agile as the solution to this. It means persuading his board to think about what they want at the right level — business value, not the contents of drop-down menus — and providing reassurance through clear, regular deliverables. It also means getting his suppliers to deliver in that manner. But all of that is entirely independent of unit tests, story cards, and so on.

I wondered if this meant a top-down mandate of agile was more successful than a bottom up one. AS clarified: it’s successful if it’s business-led, not management-led. LB linked this to Kotter’s 8 steps to successful change, and in particular the first step: there has to be a sense of urgency.

I confessed that our processes in the Guardian team today are substantially less religious (or rigorous) than they were during the time of our major rebuild programme. I used to be able to confidently say we are Agile and point to intensive pair programme, lots of story cards, and so on. Today pairing is inconsistent, automated unit tests aren’t used in non-critical satellite code, and teams don’t always work to iterations. I explained this changed because our business had changed. The emphasis is no longer on transforming our platform but now much more on innovation and on smaller projects with a much wider variety of stakeholders. This makes the control freak within me distinctly uncomfortable (AS had previously commented that in many organisations command-and-control provides confidence) but we generally deliver projects as intended and have happy stakeholders, so I wasn’t going to wade in to change it. BK commented that this seemed perfectly appropriate, and still looked like an agile business.

Seeing the vision, from top to bottom

Successful agile is something that needs to permeate the organisation, from top to bottom. It’s about delivering value, and the vision for what needs to be delivered must be seen and understood at all levels. Many of our experiences of projects going awry were also experiences of where the project vision wasn’t seen by the people doing the day-to-day work.

TC told how his IT department decided it was going to achieve CMMI Level 2. After two years they had accumulated 10 rooms’ worth of documentation, and their productivity had dropped like a stone. And yes, he could measure that drop in productivity, because the team essentially did nothing else for those two years than produce documentation. The board inevitably said: Never do that again. CMMI accreditation may be useful, but it’s got to be for a purpose.

FC talked about his troubled project in its third year. “I revisited the original outcomes document a short while ago, and I couldn’t see how the activities around me are ever going to achieve those outcomes. When I ask one of the team leads what they’ve delivered, and how much there is to go, I’m just waved in the direction of a vast wall of index cards.”

AS talked about a daily scrum he attended: a two-minute meeting in which the team lead got a task update from each team member while he stood with his back to the story card board. “I had to take him to one side and tell him that he needed to be constantly referring people to the project outcomes, not just getting task updates.”

He also told the story of a business manager who wanted a change rolled out midweek — unprecedented for the organisation, as it would involve taking the website down for two hours. This was flatly refused by the Head of Systems. When they discussed the matter the issues were this: the business manager could show that if the change rolled out in the desired slot the company was projected to make an extra £1m, and if the slot was missed there wouldn’t be another opportunity for six months; the Head of Systems, meanwhile, had a target of 99.9% uptime and two hours downtime would mean he’d forfeit his bonus. “Our business must organise itself so that we are all focused on the same goals.”

What did we learn?

You may ask what our learnings were. I can confidently say there were no learnings whatsoever because “learnings” isn’t a real word. But there were probably lots of lessons. Here are three key things I came away with.

1. Religious Agile, with an optional hothouse atmosphere, is entirely independent of a successful agile project. There are successful projects with and without religious Agile, and there are unsuccessful projects with and without religious Agile. This is underscored by…
2. Agile is about business change. It really only works when all the stakeholders focus on the same business-level goals, understand what their part in it is (and isn’t), can deal with uncertainty, and continually work to reduce that uncertainty exactly when necessary.
3. The business-level vision must be clear and permeate all levels. This is a corollary to the last point, but to me is significant enough to pull out. The people on the ground have to be able to relate all their activities to the business’s end goal, otherwise they will define success by other criteria — perhaps how well they adhere to a process — which are different from the actual success criteria.

Thanks to all the participants for making it such a stimulating morning.

In my spare time over the past few months I’ve been writing an app for my Palm Pre, and have finally got to point where I’m happy enough to release it. Palm Pre and Pixi apps run on Palm’s webOS operating system in HTML and Javascript. This is a summary of how I got on…

• Background
• Javascript++
• Development environment
• Execution sequence
• Callbacks and testing
• Events
• Releasing it

Background: A basic usability problem

I’ve always regarded Palm as the masters of productivity. David Allen based his Getting Things Done system on his use of a Palm Pilot. I stuck to my old Palm Vx as long as I could, as I lived almost entirely out of its task list application. I bought an iPod Touch when I had to ditch my old Palm, but while Apple makes beautiful products it doesn’t seem to care about productivity apps. (And that’s understandable — if you can look cool in Starbucks with a black polo neck sweater and a slim silver laptop, why should you care about productivity? Me, I don’t look cool in polo neck sweaters.) The iPod Touch and iPhone’s calendar app, for instance, only allowed a limited choice of event recurrence options; if you had a meeting which occurred on the 3rd Thursday of every month then that was just tough. There was no task list app as standard.

While I had migrated my task list to Remember The Milk (RTM) on my desktop, the Touch’s RTM app was for me a poor user experience. For one thing you had to navigate through several screens to get to your task list. Then you couldn’t see today’s and tomorrow’s tasks in one list — they were on separate screens you had to navigate back and forth between. And when you tapped to create a new task you couldn’t start typing “Get bread”, you had to first tap on the description field to select it — that’s just an annoying unnecessary extra user action. One lesson I learnt — from GUI Bloopers, I think — is understand what the user will primarily want to do and then absolutely minimise the work needed to do it. In a task list application I’d have thought having your tasks on the first screen might be obvious. Apparently not.

So I held out for the long-awaited Palm Pre to be my first smartphone. (And in the UK that was a very long awaiting.) Take a look at the Pre’s calendar app in this inevitably unnatural video run-through. Notice for one how the free time concertinas up so that you don’t miss knowing about appointments just because there’s a big gap before them. That’s an application made by people who really understand what their users need — or at least understand what I need.

Unfortunately, while the Pre does come with a very beautiful task list app it really is very basic. It doesn’t capture the ease of use of the Palm Pilot’s original (once again you have to drill down to actually see your tasks). And of course it was foolish to have hoped it would sync with Remember The Milk.

So, anyway, I wrote a task list app.

Javascript++

Palm’s webOS is based on Linux, and the basic programming environment is Javascript and HTML running in Webkit. Now I know what you’re thinking: isn’t that just what Steve Jobs announced when the iPhone first appeared, before the iPhone SDK existed, and wasn’t it unconvincing then? This is what he said:

We have been trying to come up with a solution to expand the capabilities of the iPhone so developers can write great apps for it, but keep the iPhone secure. And we’ve come up with a very. Sweet. Solution. Let me tell you about it. An innovative new way to create applications for mobile devices… it’s all based on the fact that we have the full Safari engine in the iPhone. [...] don’t worry about distribution, just put ‘em on an internet server. They’re easy to update, just update it on your server. They’re secure, and they run securely sandboxed on the iPhone. And guess what, there’s no SDK you need! You’ve got everything you need if you can write modern web apps…

That section of transcript came from Engadget’s live coverage, and they immediately added the following comment of their own:

Weeeeeaaaak

Well, don’t confuse that with what Palm has done, because there are three key differences. First, they’ve provided their own APIs which allow access to useful functions, including some system functions such as background alarms, network status, location, and so on. Second, you can package up your app into a single bundle and deploy it onto a device. Third, when an app runs it does so within a well-defined framework. So you can create scenes with their distinct logic and pass data between them, and the framework (called Mojo) handles the application lifecycle.

So Javascript is still the language, and HTML and CSS is still the rendering mechanism, but that’s just a language detail. You really are writing real apps on the actual device platform. It’s Javascript, Jim, but not as you probably know it.

As an example, here’s how my task list app exits from the scene in which someone has added or edited a task:

The Mojo.* Javascript classes are built in, and I’m using them to do a bit of logging and also to exit from this scene. The framework itself knows what the last scene was to return to, and the only thing I’ve added is some parameters to pass back.

Development environment

The webOS development environment and workflow is pretty good. It consists of

• Eclipse;
• The Aptana Javascript plugin;
• Sun’s VirtualBox; and
• The webOS SDK itself.

The SDK consists of

• Palm Pre and Palm Pixi images for VirtualBox (thus creating an emulator);
• Another Eclipse plugin which adds some webOS specific actions (deploy to emulator, create a new Mojo scene, etc);
• Some command line tools to perform actions such as tailing logs, creating an app package, deploying an app, etc;
• Graphical tools for resourcing monitoring and DOM inspection; and
• Sample apps to study.

What appeals to me about all this is Palm’s relaxed attitude to technology ownership. Write an IDE? Why go to the trouble when Eclipse already exists. Write an emulator? Run it in VirtualBox. And so on. Plus, the choice of Javascript as a development language ensures a very low bar to entry.

This relaxed (Palm would say “open”) attitude extends to deployment, too. Once I’ve packaged my Javascript app I can send it to the emulator or I can hook up my Palm Pre to my laptop with the USB cable and send the app down the line. No licencing, no cryptography, no UUIDs, just drop it on the device. That also means I can e-mail you the app package and you can drop it on your webOS device, too. As a result there’s been a lot of healthy activity around so-called “homebrew” apps — apps which aren’t available in the Palm App Catalog but can still be easily downloaded and installed.

I said the development environment was “pretty good”, but I have reservations. For one thing, the debugging and troubleshooting tools are a bit basic. But my more significant reservations are around use of Javascript as a development language. After coming from the nice, safe, statically-typed world of Java — having a dynamically-typed language with no safety nets of compile-time type-checking or intelligent auto-completion means I have to work harder. More of my thinking goes into typing rather than programming.

Also, Javascript is a language and platform that has its own quirks that stalled this non-expert developer, particularly when dealing with a large application…

Execution sequence

One thing I took a while to grasp was how Javascript handles its execution sequence. On the one hand we are told Javascript is single-threaded. On the other hand, it’s easy to have events fire out of order using setTimeout or in response to some user action. Eventually I worked out that Javascript will execute a sequence of code without interruption until it reaches completion, and then it will select another sequence which has queued up in the interim (from setTimeout, or a user action, or whatever). Overall this is really simplifies things, and it meant I could stop worrying about concurrency problems. (It also explained why I couldn’t write any code to successfully demonstrate a concurrency problem.)

However Palm realised that this is potentially bad, too, because a long-running routine can lock up the application — it will become totally unresponsive while the routine runs. So in order to preserve the user experience the webOS platform kills any routine that continues for more than 10 seconds without interruption. Unfortunately when this happens webOS doesn’t tell you (e.g. by logging a message) so you’re left to guess why your software has suddenly stopped. And the documentation of this “feature” is not terribly obvious, either. I spent quite a bit of time wondering what was going on when it happened to me. But eventually I discovered the cause, found myself in a small community of similarly-frustrated developers, and posted some sample code which showed the problem in action and also demonstrated that at least webOS doesn’t kill your whole application, just the long-running routine.

So I had to adapt my code to run in smaller, disjoint chunks. Fortunately by that stage I had become rather adept at dealing with…

Callbacks and testing

Most of the interesting Javascript extensions use callbacks, in particular XMLHttpRequest and the HTML5 SQL database API, which both return their results on callbacks. Initially I structured my code around XMLHttpRequest (more precisely, Prototype’s Ajax.Request wrapper) and I avoided asynchronous storage by putting all my data in cookies, which are accessed synchronously.

But eventually I felt I had to switch from cookies to SQL and convert my synchronous storage code to asynchronous code. Not only was that conversion quite painful, but trying to find a way of writing tests around so many, er, sequential asynchronous actions sent me down a lot of dead ends. I was using Yahoo!’s YUI test framework, which is quite elegant, but I had found the limit of its usefulness here.

In the end I devised a mechanism to break up my test cases’ code into asynchronous segments with pauses to aid sequencing. So a test would create a database table if it wasn’t already there, pause, clear down the table, pause, write some data into it, pause, and so on. Essentially I was pumping many of my tests full of race conditions (although it was fine in practice… generally) . What didn’t help was that to run the tests I now needed a browser which supported the HTML5 SQL database API, and on my Windows box that meant only Safari. Which, it turns out, is spectacularly disappointing: slow, resource-hungry, and oddly buggy. Test execution took three times as long, and it was only in a small part due to the little pauses I put in between database calls.

Events

But at least I settled on an approach. One area I never resolved satisfactorily was how best to handle events. Because of the way Javascript executes, or because of what my application does, there were a lot of “things that had to respond to other things”. I didn’t settle on a single way to manage those, and actually found myself using four techniques:

1. Writing event listeners. Various functions register with an object to show their interest in an event. The object adds each function to a list. When the event occurs the object calls the functions in turn. Here, the event happens and the functions are called synchronously.
2. A dummy function designed to be overwritten. This is a simplification of the first, where the object knows that it will have only one listener. When the event happens the object calls the dummy function. The interested code simply needs to replace the dummy function with its own implementation.
3. DOM events. The interested code listens for a custom event in the DOM. When the interesting thing happens the custom event is fired in the DOM for the interested code to pick up. Useful if the firing code and the listening code aren’t otherwise well connected.
4. Weird specialist class. Sometimes I found some actions depended on other things having happened first. For example, pushing out task changes depended on having first fetched a “timeline” ID from the Remember The Milk server, which in turn depended having an authentication token, which in turn depended on having an internet connection. To handle this I encapsulated the logic in a single class. It had a method called fire() which just went off and did the next thing it could.

Now having four ways to handle events isn’t necessarily wrong: arguably there are different kinds of events, and each kind may well benefit from its own design pattern. But I don’t have a handy classification of events, much less a mapping from them to appropriate design patterns. So perhaps here more than anywhere else in my code I felt I was guessing.

Releasing it

Undoubtedly my experience of writing a webOS application was a positive one: the very fact that I finished the project proves that. It is the most complete and release-quality piece of software I’ve developed in my own time. And now my smartphone has its missing app: Cloud Tasks. I can continue to live by my task list even when I’ve left my desk.

With some trepidation I’ve made the application available for others to download and use, too, in case they find it useful. The trepidation exists because it’s taken a substantial chunk of my time to develop and I really want to leave it now, and get on with the rest of my life. But I know there are plenty of people who use Remember The Milk in different ways, making use of features I’ve not implemented in the webOS client, and don’t want to implement, because I don’t use them myself. It’s not very community-minded to release something with minimal support. Instead I’ve chosen to release it under the GPL, so that others can develop it and any developments remain similarly freely available.

We’ll see what happens.