Here’s an interesting response to my earlier post about how test driven development does not necessarily apply to all problem domains. Ocean has some insightful things to say about creativity, but mischaracterises me as seeing constraints as undesirable.
In fact I agree that constraints are essential to creativity. Constraints form the walls of the creative space that a creative agent (here, the programmer) searches within and pushes against. My complaint was not against constraints in general, but in the assumption that when we’re talking about development, we’re talking in the context of writing quality assured business software.
Lets take livecoding as a example. A programmer stands on stage, and has to write some software to generate some music so that the people waiting in front of them has something to dance to. Imagine looking up from your code editor to see the expectant faces above. This particular problem domain is one I have found myself in as a member of slub, and already has plenty of constraints to guide my creativity without adding the extra artificial constraints of starting with some unit tests.
[edit: see comments for fine counter-example from dave (a fellow slub member)]
I imagine your audience in that situation would act as the same strong feedback mechanism that unit tests provide to most programmers. In the most general terms, I think it’s important to acknowledge the importance of feedback in programming otherwise you start to fall into something like bikeshed thinking.
The audience is indeed a feedback mechanism, but both an immediate and informal one — so very different from unit tests.
Also I’d be very surprised if most programmers used unit tests. Unit tests introduce nothing but needless tedium outside of very particular situations.
Both here and in your blog post, you are arguing against a straw man. Nowhere have I claimed that feedback isn’t important in programming, constraints aren’t important to creativity, or that programming is about construction rather than creativity.
A very interesting set of articles. I seem to spend a lot of time trying to convince people programming is a creative business. It’s interesting that fields such as architecture seem to be close, yet are treated so differently.
This confusion has it’s upside – it’s made a lot of money for people who sell books on managing programmers.
There is nothing wrong with unit tests – it’s just using them appropriately. I use them, not just in code where the needs are obvious, but in exploratory and artistic code as well.
The act of writing of tests can help you understand what you are doing. The key is to write them as you go along, and keep them running all the time. They may not be the most interesting things, but they do make code more flexible, as you have more confidence in changing things later on.
For example of my use of them, see test-lowlevel-graph and test-daisy-graph in: http://www.pawfal.org/flotsam/daisy/daisy.scm
Wow, OK… So you’re saying (and demonstrating) that it’s possible to both follow your imagination and write unit tests? In that case, how often do you find yourself going back and modifying/deleting old tests?
“So you’re saying (and demonstrating) that it’s possible to both follow your imagination and write unit tests?”
Yes. I use my imagination, I write a little unit test, I write some code, then I run the test to ensure it does _exactly what I wanted_. Even better, I can ensure that my imagination hasn’t _broken everything else_.
But this is when I’m _developing_. Writing ephemeral code for live purposes is _not_ that.
I find unit tests useful for making complicated code simpler to play with. I think it’s all about levels of ambiguity with the purpose of the code you’re writing. Some code is written to get a job done, some code is written as a creative exploratory act. There isn’t a fine line between these roles, and sometimes (most times unless you have a good spec) code moves from exploratory to a purposeful state as time progresses. In this context I slot in unit tests when code becomes more purposeful, and it helps to solidify things in my mind. I don’t go back and modify the tests much, but they go off when you’ve changed something which causes an assumption you’ve made to be false in dependent code. I don’t use them much though – it’s quite a new thing for me in this sort of code.