Archive for February, 2007

Automatic programming… well, almost

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.

A state of flow

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.

It’s easier to be first (and good) than to be better

“A Minnow on a Mission” - that’s a mighty odd title for a blog about the environment and vegetarian cooking, you’re probably thinking. Actually, the original intention was to blog about the online music community we’re starting, Flukebox. But as I have a habit of doing, I got distracted by all manner of other things.

That’s not to suggest that nothing’s been happening in Flukebox land. A little while back, Last.fm’s added two of our key features, downloads and concert listings, to their service. Then one of most enthusiastic and knowledgeable supporters, Andrew Dubber, wrote a blog post that wished our service a “swift and inexpensive failure” - with the smallest of get-out clauses in case I started crying. These, and a few developments from other competitors, made me increasingly worried that perhaps we risked being a small fish in an overcrowded pond. A quick look at some of the biggest Internet success stories in recent years (Amazon, eBay, Skype, etc.) shows that not only did they do something well, they also got established before anyone else had come up with something worth using. So, after a week of feeling decidedly moody and angrily throwing lots of ideas in the bin, I’ve emerged with a new plan.

Flukebox was always a reaction to two technologically-driven trends:

  • the reducing cost of digital recording technologies are encouraging more people to record high-quality music
  • the Internet is making it practically free to distribute music and is changing patterns and methods of consumption

Just like everybody else, we were focusing mainly on the latter trend and just accepting that the first would provide the raw material for our service. But why? Many musicians make music for the fun of it and don’t really care if anybody hears it or not. A bit like the way I write this blog as a way of getting my thoughts straight and keeping a diary, and am pleasantly surprised when I find somebody has actually read it.

A quick and informal survey reveals that people are mostly just using email and discussion forums to collaborate with other musicians online - if at all. Surely we can do better than that? Making music is different in several important ways - so why do we basically only have tools for doing it on a single computer? Why is there no proper online community for musicians?
Why indeed.