My entries for the SPA 2007 competition. Update I won a bottle of wine!
We actually did this on our project, with great success. Working test-first, in iteration 1 we developed a test to ensure the lightbulb had actually been changed. Development work in this iteration was obviously somewhat hampered by having to work in the dark but changing the bulb at this early stage would violate the Test-Driven Development ethos.
Our test consisted of a light sensor that lit up green to indicate there was light and red to indicate there wasn’t. When we first ran the test we were surprised to see the red light lighting up very briefly, but then going green. Initially we suspected a problem with our test code, but after printing it out in braille and feeling our way through it carefully we were unable to find any errors.
We decided to involve the web development team, who work next door. In iteration 2, we took away their light bulb to allow them to work on the problem in uninterrupted darkness. During this iteration we think we probably worked quite closely with them to resolve the issues with the test but it wasn’t always clear how many people were actually in the office.
During our retrospective someone - we’re not sure who - suggested the test was interfering with itself. Lightbulbs went on in our heads. I’m speaking metaphorically of course. Not the system metaphor, which is an XP practice we don’t follow. I’m just using an ordinary metaphor.
Anyway, we knew we needed isolate the test input from its output, so, during iteration 3 we put the output lights for our test next door, and their output lights in our room, and got them to call out what the results of the test runs were. We got very confusing results during this phase of the project and there was quite a lot of shouting.
In iteration 4 we finally got the test failing as it should and tried plugging the good bulb from the systems team into our socket. The test passed! Even though you aren’t really supposed to, we also did a quick manual test using our eyes to see things and everything seemed to be working ok.
Since we’d done the Simplest Thing That Could Possibly Work, we felt pretty good and went to the pub. The web developers were less happy though and pressed us to implement a second lightbulb because it was still dark in their room. We explained that duplication is bad - Don’t Repeat Yourself we said. Why do we need that duplicate lightbulb? It pointed to a deeper problem with the design of our office, which clearly needed refactoring to remove lightbulb duplication. The builders arrived in iteration 5….
None. Although several competing framework designers will attempt to tackle the problem, actually changing lightbulbs is not the primary focus of the framework designers role. It will require an additional 2 agile software developers to download all the frameworks, figure out the best one and actually get the bulb changed, submitting bug-fixes to the framework as they go, and finally making a conference appearance to explain their 12-month success story.
We need a DSL for expressing the design of DSLs. The only keyword is “meta” but you can use it as many times as you like.