My architect friend Ken and I had coffee the other day and caught each other up on the latest trends in our fields. Ken and his wife designed our house. Ken and I like to talk about meaningful design processes (me about software, Ken about buildings and homes) and learn from each other’s experiences.

I explained to Ken the new trend in software called agile development which emphasizes teamwork, close customer involvement, evolutionary design, programmers as designers, and incrementally delivering value to customers. On a typical agile team there isn’t much distinction between designing and programming. Design is viewed as something that is constantly happening while you are coding. In fact one view held by extremists that I find somewhat disturbing is to equate any design up front as being the same as Big Design Up Front which is equated with being wasteful. Since you will change your ideas during implementation anyway, why invest any time inventing pie-in-the-sky solutions? (In case you can’t tell, I take a more moderated view—it all depends on the situation and the context. I believe a little upfront design never hurts, and sometimes more is needed).

More traditional processes tend to divide development into phases: problem requirements are gathered and analyzed, solutions are designed and implemented. Although even that description is too simplistic. The Rational Unified Process talks about overlapping phases and delivering incrementally. So what’s the big difference between agile and more traditional approaches?

One big difference between agile and more traditional approaches is what stands between the developer and the problem. Traditional software development teams have analysts or business architects who gather requirements, write them down, and then work closely with developers/programmers who implement the software. These people hold the torch for what the user needs and wants (and can afford) throughout the process. The good analysts I know are skilled at talking with users and business experts and at translating their requirements into terms that developers understand. They bridge the complex world of the business and the detailed world of the programmer. On agile teams, developers work directly with their “customers.” Middlemen are eliminated. As little documentation as possible is created. There’s direct, open communication. The software design takes shapes in a very organic manner. Things are not planned out to the nth degree beforehand.

Ken noted that a similar trend in building architecture, especially the environmentally friendly architecture that he’s interested in. There’s the traditional design process which Christopher Alexander believes makes for lifeless buildings, and the more organic, buider-as-designer process (which is a haven for old hippies, according to Ken). It is into this world divided into disparate camps, that Ken wants to bring his creativity and vision. He’s worked in a big architectural firm and felt far removed from the customers’ needs. On the other hand, do-it-yourselfers tend to not want help. Where does such a passionate designer like Ken fit in and make a living? I told him he has to find a new market and educate potential customers on the benefits of taking responsibility and engaging in the design of their environmentally friendly homes with a designer like him.

I told him I find myself in a similar situation. But I haven’t had to create a totally new market. More often than not, I work with those who follow fairly traditional development processes. There I add value by talking about responsibility-driven design. I also help people who want to build flexible, well-designed systems get more skilled at articulating what they want and how to build it. I also try to bring a spark of agility to their processes—finding ways to simplify heavy-handed processes, streamline documentation, and communicate more effectively. I’d like to spend more time with agile teams helping them bring their design skills up another notch while programming like crazy. But so far, that opportunity hasn’t come along.

I’m always fascinated by the parallels between software and the architecture world that Ken and I find whenever we have time for a cup of coffee. My next challenge will be to absorb some of Christopher Alexander’s latest writing (but Ken has warned me that his four volumes are not light reading) before I have another conversation with Ken.