A panel discussion on the topic: Can Good Software Architecture and Design Really Be Done In An Iterative Manner?

January 8, 2004

Location: Electrical Engineering/Computer Science Bldg., Room EE/CS 230, in the building to the left of our usual one

Thursday, 08 January, 2004
5:45-8:00 p.m. at The University of Minnesota
5:45 start of networking, 6:15 start of meeting, 8:00 end of meeting
Electrical Engineering/Computer Science Bldg.
Room EE/CS 230, in the building to the left of our usual one
Minneapolis, MN

Position Statements:

David Hemphill: Every project has an architecture; every architecture evolves. During post-release cycles architectures tend to diverge from their original design. This can be attributed to changing needs of customers and business processes; it can also be attributed to increased customer feedback and articulation of problems once customers start using the software. This sheds light on some interesting differences between "traditional" pre-release and post-release development, namely in

post-release cycles the customer feedback is often better and more articulate because they are now using the software and
large redesign efforts during post-release cycles have more difficulty gaining support or funding.

As a result, post-release software is often managed differently than it was in pre-release cycles. Said another way, post-release architectural work tends to be emergent and customer driven. Extreme Programming supports an emergent approach to architecture. This can also be viewed as an adoption of a post-release development mentality during the pre-release development cycles. XP practices such as refactoring, simple design, small releases and having an on-site customer all support this mentality. In many ways, XP is also a failure-driven approach to architecture. Improvements are made only when the existing implementation fails or is insufficient to move forward, much in the way post-release software development is managed. However, it should be noted that as a software methodology, XP provides a set of practices to manage risk by keeping the failures small, isolated and discovered as early as possible.

Kyle Larson: Iterative development can and does produce good architectures and good designs and often succeeds where planned approaches would fail.

All successful software architectures and designs are eventually incremental, being adapted to their environment and usage. The difference between planned and evolutionary approaches is the timing of when incremental, adaptive development starts and is embraced.

Iterative development is not a panacea. Architectural vision, meaning consistent usage patterns of key abstractions, can be a challenge to ensure in an incremental environment. Extreme Programming's goal of always leaving the software in the simplest, most readable state naturally leads to incremental architecture, design, and implementation. The degree of simplicity achieved, however, depends on the development team's ability to maintain consistent usage of key abstractions.

Incremental approaches have important organizational and social benefits as well. Because the architecture and design work is taken in smaller steps, applied immediately, and is often made public to the development team, there are more opportunities to distribute architecture and design work across team members.

This contributes to team ownership and accountability while enabling individuals to seamlessly take on more responsibility.

Prasad Muppirala: A good software system is built on sound software engineering practices. Iterative methodologies provide a mechanism to streamline usage of such sound software engineering principles. Architecture does evolve over a period of life cycle development, but is always mature if built on core foundation layers. Starting from a holistic and simplistic view to a tangible set of foundation layers (frameworks) provides an opportunity for a flexible and thought out system development strategy.

Experiences show that a particular methodology alone does not assist in building good systems. Custom software development artifacts may be orthogonal to a software development purely based on integration of different packaged solutions.

It is essential to be selective of the artifacts from different methodologies, understand the cultural aspects of developers and user community, bring to front different foundation components and frameworks proven with experience and establish adaptable blueprints in a strong collaborative environment. I call this common sense methodology. Finally what WORKS for you, IMPROVISE don?t ABANDON!

Mary Poppendieck: It doesn’t seem to me like you have much choice – architecture is going to emerge whether you want it to or not. We know that well over half of all software development occurs after initial release to production. We know that software products which have been around for a good decade now are robust only because their architectures have emerged with each new release. So architecture will emerge.

We also know that some architectural decisions must be made right and made at the start. Take Quicken, for example. The register concept has not changed since the program’s introduction, well over a decade ago. If the original designer had not gotten that right, Intuit would not be around today. The overall systems concept has to be right from the start, and certain architectural elements will be very expensive to change after development is underway.

It seems to me the question might be better put – how does architecture emerge? I think a lead architect or lead systems engineer or master developer needs to be present to guide the overall concept of a system from the start, and guide it’s emergence. Great designs have great designers behind them, and in software development we should not let the focus on the development team override the need for visionary leadership.

About the Panelists:

David Hemphill is the Lead Architect and Development Manager for Gearworks, Inc., a Minnesota-based company that creates wireless workforce automation software. David is the co-author of the book Java 2 Micro Edition (Manning Publications). He has published numerous articles on J2ME and speaks on the subject at industry conferences including OOPSLA and JavaOne. David is also a member of the J2ME expert team that is creating the Sun Certified Mobile Application Developer exam for the Java 2 Platform, Micro Edition. David can be reached at dhemphill@mn.rr.com

Kyle R. Larson leads and helps development teams leverage Agile practices to develop object-oriented systems. He has personally led teams using Agile processes on six projects over the past four years. Project environments ranged from startup dot-coms to fortune-100s, with on-site and off-site development teams. Kyle mentors and teaches agile development methods, is a certified Scrum Master, and is the founder and facilitator of the Agile Experience Group (www.otug.org) which meets monthly in the Twin Cities.

Prasad Muppirala is a consultant with RAJEN Technology Solutions, Inc. specializing in J2EE, WebServices and distributed systems development efforts. Over past 10+ years Prasad has significantly spent time in leading, architecting large scale distributed systems development efforts in FORTE, CORBA and J2EE environments. Prasad has also contributed as technical reviewer for Enterprise Java Beans from ORielly as well as Mastering BEA Weblogic Server from Addison Wesley.

Mary Poppendieck, a Cutter Consortium Consultant and Managing Director of the Agile Alliance, is a seasoned leader in both operations and new product development with more than 25 years’ of IT experience. She has led teams implementing solutions ranging from enterprise supply chain management to digital media, and built one of 3M’s first Just-in-Time lean production systems. Mary is currently the President of Poppendieck LLC. Her book Lean Software Development: An Agile Toolkit, brings lean production techniques to software development.