Read on and leave a comment
or return to our portfolio.

Archive for April, 2008

25 Apr 2008

by Noel

Know Your Customer

Watch the battle below and guess who won: Bboy Baek (on the left), or Bboy Born (on the right).

I expect most people would say Baek. He does all the crazy stuff, right? Looks hard and impressive, while Born is just spinning around on the floor most of the time. However, I expect most bboys would give it to Born, who in fact did win that battle. Why? Born sets are well constructed. He has a nice mixture of toprock (the stuff standing up) and downrock (the stuff on the floor), and mixes up the tempo with those pauses at 1:27 and 2:40. Baek has great moves, but he just throws them down without any real set up, and he messes up some of them, like the hand-hop at 50s and the flares at 2:14. Also, when the music changes he just wanders around the stage, not dancing.

I like this video as its reminds me of an obvious but sometimes forgotten point in software development: experts are not everyone. Expert users are often the most vocal, and when desiging software it can be very easy to let their concerns dominate to the detriment of less skilled but more numerous users. Sometimes a new feature is just creeping featurism, but sometimes it’s core to the target market. The only way to tell the difference is to constantly keep in mind who the customer is. Startups in particular can have difficulty with this, as by definition a startup doesn’t yet have any customers. Common advice to startups: scratch your own itch and dog fooding, can be seen as mechanisms to put the developers into the mindset of the users. 37Signals advice to build less is appropriate when targeting the general public. Extreme Programming mandates an Onsite Customer. We’re lucky at the moment to have constant contact with our customers, and regular feedback from them is important make sure we develop software that is useful for them.

Posted in Business | No Comments »

21 Apr 2008

by Noel

The Biographicon

The Biographicon is a very pretty web site of user contributed biographies. It is also written in Scheme, and here’s one of the developers discussing how it was done.

Posted in Web development | No Comments »

6 Apr 2008

by Noel

Science and Self-Directed Learners

Over on LtU I was asked how to help beginning programmers become self-directed learners. I have taught a number of students, but not in a context where I’ve been able to really make a difference in their programming practice, so I don’t have an answer to the whole question (though my instinct is that the apprenticeship method is the right way to go). However I try to teach one process that I think is an essential step towards becoming a self-directed learner. That process is the big idea called science, and I’m not talking about lab coats and chunky glasses

When working with students I always get asked what the result of evaluating some piece of code will be. What I tell the students is toask the computer via a test case or the REPL. Testing ideas by experimentation is science in its simplest and most immediate form, and a crucial step in developing the student’s ability to solve their own problems.

Application of science to programming is not restricted to students;test-driven development is science. So what is science then? I simplify, but basically three things: a theory to test, an experiment to test it, and a standard of proof (note we can never truly prove a theory, just simply not be able to disprove it). This is exactly when a unit test is. For example, a Scheme programmer might pose the theory “the string->number function will convert strings padded with whitespace characters to numbers”, formulate the experiment(equal? (string->number “ 200”) 200), and have as the standard of proof the boolean output of this single experiment.

When most people think of the scientific method they think of the lengthy and expensive double-blind trials used in, for example, medical trials. A really important point is to realise that when you do science, you choose the standard of proof. For example, as most computer programs are deterministic a few tests can be sufficient to show a property holds. When dealing with a concurrent program, or some other non-deterministic system, you may need to be more rigourous.

So there we have it. All programmers are scientists to some extent, though they might not know it. We can extend the use of experimentation to answer other questions, such as determining if productivity is affected by changes to software development process. Doing this in a lightweight way is the intention of the Simple Improvement package, though I haven’t had the time to get that library to a really useful state. Perhaps in a later post I’ll go through the ideas behind it. In the mean time, get experimenting (lab coats optional).

Posted in Code | No Comments »