Some time ago I read an interesting article by musician Brian Eno titled “Composers as Gardeners”.
The basic idea of ​​Eno is to rethink to way to compose music, going from a process in which the composer designs all the details of the piece in advance, to one in which she gives a small initial boost and let the music evolve by its own. In Eno’s own words:
[…] I had assumed that music was produced, or created in the way that you imagine symphony composers make music, which is by having a complete idea in their head in very detail and then somehow writing out ways by which other people could reproduce that. In the same way as one imagines an architect working. You know, designing the building, in all its details, and then having that constructed. […] a new paradigm of composing. Changing the idea of the composer from somebody who stood at the top of a process and dictated precisely how it was carried out, to somebody who stood at the bottom of a process who carefully planted some rather well-selected seeds, hopefully, and watched them turn into something.
This idea stuck in my head and now that I’m practicing Test Driven Development, it has returned to the foreground to point out to me that this programming technique fits Eno’s philosophy.
Architects
When we code the unit tests after the main program (if they are coded at all) we are like the composer stood at the top of the process. This position forces us to have a global and precise vision of what we want to build. This idea (inherited from the infamous attempt to resemble the development of software to other engineerings) is unrealistic and ends up generating convoluted, rigid and fragile systems.
Gardeners
However, if we follow the TDD, we become that gardener who plants the seeds and observes the growth of them, watering or fertilizing when necessary.
We only create a class when some test asks for it (compilation error), we only codify a method when it is necessary to pass a test that had previously failed.
The production code (of which before we started we only had a general idea) emerges test by test like the shoots of a plant. And the design is the most natural and organic, since it has arisen from what the system demands at any moment.
Other people have found the metaphor between gardening and software development to be convenient:
So I’m going to try to be more and more like a gardener and not an architect. As Eno himself says, they are at least equal in dignity.
P.S: This article has been written listening to Discreet Music continuously.
Top comments (5)
Food for thought: while TDD can be useful in many projects and scenarios, sometimes it isn't practical (or even possible).
For example, at work we're creating an animation engine, a large part of which must be carefully designed and constructed before tests are even a possibility. While testing must be a part of that project, TDD itself is a stumbling block to progress there.
By contrast, in creating a language parser, TDD is absolutely essential to ensuring it meets expectations and works well.
I absolutely agree that programming is not a science, and it certainly isn't engineering. However, no methodology exists which fits every project well. Each methodology has its place, and its usefulness should be considered purely in the light of the needs of each project. To apply it because "It's the One True Methodology" is invariably asking for trouble.
I agree sometimes it's hard to TDD and is not a bad practice write tests shortly after production code (however I think it's important keep small iterations between production and tests).
I don't know in other countries but here (I'm talking about Spain), Computer Science degree it's officially called "Computer Engineering" !!!).
Small iterations and testing are both excellent things to do - although the definition of both "small" and "testing" vary from one situation to the next. (i.e. there are some cases where you must manually test, because unit tests do not provide adequate coverage by nature of their design.)
I agree, "computer engineering" and "computer science" (the degree name in the U.S.) are total misnomers. (See my article, The Cake is A Lie.)
I prefer gardening/landscaping metaphors in general, regardless of stances on TDD. I think "organic" metaphors more aptly describe our relationship with our applications, which grow up, and are more "living and breathing" than things we "architect".
Selfishly, I'm happy our work is something organic, it means it's not easy for AI to take our place. And it makes me feel somekind special too... Maybe talking philosofy-fiction here!