Scrapheap Challenge at SPA2007, part 1.
Ivan and I ran our Scrapheap Challenge workshop again at last week's SPA conference. This time we were hoping to get the participants to invent their own challenges in an Improv-style brainstorm at the start of the workshop, a section we called "Who's Line of Code is it Anyway?". Unfortunately this attempt was a bit of a flop, possibly because everyone had to get up early on a Sunday to get to Cambridge while the train services were cancelled and so weren't in a very up-beat brainstorming kind of mood, or more probably because neither me nor Ivan had any experience of Improv whatsoever.
Luckily we had some pre-canned challenges in reserve, so the workshop wasn't a total washout:
- A Presentation Package. I want to be able to type in a list of sentences that summarise what I will talk about during each slide of the presentation. For each summary the tool should suggest pictures that illustrate the point I want to put across and let me pick one picture per slide to build a presentation. It shows that presentation full-screen.
- A Christmas Quiz Game. I want a quiz game to play at Christmas. The most important feature is that I don't want to have to prepare the quiz beforehand. The second most important feature is that the quiz should help avoid family arguments by keeping scores. Exactly how the game is to be played is part of the challenge. What is the quiz about? Is there a quizmaster? If not, how do players make their guesses? Do all players try to answer the same questions or do they take turns?
- Real-time Sloppographer. A tool for developers that show them if they are making the code better or worse as they work. We ran over time a bit on tea-breaks before this challenge so the participants only had half an hour to produce a solution instead of an hour and a half.
This time the challenges were more open ended and the applications were more interactive than the workshop we ran at PoMoPro. Dynamic languages that played well with other software and webservices won out by a slight margin - Perl being the most successful - but Unix pipes-and-filters were not very useful.
Here are what the participants found helped their efforts:
- Break the problem into parts
- "Luck" in finding components
- Focus on the minimal functionality and grow the system from
there.
- Incremental, small steps
- Always keep the system working
- Don't be fixated on the technology
- Start with example code and change to fit your needs
- Find components that do more of the problem: are a better fit
- Divide the research task (e.g. finding useful components or services) between the pair
- Keep it Simple, Stupid!
- Code examples that are easy to find
Here are what the participants found hindered their efforts:
- Version incompatibilities
- Environment dependencies
- Difficult to find what you're looking for
- Descriptions of components or services not good for getting a quick idea of what the API does
- Confusing language (gobbledegook) used to describe the API.
- Leaving integration to later
- Bad example code
- Closed formats
Normally we work through the challenges before running the workshop to make sure they are achievable in the time available. However, we hadn't done so this time because we were hoping that we wouldn't have to use them. On the plus side, that meant we were able to participate in the challenges during the workshop. Ivan has already written up our solution to the Real-Time Sloppographer. I will write up our solutions to the Presentation Package and Quiz Game in later articles.
Update: I have published our solution to the Presentation Package challenge.
Update: I have published our solution to the Quiz Game challenge.