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.

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?

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.

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.