assert(false);

test/unit, the testing library used by Rails, has a really lovely named method: ‘flunk’ – for when you just want to flunk and test and cause a fail:

flunk ( [msg] )

One of the nicest things about Rails and ‘convention over configuration’ is that things are named well. After all, there are only two great problems in computer science; cache invalidation and naming things!

We mostly use agile project management methodologies, for example; Scrum. This reminded me of a story that someone told me at my last place, which illustrates both one of the issues surrounding project management, and a solution too. The example was ‘counting trees’…

So the story goes; there was a person, employed by a company to count trees in forests. They’d be flown over a forest and look at it, then note down how many trees they could see. Obviously this was an estimate, and the other point was that the person was never told if they were right or wrong or how many trees out they were, and the number that they supplied to the company was really very useful. The reason it was so useful was that the company had this person fly over forests with a known number of trees – say, 2000 – and then the tree-counter would give their number – maybe 3000. Doing this a couple of times, the company could work out how much this person was out; maybe 50% extra. So they would take the number given, and subtract 50%. The person wasn’t told how much out they were as then they’d start to compensate and the numbers would change.

The important part of this story though, in terms of project management of software projects, wasn’t that the person was estimating, but it was that the estimate was used in an effective way. The number wasn’t taken as gospel, and the number was used to calculate the real number. This number was the amount of trees, or the time it would take to complete a bit of software.

There are a couple of problems with estimating software projects; the estimate given is often used as the definite time to deliver and people’s estimates are different. The first issue that it’s often used as a definite is because the language used is flawed. It is an estimate, but if we’re estimating time, then it sounds fair to use that time to work out when you will deliver. If we use ‘complexity’, then this problem is removed. Also by using complexity, you can work out pretty easily how much time person x will take to deliver complexity y…. Something like:

(complexity * person_factor) + contingency = time to deliver.

So the ‘estimate’ given by the person would be the complexity, or ‘how hard I think this is’. By using feedback from other deliveries, you can work out how long it would take that person to deliver that complexity task, without asking for a deadline or a time estimate. By using a baseline, you can work out a standard person_factor, and then improve that for a particular person or team. In fact the person_factor could also include information about their experience too, so a junior programmer, or one new to a system, would take longer than a senior or someone that wrote it in the first place.

In my morning walk to work, I was idly thinking this over, and as I’d been playing my soprano sax for an hour or so this morning, I realised that there was some parallels to this idiom and playing a musical instrument. Imagine you’ve wanted to play an instrument, and you finally get one to play. It’s shiny, complex, fantastically interesting and you read everything about it – playing it for hours a day. I guess this would be a new relationship. You practice scales and arpeggios, even though essentially they’re quite boring. Eventually the relationship either works, or it doesn’t. The relationship with your instrument is over and you’re left with memories and a peculiar shaped box in the loft… Either you lost interest, or didn’t put enough work into it.

Putting in the effort, time and care to play something is worth it though. There is a point at which you transcend just playing an instrument, to being able to express yourself and your emotions through the instrument. You’ve put all the ground work in, you’re dedicated to the instrument and you find that the effort you put into it rewards you with the most amazing way of expressing who you are, and expressing your instrument too… You can get lost in the magic and moment of just playing it, people listening to the music you’re playing are affected. They feel it too, albeit in a passive way. That feeling of familiarity you will gain, doesn’t breed contempt, it allows you to express yourself! It’s a familiarity that you understand, but you’ll never stop enhancing.

Personally, I favour playing different instruments, although this in itself takes more effort. You must be able to give each instrument time and focus. You need to be more dilligent. Although theory learned by playing one instrument is transferrable to other instruments, in much the same way as things you learn in relationships.

So, focus on the instrument or instruments you choose, study hard, practice, don’t become lazy, and let the music play!

Recently entering into the common lexicon is the phrase ‘turn it off and on again’, normally describing a computer that has broken somehow, and nobody can be bothered to work out what has happened, if it’s possible to anyway. So, turning it off and on again will restore some past state in its entirety, allowing you to carry on as if nothing bad has happened. Oh look, I just un-killed a gazelle!

Is this the right way of doing things?

Smalltalk is a programming language I have a lot of time for. Most programming languages seperate ‘state’ from ‘code’. So a program boots, it gets told what it is by loading some state, then it springs into life. Assuming the program could understand the state, then it’s all ready to go. Why not kill it with a big frickin’ laser? Load it again, and it’s in the same state as it was when you killed it. Over and over you can restore state. Ok, so being able to do that isn’t inherently a bad idea as it’s one of the powerful things about computers, that you can ‘magically’ change things. One of the bad parts comes when you forget to save something, or something crashes. You don’t have a problem if something is written on paper; it doesn’t inexplicably vanish before your very eyes – unless you’re a 8 year old ‘spy’ with one of those ‘invisible ink’ kits.

Smalltalk, and a number of other systems, were based on an ‘image’ which stored state. Similar to a ‘core dump’ which some may have seen when their computer barfs a load of crap onto the screen in the blue-screen death throes. Except for Smalltalk images are restartable, not just debugging data.

These kind of systems did require a larger overhead, so some weren’t convinced. But what would the electronic world be like now with solid state? Anything you do is fixed, and recoverable. Turning the machine off and on again would still present you with the same state. No get out, no turning back time…

Maybe programmers would be a bit more careful when hacking away at some wood, or is having a get-out clause a good thing?

Examples of dynamic typed languages are Ruby and Python, although there are a lot. It seems that Microsoft, in my humble opinion, have seen another ‘shiny object’ that they’d like to add to their language spec, so they’re creating a kludge to add it. Sometimes though, restrictions are a good thing…

If you take, for example, a team of programmers that understand a paradigm. Using a different paradigm ‘just because’, isn’t generally a Good Idea(tm). I consider real programming to be a creative process, no different to painting or sculpture, and limits are always good in any creative process.

I can hear people balking at this idea, that we would impose limits for the sake of it. Well, if you had a studio and were to create some ‘art’, and somebody asked you to ‘create something’. What would you come up with? Defining limits beforehand really focuses the mind to what you’re doing, and the starting-point of; “using oil paint and canvas with only 4 colours, represent how you feel about rock music” is much more emotive, inspiring and creative.

Of course, what I mean by this glib example is that often restrictions *inspire* the creative process, not hinder it. Constantly adjusting something to be a ‘one size fits all’ dilutes it..

It’s often said that C takes an hour to learn, and a lifetime to master. C is very small in its implementation, although the power is all in its simplicity and limits…

Maybe historically techs would have come in at the last moment before a run, and put some lights up and rigged the sound etc, but we take a very different approach and form part of the ‘creative’ team from the very start. During rehearsals, the lighting designer (me for the last production), stage manager, wardrobe, sound etc will attend rehearsals and provide creative input from the start. It’s true that we need to operate in a technical environment, but the real work is in using the technical environment in a creative and artistic way.

Take lighting design for example… The principle is for ‘illumination’, ‘area selection’, ‘sculpture’ and ‘atmosphere’. Illumination to make sure your actors are seen, area selection to draw the eye of the audience to the areas you wish to, sculpture to provide good shadow detail on an actor’s face to aid the audience to be able to read expression better and atmosphere to create the mood, feeling and ambience of the design.

Of course, you could just follow the prescribed ‘rules’ and point a load of lanterns at the stage, but lighting designers follow a creative process to put in emotion, feeling, aesthetics and a lot more into the design. it’s true that a lighting design can move people emotionally, and using subtle ‘subconcious’ changes in lighting, you can make an audience member feel more anxious, happy, sad and a lot more.

‘Tech’ is often used as a catch-all for this kind of work, and similarly software development, but it’s only part of the real whole. Considering a tech to just be doing ‘technical’ work is a mis-representation of what they really are or should be doing. In the same way, considering that developing software is an entirely technical task is the same. We should still be using the same creative skills in technical tasks.

The difference is when a ‘tech’ uses their technical skills as a method to deliver a creative solution…

It is important for tech to be nice.

In the real world you write on a piece of paper; and then you have something tangible. To introduce the paradigm that you then have to save the work you’ve done was something introduced by computer systems, and has carried through since. A much better paradigm is to have everything you enter into a document for example, or everything you edit on a photo to be automatically saved. Of course saving a copy is fine as you can save a copy with new changes. The power of computers can be used to ‘turn back time’ to a previous version of an item, even before some destructive changes.

A few tools use this paradigm, such as Aperture or OneNote – just to pick two at random. Whatever you do to an image in Aperture is what happens to the image. You don’t have to edit, then save. Similarly, you can type something into OneNote, and close it immediately – what you’ve typed is automatically saved. Should you want to ‘save’ a document, you should be able to ‘file’ it, which is the way I’d prefer to work.

To paraphrase a comment from my father when I suggested he tried using Linux instead of Windows on his next upgrade: “…but I like Windows – it’s taken me ages to learn”.

Bad design establishes new patterns of work, and human beings – being the adaptable creatures we are – learn to adapt and live with things. This isn’t to say that bad design is acceptable. After my dad started using Linux, he found it much more intuitive for him, and liked it. “Seems to be doing what I want” was his reply when I asked him. Of course the argument isn’t that Windows is bad and GNOME Desktop is good. Of course there are bad designs on many systems.

It’s important to challenge things, and ask *why* am I doing it this way. Is it because it’s the way it’s ‘always been done’, or can I do something different…

During the first workshop I attended; Entertainment meets the Geek presented by Eric Lindstrom & Steve Jelley, the speakers talked about how sites were positioned in ‘the market’. Now their perspective was from pretty much from the point of an economist, but they had a graphic showing how sites fitted into a matrix of entertainment, social networking etc. This matrix was a compass that showed the sites as they fit into various types of use and design. 

The important thing, I understood from the session, was to understand where you fit. It’s also important to understand that they were presenting the delivery of digital media through a hub site – which is positioned in a particular part of that compass; ‘entertainment and information’-related.

It all reminded me of something I overheard on the train a little while ago, and made me smile. There were two guys talking, and one of them asked: “Have you got a YouTube page?”. The other guy replied “No, but I’m going to get one…”. “You should..it’s loads better than MySpace” was his reply.

Now YouTube wasn’t positioned as a social networking site, although this guy clearly didn’t share that opinion. To him it was a place he hung out, entertained himself, probably argued with people and added his own content and opinions to the internet. We spend a lot of time designing a ‘tool’ for a particular task, and then realise it doesn’t really work in the way we intended, or that users don’t respond to it in the way we thought they would.

I had the chance to talk to the guys after the workshop and I related this story to them just as a humourous aside, but I realised then that we spend so much time postulating over ‘social networking’ sites, ‘entertainment sites’ etc, that it’s easy to forget that they’re about people, and empowering them to experience the site and feel part of it. This is obvious in the threads of ‘video responses’ on YouTube, where – virally – people respond to a particular video with their own video, and so on…

An interesting point they made though was that more YouTube content is viewed off-site than on-site, yet YouTube still remains dominant. You don’t have to explicitly visit the site to view content, and can present YouTube content on your own site or page. The ability to ‘take a part of the site away’ and embed it in your site is particularly powerful, and one of the keys to success of YouTube (although lots of sites tried to do the YouTube thing, but at the wrong time: before broadband ubiquity).

It’s the lot of a person that works in the industry to think about these things, but we shouldn’t forget that only users know how they want to interact with a site. Users don’t consider YouTube to be too different from Facebook in that they can link up with friends, entertain themselves and have an effect on the site.

So is this about designing experiences rather than tools?

Most of my time is spent asking why something is aesthetically pleasing, or a great experience – so I thought I’d start this blog to ask exactly that.