Hopefully that whets your appetite. Worth watching.
Regarding collecting customer feedback and incorporating it into your software:
People love giving you feedback. Every time you make a mistake they give you feedback. Give people great products and you’ll get feedback… You have to take it all in and then you have to make decisions on behalf of your customers. Decide what they’re actually trying to tell you. You have to be a museum curator and think about what makes sense for the product. An editor, a curator, looks at an entire universe of options and picks a few of em.
An interesting perspective, but probably worth noting that this is coming from a non-developer (Jason is one of the co-founders of 37signals, and has more of a design background than a programming one). I like that his example puts a lot of stock in the customer needs and wants, while also taking a great deal of pride, somewhat of a near-arrogance, in what’s ultimately right for the product. That is right on.
That said, I still like the gardening metaphor better. In both cases (a museum or a garden) you are attempting to create an aesthetic that is pleasing to the visitor, and you are likely to get feedback, some of which you will incorporate. But the museum analogy stops at the choice of whether or not feedback is acknowledged (and ultimately leaves the actual creation of art out of the picture). In gardening, the feedback alters what happens on the ground, in the garden: how the plants are pruned, how all-season interest is maintained, how to attract wildlife, etc.–a truly iterative process that, to me, is a more apt analogy to the actual development of the software.
Maybe from a project management perspective, museum curating is a good approximation of how the customer feedback loop works, but from the trenches, as a programmer, it just feels too simplistic. I’m sticking with the gardening analogy.
Check out notes from Jason Fried’s presentation here. (Lots of other great info about 37signals and their “Getting Real” philosophy, too!)]]>
Rather than construction, software is more like gardening—it is more organic than concrete. You plant many things in a garden according to an initial plan and conditions. Some thrive, others are destined to end up as compost. You may move plantings relative to each other to take advantage of the interplay of light and shadow, wind and rain. Overgrown plants get split or pruned, and colors that clash may get moved to more aesthetically pleasing locations. You pull weeds, and you fertilize plantings that are in need of some extra help. You constantly monitor the health of the garden, and make adjustments (to the soil, the plants, the layout) as needed.
The engineering/construction thing is so often used in the software field that “software engineer” has come to be the accepted term (though still much to the chagrin of licensed professional engineers, I suppose). Yet this quote really captures something with this gardening idea that is more similar to what writing software is all about.
We can’t write software like we build bridges, there’s a bit more artistry to it, much as there’s artistry to gardening. Designing up front is important to have a grasp of the big picture and the pieces required to make it happen, but just important is the ability to adapt along the way, change course, do things different, ultimately with the ends of making a more elegant, more beautiful garden of code.
I think I might need to start calling myself a Software Gardener instead of a Software Engineer…]]>
However, I would be remiss if I didn’t mention that in the meantime, a new collaborative blog focusing on Tacoma tech stuff has popped up: Tacoma Tech Connect. This features Paul Ellis from the BIA (and BIA Blog), Gary Brackett from the Chamber of Commerce, and Andrew Fry from UWT, all representing the Tacoma Technology Consortium, an organization encouraging development and relationships in the local tech community. Cool stuff. Keep up the good work, guys!
(Via the TNT carnival of blogs.)]]>