This entertaining article supporting test-first development has been playing on my mind. The article is beautifully written so it is easy to see the assumed context of working to deadline on well specified problems, most probably in a commercial environment. It saddens me though that we accept this implicit context across all discussion of software development practice all too easily.
Here’s a nice illustration from the article, which appears under the heading “Prevent imagination overrun”.
Diagram © lispcast, some rights reserved
So there is a fairly clear reason not to write any tests for your code — you will take in more of the problem domain without such directive constraints. What you are left with will be the result of many varied transformations, and be richer as a result. You might argue that this is undesirable if you are coding a stock control system to a tight deadline. If you instead take the example of writing some code to generate a piece of music, then you should see my point. The implicit commercial context does not apply when you are representing artistic rather than business processes as code.
In fact this notional straight line is impossible in many creative tasks — there is no definable end goal to head towards. A musician is often compelled to begin composing by the spark of a musical idea, but after many iterations that idea may be absent from the end result. If they are scoring their piece using a programming language, then there would be no use in formalising this inspirational spark in the form of a test, even if it were even possible to do so.
What this boils down to is the difference between programming to a design, and design while programming. Code is a creative medium for me, and the code is where I want my hands to be while I am making the hundreds of creative decisions that go into making something new. That is, I want to define the problem while I am working on it.
While “end user programming” in artistic domains such as video and music becomes more commonplace and widely understood, then perhaps we will see more discussion about non-goal driven development. After all artist-programmers are to some extent forced to reflect upon their creative processes, in order to externalise them as computer programs. Perhaps this gives a rare opportunity for the magic of creative processes to be gazed upon and shared, rather than jealously guarded for fear that it may escape.
This post is distributed under the attribution share-alike cc license.
Very interesting analysis and good points — though I was not trying to contrast TDD with coding creatively. What I was trying to show (which perhaps wasn’t clear) was that without your tests, you could work on things that are totally unimportant even to you creatively.
Like an a painter who spends hours of his time mixing the right color for all the possible vegetables (anything in the produce aisle) that could be in his still life before even choosing the three vegetables he will eventually paint (tomato, bell pepper, potato). He was following his imagination, meandering around the color space. If the actual color he wanted had been defined a little more, he would have had a straighter path to follow.
I’m not saying that exploring different colors is unimportant — but it could distract you from what is important to you.
Thanks for the reply Eric!
I was not trying to contrast TDD with coding creatively either. I was contrasting coding under commercial constraints (problem specs, tight deadlines, maintability, etc) with those of a certain kind of artist (no specific goals, loose deadlines, fast iterations, focus on end results, etc).
So I didn’t have a problem with your post, which I agree with in the (I assumed) context of commercial ‘quality’ code. Rather I have a problem with the implicit context that it is written within — the accepted norms behind most discussion I see around software development.
I don’t think I like either of your artist’s colourspace searches. I prefer a search where the initial ‘pure’ idea of a colour is specified and attempted. Then the artist observes what they have done and decides whether it is good or not. They then react by adjusting the colour and continue around the feedback loop until they decide to stop, and start painting (or wash the paint away and try again).
I think this iteration differs from TDD because the success of the process is based on how the end results deviate from any tests, not on how well they conform… Aberration is key to creativity. Also as I say above, these specifications are created and discarded throughout a creative process.
Of course these concerns certainly aren’t unique to artists and musicians — *all* coding involves creative activity. However I would claim that TDD aims to move some of the creative decision making out of the code and into test writing, and cite artistic programming as an example of where that might be a bad idea.
Right. I see. A Unit Test maintains a minimum assurance of functionality. You can’t say how well it does conform to what you want.
I agree completely. TDD is a discipline to support what can only be considered an early form of software development. We are years away from working at a level where you don’t have to worry about regressions.
Wouldn’t it be nice to write some code, see it working, then decide whether it worked right?
Very nice diagram and commentary. Thanks for the discussion. What would an artistic debugger look like?
Hey Burak,
The diagram is nice, but was from the original post by Eric, I’ll add clearer attribution.
Artistic debugger — good question, maybe software artists should be like well practiced guitarists, and never make bum notes 🙂 More seriously, I’m not sure what I’d want beyond existing debuggers (gdb etc). Do you have any ideas?
Does any artist create a masterpiece with one tool?
When I’m crafting software I use many tools throughout the development process. At one moment I may work on some simplified UML diagrams (simpler than UML Distilled), then some TDD, then maybe back to UML diagrams, a spike, TDD, use cases, UML, TDD, etc. I even bounce from working on some high level abstractions one moment then down to the lowest levels the next moment. The process I use is hard to describe just as it’s hard to describe how to paint a masterpiece.
I never use the tools in the exact same sequence from project to project. I use one tool until I get stuck and then switch to another. As each tool provides a different prospective to the problem at hand. With each iteration of a tool the solution to the problem becomes clearer and clearer until a new masterpiece is built.
So yes, TDD is no silver bullet, but it’s one of the most insightful tools I depend on. In fact I would consider it the most valuable one. Next would be simplified UML diagrams. Then any of the other of dozen or so tools I use would come next in no particular order of preference as they play a much smaller role in my development process.