While listening to a new podcast the other day, I stumbled up on an old presentation from a Java conference (Javapolis 2005) titled "Perspectives on Agility" by Kevlin Henny. While the talk, in general, contained several interesting points concerning agile development, one point peaked my interest in particular. I get the feeling that it's often said by developers (and I definitely know I'm guilty of this) that the customer doesn't know what they want. More specifically, they don't know what they want until they see it, and by that time, a significant amount of effort might have already been devoted to a project and more work will be needed to correct things. This might be true, and even seems reasonable to accept this as a part of human nature (as agile methods commonly do), but what about developers? Do they exhibit the same behavior to some extent?
In the presentation, Henney suggests that the most capable software engineers that could work on a software project are the ones that have seen it to its completion (or, just as likely, failure). Typical developers are constantly learning about the problem domain and may even significantly adjust their development tools and practices during a project. While the traditional waterfall process is often chided for its naive attitude towards changing requirements (which is ironic considering that in the original paper describing the process it was never called a "waterfall" and the author even warned against using it), I wonder how many times when software is planned changing developer knowledge or habits are taken into account.
When confronted once with a client who rejected "agile" software processes (the client having been burned before by a process describing itself as "agile"), Henney describes successfully re-branding his approach as a "sustainable" process. While he might have gotten some inherent acceptance owing to recent popular environmentalist attitudes, I think "sustainable" is a good term to describe a software development approach that accepts both changing customer requirements and perceptions as well as changing developer knowledge and habits.