Friday, September 23, 2005
Programming is Gardening, not Engineering
http://www.artima.com/intv/garden.html
Andy Hunt: There is a persistent notion in a lot of literature that software development should be like engineering. First, an architect draws up some great plans. Then you get a flood of warm bodies to come in and fill the chairs, bang out all the code, and you're done. A lot of people still feel that way. I saw an interview in the last six months of a big outsourcing house in India where this was how they felt. They paint a picture of constructing software like buildings. The high talent architects do the design. The coders do the constructing. The tenants move in, and everyone lives happily ever after. We don't think that's very realistic. It doesn't work that way with software.
We paint a different picture. Instead of that very neat and orderly procession, which doesn't happen even in the real world with buildings, software is much more like gardening. You do plan. You plan you're going to make a plot this big. You're going to prepare the soil. You bring in a landscape person who says to put the big plants in the back and short ones in the front. You've got a great plan, a whole design.
But when you plant the bulbs and the seeds, what happens? The garden doesn't quite come up the way you drew the picture. This plant gets a lot bigger than you thought it would. You've got to prune it. You've got to split it. You've got to move it around the garden. This big plant in the back died. You've got to dig it up and throw it into the compost pile. These colors ended up not looking like they did on the package. They don't look good next to each other. You've got to transplant this one over to the other side of the garden.
Dave Thomas: Also with a garden, there's a constant assumption of maintenance. Everybody says, I want a low maintenance garden, but the reality is a garden is something that you're always interacting with to improve or even just keep the same. Although I know there's building maintenance, you typically don't change the shape of a building. It just sits there. We want people to view software as being far more organic, far more malleable, and something that you have to be prepared to interact with to improve all the time.
Bill Venners: What is the alternative to stratification of job roles?
Dave Thomas: I don't think you can get rid of the layers. I think politically that would be a mistake. The reality is that many people feel comfortable doing things at a certain level. What you can do, however, is stop making the levels an absolute. A designer throws a design over the partition to a set of coders, who scramble for them like they are pieces of bread and they are starving, and they start coding them up. The problem is this entrenched idea that designers and coders are two separate camps. Designers and coders are really just ends of the spectrum, and everybody has elements of both. Similarly with quality assurance (QA). Nobody is just a tester.
What we should be doing is creating an environment in which people get to use all their skills. Maybe as time goes on, people move through the skill set. So today, you're 80% coder 20% designer. On the next project, you're 70% coder and 30% designer. You're moving up a little bit each time, rather than suddenly discovering a letter on your desk that says, "Today you are a designer."
Andy Hunt: If the designer also has to implement what he designs, he is, as they say, getting to eat his own dog food. The next time he does a design, he's going to have had that feedback experience. He'll be in a much better position to say, "That didn't quite work the way I thought last time. I'm going to do this better. I'm going to do this differently." Feedback paths contribute to continual learning and continual improvement.
Bill Venners: Continual learning is part of the notion of software craftsmanship?
Andy Hunt: Exactly. First you've got the designer doing some coding, so she'll do a better design next time. Also, you really need to plan how you are going to take some of your better coders and make them designers. As Dave says, will you give them "the letter" one day? Sprinkle some magic fairy dust and poof, they're now a designer? That doesn't sound like a good idea. Instead you should break them in gradually. Maybe they work with that designer, do a little bit of this design today, a little bit of that design tomorrow. Some day they can take on a greater role.
Andy Hunt: There is a persistent notion in a lot of literature that software development should be like engineering. First, an architect draws up some great plans. Then you get a flood of warm bodies to come in and fill the chairs, bang out all the code, and you're done. A lot of people still feel that way. I saw an interview in the last six months of a big outsourcing house in India where this was how they felt. They paint a picture of constructing software like buildings. The high talent architects do the design. The coders do the constructing. The tenants move in, and everyone lives happily ever after. We don't think that's very realistic. It doesn't work that way with software.
We paint a different picture. Instead of that very neat and orderly procession, which doesn't happen even in the real world with buildings, software is much more like gardening. You do plan. You plan you're going to make a plot this big. You're going to prepare the soil. You bring in a landscape person who says to put the big plants in the back and short ones in the front. You've got a great plan, a whole design.
But when you plant the bulbs and the seeds, what happens? The garden doesn't quite come up the way you drew the picture. This plant gets a lot bigger than you thought it would. You've got to prune it. You've got to split it. You've got to move it around the garden. This big plant in the back died. You've got to dig it up and throw it into the compost pile. These colors ended up not looking like they did on the package. They don't look good next to each other. You've got to transplant this one over to the other side of the garden.
Dave Thomas: Also with a garden, there's a constant assumption of maintenance. Everybody says, I want a low maintenance garden, but the reality is a garden is something that you're always interacting with to improve or even just keep the same. Although I know there's building maintenance, you typically don't change the shape of a building. It just sits there. We want people to view software as being far more organic, far more malleable, and something that you have to be prepared to interact with to improve all the time.
Bill Venners: What is the alternative to stratification of job roles?
Dave Thomas: I don't think you can get rid of the layers. I think politically that would be a mistake. The reality is that many people feel comfortable doing things at a certain level. What you can do, however, is stop making the levels an absolute. A designer throws a design over the partition to a set of coders, who scramble for them like they are pieces of bread and they are starving, and they start coding them up. The problem is this entrenched idea that designers and coders are two separate camps. Designers and coders are really just ends of the spectrum, and everybody has elements of both. Similarly with quality assurance (QA). Nobody is just a tester.
What we should be doing is creating an environment in which people get to use all their skills. Maybe as time goes on, people move through the skill set. So today, you're 80% coder 20% designer. On the next project, you're 70% coder and 30% designer. You're moving up a little bit each time, rather than suddenly discovering a letter on your desk that says, "Today you are a designer."
Andy Hunt: If the designer also has to implement what he designs, he is, as they say, getting to eat his own dog food. The next time he does a design, he's going to have had that feedback experience. He'll be in a much better position to say, "That didn't quite work the way I thought last time. I'm going to do this better. I'm going to do this differently." Feedback paths contribute to continual learning and continual improvement.
Bill Venners: Continual learning is part of the notion of software craftsmanship?
Andy Hunt: Exactly. First you've got the designer doing some coding, so she'll do a better design next time. Also, you really need to plan how you are going to take some of your better coders and make them designers. As Dave says, will you give them "the letter" one day? Sprinkle some magic fairy dust and poof, they're now a designer? That doesn't sound like a good idea. Instead you should break them in gradually. Maybe they work with that designer, do a little bit of this design today, a little bit of that design tomorrow. Some day they can take on a greater role.
Permalink : 12:28 AM
