Jonathan Melhuish

It’s now generally accepted in the software community that the best way to develop software is iteratively, for the simple reason that it’s really hard to design anything perfectly, especially if it’s for somebody else.  The best we can hope for is to create something small that we think the customer wants, show it to them and then change it until it’s what they actually wanted.  It’s a bit like finding your way by heading in roughly the right direction and then correcting your path whenever you find a landmark – rather than looking at the compass, closing your eyes and walking blindly until, inevitably, you fall off a cliff.

So I find it surprising that nobody seems to be pursuing a business model that closely fits this model.  Instead, most people seem to be sticking with some variation of the old-world “make it, box it, sell it” approach, or perhaps a subscription model where all that’s necessary is to keep the customer happy enough that they don’t go elsewhere.  Or, of course, the Free Open Source Software (FOSS) model – give it away and rely on support contracts, goodwill or magic to pay the rent.

Although the FOSS model is the hardest to make money with, it does have a lot of advantages – particularly that you’re much more likely to get free help with development and testing.  In fact, this eager and helpful user community is perfect for providing the constant feedback needed for an Agile development process.  If the user finds a problem with your software or has an idea of how to make it better, they’ll let you know about it – especially if they know it has a good chance of getting fixed.

Unfortunately, therein lies the problem.  With many Open Source projects there are, understandably, relatively few skilled developers that are prepared (or able) to donate large amounts of their time for free – so user’s requests are most likely to go ignored.  As much as they love the idea of FOSS, they’ve got to pay the rent somehow; most likely by sitting in front of a computer at work.  It takes a pretty hardcore geek to come home from a hard day’s programming and want to spend the evening doing the same.  And even if they do, they’ll probably choose to implement a new whizz-bang feature than fix a bug in the User Interface.
I suggest therefore that putting an economic mechanism in place to allow users to financially support the development of Open Source software.  I envisage that it would work something like this:

• a user describes a problem they are experiencing or a way in which they would like to see the software improved, and sets an initial bounty amount, payable upon successful completion
• an expert works with the user to clarify their requirements and to create a series of acceptance tests , and claims some or all of the original bounty
• once the user has agreed that the tests specify their requirements exactly, other users can contribute to the bounty
• developers can then choose a bounty they wish to hunt
• upon successful completion (when all of the tests pass), the developer is paid and the users receive the modified software
• the modifications can, at the discretion of the project community, be incorporated into the normal release of the software, for the benefit of everyone

I suggest that these economic mechanism would not only allow greater development effort, but lead to greater user involvement and, ultimately, better Open Source software.

Test-driven development seems like a great idea, but when it comes to actually spending the time to write the tests, it seems like a drag. Of course, it’s not something that can be easily automated – tests should essentially be tightly-defined, programmatic versions of the design, and until computers get really great at natural language comprehension (and, in many situations, telepathy), they’re never going to do a good job of building what you want.

But armed with an executable definition of your goals, surely the computer could at least have a stab at implementing them? It could simply try running your tests against code libraries such as chunks of existing Open Source software – or, more usefully, try piecing together parts from several different sources in the hope of creating something executable that meets your tests’ assertions. A useful starting point would be to search unit-tested software to find sections of code that satisfy similar unit tests.

It would still require a lot of trial-and-error and hence be quite computationally inefficient, but patterns should begin to emerge quite quickly – which combinations of code satisfy the compiler and which sections of code are most likely to satisfy a given assertion. Of course, it would probably still take a lot of computer-juice, but computers are cheap – you can rent 500 powerful-ish PCs on-demand from Amazon EC2 for as much as the average developer. So if an army of 500 dumb PCs can write half the code, you break even – not to mention the morale benefits of taking all the drudgery out of coding and just leaving the challenging bits for the human to fill in.

I envisage it working something like this:

• design what you want to achieve this iteration, in collaboration with your customer and colleagues
• write the tests and interfaces, preferably with one of your colleagues doing some sanity-checking
• have a nice lunch, whilst your tests and interfaces are sent to the on-demand compute cluster
• come back to find that half the project has been magically coded already
• fill in the blanks, which are likely to be the parts specific to your project or particularly challenging
• whilst you code, the computer could display changes or blocks of code that you can easily include that satisfy the compiler and some of your test suite (although the User Interface obviously needs some thought – we don’t want the programming equivalent of the Office Paperclip!)

This would essentially give a new way of programming – half-way between declarative languages where you only specify the goal and imperative languages where you must specify every step. By specifying the goal and then guiding the computer in creating a solution, we create a hybrid that has the elegance of the former with the power and flexibility of the latter.

Our modern lives are full of distractions from many sources, in person, on our computers and from a multitude of other devices. It can be very difficult to reach a “state of flow”, to stay there for any period of time, and to regain that flow when interrupted. Here’s some ideas of how technology could support that.

Single status… everywhere
In some limited way, we already have status notification built into some software, such as instant messengers, telephones, etc. But realistically, who sets their IM status to offline, their phone to silent, their notice on their door to “Do Not Disturb”, etc. every time they want to get some work done? Usually people either always leave it “online” or “busy” depending on their personality. This lack of accurate status has an effect on the “sender” too, though – they might wait to grab you in the corridor (if you work in the same building, that is) or use something like email, which takes more time and is often a less effective way to communicate.

What we need is two things:

• an easy way to set status
• status “syndication” across all software and devices for that user

I think the ideal way to set the first would be by a program that learns the relationship between user status and easily-collected information such as window titles, key-press frequency, mouse movement, webcam, audio, etc. That might sound all a bit complex, but it shouldn’t be hard to make something that can have a good guess at the difference between me staring wide-eyed at Eclipse while bashing code and sitting back drinking tea whilst I watch YouTube. Then, armed with that information, it should broadcast my status to anyone or anything that wants it.

Pounce!
The way to encourage people to keep their status fresh is to offer them tools for doing useful things with it. One simple one is a “pounce” facility for any real-time communication: when both user’s statuses are set to “available”, alert both of them so that they can talk. It’s something we do so often yet is quite poorly handled at the moment.

Audio To-Do
I don’t know about you, but for every one thing I do, I seem to have at least two or three more ideas of things I’d like to do. Often these are quite simple little things that hardly seem worth writing on my To-Do list. The act of creating a To-Do item would break my flow and also turn my To-Do into a mess. So how about a simple voice recorder where I can hold one key and my recording gets added to the top of a “stack”. I can click to hear the recording (and perhaps see a screenshot and webcam capture to further jog my memory) or to remove it when it’s done. Obviously navigation is an interesting user interface challenge, but the idea is that you generally just pick the next thing from the top of the stack – if you have some reason to put it off until later, you should probably put it on your To-Do list. I have some thoughts about how To-Dos should be organised, but that’s another story.

Rewind button
So the above didn’t work and something has interrupted you, or you’ve lost your train of thought. If you were working in the real world, you’d probably have lots of artifacts to prompt you – bits of paper, tools, materials. But on your computer’s “desktop”, you’ve probably got a huge pile of things that’s relatively hard to glance at and many of which have nothing to do with the job in hand. So how about being able to “re-wind” what you were doing before the phone rang? In a few seconds, you can see which applications you were using and what you were typing – and it probably won’t be long before you’ve found your flow again.