Join the Agile Community

With more than 4261 members located around the globe, the Agile Alliance is driven by the values and principles of the Manifesto for Agile Software Development

We support those who explore and apply Agile principles and practices to make the software industry productive, humane, and sustainable.

Knowledge Repository

Search for text or agile alliance members

Why We Don't Build Software for Users

by Cooper, Alan; Thé, Lee (2002-10-18) permalink

Read the full article

During this interview Alan Cooper talks about software construction, craftmanship, agile and engineering methods as well as much other issues that live in the software industry.

Rating: 3.2 out of 5 (5 ratings)
Source: Visual Studio Magazine
File Type: HTML
Owner: admin
Categories: Architecture, Design, Extreme Programming, Project Management, Rational Unified Process
Updated: July 14, 2007

Comments

Comments admin (17 May 19:11)

Overall very good. Alan Cooper is always a joy to read. I only have two issues with the interview. One is minor. I believe he may be simplifying the waters a bit by claiming XP=small projects and RUP=larger projects. But that may be more because of the time and forum. The other quibble I have is with the points he makes about what an architect should be. I believe he conflates two roles into one: architect and business analyst. This is most likely because he may be one of the rare people who can do both, and because most people have never worked with a skilled BA. I believe that the architect must be able to examine the business and understand the problem and solution, but I don’t believe it should be the architect who comes up with the final system behavior to accomplish the solution. The final functional design of a system should come about through the cooperative activities of the users, the BA and the architect. The BA helps the users define and describe the problem and a solution while the architect helps create the technological architecture to make it possible. Not everything is possible technically for a reasonable amount of money and time and that’s where the architect feeds back into the requirements process. She will help the BA refine the requirements, which are fed back to the users, based upon the realities of technology. It’s true that the architect is the nexus of people, process and technology, but they stand side-by-side with the analyst in bridging the gap between the development team and the users.