Sunday, 26 October
Monday, 27 October
Tuesday, 28 October
Wednesday, 29 October
Thursday, 30 October
There is no shortage of technical wisdom on how to develop clear and robust code, so why is cryptic code and the corresponding look of puzzlement on a programmer's face such a common sight? Many companies and developers want to use state-of-the-art development practices, but seem swamped and bemused by how much state there really is to that art.
The tutorial offers a concrete, thirteen-point list of recommendations (zero through twelve) that can be applied immediately to reduce code size and complexity, acting as both guidelines for new code and indicators for refactoring. The short list has no ambition to be all that you needed to know about design but were afraid to ask, but it does offer an easily learned and easily practiced set of guidelines that offer the greatest immediate return on investment--the most bang for your buck or oomph for your euro.
This tutorial is targeted at people who write code for a living, typically using a curly-bracket language (C++, C#, Java, etc.) and are looking for that extra edge that allows them to keep their code live and clean.
Kevlin Henney is an independent consultant and trainer. The focus of his work is in programming languages, object orientation, component-based development, UML, patterns, and software architecture. He is a regular columnist for C/C++ Users Journal (online), Application Development Advisor (UK), and JavaSpektrum (Germany), and previously wrote columns in Java Report and C++ Report. He is also a member of the advisory board for Hillside Europe, the program chair for EuroPLoP 2003, and a popular speaker at conferences in the US and Europe.
This tutorial takes the "extreme" out of Extreme Programming. It brings the expertise acquired by the agile software development community to mainstream software developers working on all kinds of projects. The Extreme Programming community has shown the value of writing automated software unit and acceptance tests for increasing quality, reducing development cost and improving agility. Now that we know this is possible, how can we apply these lessons to more traditional software projects? And if you are an XP developer, how can you improve the way you write tests?
The XUnit family of testing frameworks (including JUnit, SUnit, NUnit, VbUnit, etc.) provide an important first step in software test automation. But test automation is much more than just knowing how to program a test in XUnit. The neophyte test-writer is faced with a deluge of questions and issues; e.g.,
This tutorial addresses these and many other questions.
This tutorial is intended for professional software developers who would like to learn how to test their software more effectively.
Prerequisites: Participants must be familiar with the object-oriented software development paradigm, and be fluent in one or more object-oriented languages. Familiarity with Java or C# is useful, but not required. Familiarity with a unit testing framework, such as JUnit, is preferable.
Lecture and hands-on exercises
Gerard built his first unit testing framework in 1996 and has been doing automated unit testing ever since. Along the way, he has become an expert in refactoring of software, refactoring of tests, and design for testability. Gerard has applied automated unit and acceptance testing on projects ranging from full-on eXtreme Programming to traditional waterfall development. He has presented successful tutorials at the past three OOPSLAs, has organized workshops at four previous OOPSLAs, and has presented papers on developing and testing object oriented software frameworks at two previous OOPSLAs as well as XP2001 and XP2002.
Ralph Bohnet is a senior consultant and trainer with Clearstream Consulting and has been doing agile development since 2000. He is an avid advocate of automated testing and Test First Development. Over the past 13 years of IT experience, he has acted as team leader, mentor, business analyst, OO developer, and instructor. He is currently the team lead of a testing team for a national Railway company. Ralph has been the president of Calgary Java Users Group for the past 4 years.
With Adaptive Software Development, Crystal, Extreme Programming, Feature Driven Development, Lean Development, and Scrum the ecosystem of agile methods seems to stabilize. Though they all use different metaphors and approaches to software development, their hands-on results are so similar that readers may ask themselves, whether they are really different methodologies. Practitioners have had the best results combining elements of different agile methodologies — a possibility that defines a common species in biology.
This sequel to last year's OOPSLA workshop "Commonalities of Agile Methodologies" explores this question in depth in a highly interactive setting. It may work on questions like "What is different anyhow and why?", "What forces drive particular solutions?", or "How does a solution deal with limitations?".
Agile development processes are different. They increase productivity, and they bring focus and pleasure back to software development. As they move from early adopters to the mainstream, practitioners and researchers require an understanding of their principles and operation. This tutorial explains the underlying theory and practices of all agile processes, and then explains how they are implemented in Scrum. A case study is presented that provides the rules and feel for the various Scrum practices. Then the new management practices and roles demanded by agile processes are explored. To wrap up, various techniques for scaling agile processes to any type of project are presented and examples provided.
Prerequisites: Attendees must understand software development, as demonstrated by participating in development projects.
Ken Schwaber is Chair of the Agile Alliance. He is one of the developers of the Scrum agile process and is an author of the Agile Manifesto. He has given presentations at numerous conferences and user groups, and is author of "Agile Software Development with Scrum" with Mike Beedle. Ken has developed, managed and consulted about software development for over 30 years.
Product-line architectures promise better productivity and less maintenance costs for families of related software systems. A strong product-line architecture is one of the keys to a successful deployment of both product lines and any system destined to go through multiple releases. However, specifying high-quality product-line architectures is a surprisingly difficult task.
Commonality and variability analysis is a powerful domain analysis tool for the specification of product lines. It can help designers produce systems that are robust in the face of change, and that can be easily customized. Additionally, it feeds naturally into OO design. This combination provides a proactive, systematic approach to accomodating changes in software.
This tutorial introduces commonality and variability analysis in a real-world setting. Topics include: underlying principles, methodology, and synthesis with OO design. By the end of the tutorial, you will understand how to use commonality and variability analysis in your OO projects to specify a stable, yet flexible, software architecture.
This tutorial is aimed at architects and designers of systems that have many variations, such as product families and systems with multiple releases.
Prerequisites: Attendees should have solid background in OO principles, and some OO design experience. Experience in specification or analysis is helpful but not required.
Lecture with exercises
Neil Harrison is a researcher at Avaya Labs, where he consults with software projects in architecture, process, organizations, estimation, and product line engineering. He has been involved in software patterns since 1994. He has organized pattern conferences and has taught many courses on patterns. He is a member of the Hillside Group board of directors. He has published patterns and chapters in pattern books, and was lead editor of Pattern Languages of Program Design, Volume 4.
Frank Buschmann is senior principal engineer at Siemens Corporate Technology in Munich, Germany. His interests include Object Technology, Software Architecture, and Patterns. Frank has been involved in many software development projects. He is leading Siemens' software architecture research activities. Frank is co-author of "Pattern-Oriented Software Architecture -- A System of Patterns" and "Pattern-Oriented Software Architecture -- Patterns for Concurrent and Networked Objects".
While Test-Driven Development and Refactoring are extremely useful software development practices, they are insufficient for evolving great designs. What's missing are the thinking and coding practices that real-world evolutionary designers use to evolve top-notch designs effectively. Such practices include critical learning that results from early end-to-end system development, significant time savings obtained by determining what doesn't need to be automated, eye-opening design simplicity achieved by automating failing acceptance tests before writing code, important design progress that results, paradoxically, from undoing previous design work and more.
This tutorial takes the mystery out of Evolutionary Design by naming and explaining what its thinking and coding practices are and how to implement them. You'll be challenged to solve Evolutionary Design exercises and you'll experience how a game of blackjack evolves from a first failing UI test to a functioning version of the game. Along the way you'll learn how not to evolve blackjack, you'll study micro-snapshots of the evolution-in-progress and you'll understand what the evolution of a game teaches us about Evolutionary Design on real-world projects.
Prerequisites: Participants should be able to read Java code to get the most out of the session. No background is required in Agile Development, Refactoring, or Test-Driven Design.
Interactive lecture and programming demonstration
Joshua Kerievsky has been programming professionally since 1987, and is the founder of Industrial Logic (http://industriallogic.com), a company specializing in Extreme Programming (XP). Since 1999, Joshua has been coaching and programming on small, large and distributed XP projects and teaching XP to people throughout the world. He is the author of numerous XP and patterns-based articles, simulations and games, including the forthcoming book, Refactoring to Patterns (http://industriallogic.com/xp/refactoring/).
Russ Rufer has been building software systems for 15 years. His wide-ranging experience includes desktop applications, embedded firmware, telecommunications, networking, satellite simulation, and productivity tools. Russ leads weekly meetings of the Silicon Valley Patterns Group, which he founded in 1998 (http://pentad.com/SiliconValleyPatterns.html) and regularly organizes pre-publication review teams to provide feedback on new literature from the software patterns and agile development communities. Russ has worked with Industrial Logic for several years. He divides his time between pure development, coaching and leading workshops on Extreme Programming, Testing, Refactoring and Patterns.
Most of the practices of Extreme Programming are beneficial to students in their computer science courses. But in order to teach students properly, pedagogical changes are needed as early as CS1. This workshop seeks participants who have significant ideas for changes that can be made in early computer science courses that involve integrating any of the practices of Extreme Programming or other agile methodologies.
Would-be participants should send in a short position paper outlining one or two ideas they have. During the workshop, participants will critically discuss the ideas that have been suggested and explore any new ones that arise. Participants will agree to allow their ideas to be shared via a web page to be posted in various CS educational resources repositories.
All of this XP and Agile Methods hype is wonderful, but how can people who work on large-scale software projects (i.e., projects with more than 100 people and longer than 1 year duration) take advantage of the benefits in quality, efficiency, and time promised by the hype?
That question is answered in this tutorial. We will go through an approach--one that has worked well in practice--that enables teams to collaborate in an agile way on large projects. This tutorial will cover the following topics:
At the end of the session, you will leave the room either shaking your head saying, "I wish I could do that," or you will have definite plans to try these practices when you get back to work.
The material in this tutorial comes principally from the presenter's forthcoming book, "Large-Scale Agile Software Development," which may be available in time for OOPSLA.
This tutorial is geared towards practitioners, software or process engineers in development leadership roles, or someone with influence on such people.
Prerequisites: Experience developing large systems, and exposure to the attendant difficulties of doing so, is required. Knowledge of object technologies is not essential, but it is helpful.
Ron Crocker is a Fellow of the Technical Staff in the Network and Advanced Technologies group of Motorola's Global Telecom Solutions Sector, where he has pioneered the application of advanced software technologies and processes in the development of next-generation cellular telecommunications systems. He is the author of the forthcoming Addison-Wesley book "Large-Scale Agile Software Development."
Agile Contracts. Are these two words an oxymoron? Contracts have played a very important role in the business of software development; in fact, much of this work is in fact done 'under contract'. Organizations adopting agile methodologies are finding it hard to write contracts for software development without compromising the core values and practices. The Agile Contracts workshop is your chance to help the agile community identify ways contracts can be structured and worded to support agile software development.
Come prepared to participate! Come and participate in the discussion about how to structure agile software development contracts and take away many great ideas, no matter which side of a software development contract you find yourself.
"I learned more from this workshop than from any other session," said one Agile Contracts Workshop participant at XP 2003. Use gaming theory to understand the motivations of contracting parties. Share examples of a contract structure, which had either good or bad effects on agile software development. Work with a small team to devise a contracting strategy, which supports agile software development.
Leave a Legacy. The good ideas generated in this workshop will be posted to the web for all to see.
Reengineering and evolution are important for long-lived software systems. Change and growth in the system's requirements and functionality occur in all kinds of systems — and it is especially critical to manage the evolution process in modern agile and extreme software processes. The management of change and growth may in fact become a daily activity, so a well defined set of techniques and tools for doing reengineering are critical to success.
This workshop picks up from the results of the OOPSLA '02 workshop "Tackling the Discovery Costs of Evolving Software Systems."
Participants will present and discuss encapsulation and reverse engineering techniques, impact of reengineering on software processes, organizational concerns, and experiences in managing software change "in the extreme".
To ensure return on technology investments, companies need to align IT projects to their Business Strategy. Today a technology solution has many stakeholders, requiring systems to be developed in a multi-stakeholder context.
The key stakeholders include:
Stakeholders often have conflicting objectives. Moreover, differing sub-cultures and ways of working and communicating contribute to communication barriers and the possibility of project failure.
This workshop explores ways of realizing an effective bridge to close communication gaps and to create a shared vision and plan for realization among different stakeholders. The benefits of having an effective way to translate a Business Strategy into optimal technology solutions include:
The workshop will look into approaches for accelerated solution design that can reliably translate and connect core business requirements into the best choices for enabling technology and software implementations. In particular, the workshop will solicit submissions that summarize substantive candidates of such approaches for presentation and subsequent cross-comparison and analysis. Workshop attendees will discuss, analyze and attempt to distill the essence of what makes these approaches work looking for a core set of similar features, activities, constructs and results produced that have proven to be effective and reliable.
One possible example of such a common feature -- the use of solution stories -- appears to foster a common understanding of ideas and confidence in proposed capabilities for given domains. As one of the probable items of focus, the workshop will seek to confirm that this is a common feature, and to understand why. The overall goal and result of the workshop will be to catalog the most important, common features or activities of the best approaches and how and why each works, whether by itself or in combination with the rest.
XP advocates streamlining the requirements specification activity process, to the extent that conversations and automated tests replace thick, formal, and invariably incomplete/outdated requirements documents. The dials are turned to the maximum settings, resulting in maximum agility. There are most certainly situations where this approach is a perfect fit. But what about situations where this approach is not possible (e.g. distributed teams, safety critical systems, etc)? If we fiddle with the settings of some of the dials, will the end result still be agile?
This tutorial explores strategies for tuning the requirements process to optimize agility for a given set of project factors (e.g. team size, project complexity, project criticality, team knowledge and experience, stability and completeness of requirements, etc). Topics discussed include: What work products do we need to use? How much detail is required? How formal does the communication channel need to be? How formal does the notation need to be? What kinds of tools do we need to use? What is the impact of unexpected change?
This tutorial is targeted to developers, managers, analysts, and "customers."
Prerequisites: Knowledge of common requirements artifacts such as use cases and UML notation (use case diagrams, activity diagrams, state transition diagrams, class diagrams) is beneficial but not required. This tutorial focuses on the application of more general concepts and not the specifics on any one set of requirements artifacts.
This tutorial is extremely interactive (definitely not "death by PowerPoint"). Simulation exercises provide participants with first hand experience and rapid feedback on various approaches to requirements specification. Guided group discussions following each simulation enable the sharing of insights and facilitate a deep and lasting understanding of the underlying concepts.
Jennitta has been a senior consultant with ClearStream Consulting since 1994 as process mentor, OO developer, requirements analyst, business modeler, instructor, and retrospective facilitator. Jennitta has been a practitioner of XP since 2000 in a variety of capacities: developer, mentor, and writer/speaker ("Managing the Bootstrap Story," XP 2001, "Catalog of XP Project Smells," XP 2002, and "Framework XP," XP 2002). Jennitta is an experienced instructor; she has recently co-developed and delivered multiple sessions of a three-day course on automated testing for developers and a three-day workshop on agile requirements specification.
Gerard is Chief Scientist at ClearStream Consulting, where he leads teams applying agile software development techniques (such as eXtreme Programming) to help ClearStream's clients achieve faster and higher quality application development. He has presented successful tutorials at the past four OOPSLAs and has presented papers on automated testing and developing object oriented software frameworks at past XP and OOPSLA conferences.
Large information systems need a domain model. Development teams know this, yet they often end up with little more than data schemas. This tutorial delves into how a team, developers and domain experts together, can engage in progressively deeper exploration of their problem domain while making that understanding tangible as a practical software design. This model is not just a diagram or an analysis artifact. It provides the very foundation of the design, the driving force of analysis, even the basis of the language spoken on the project.
The tutorial will focus on three topics:
The tutorial will include group reading and discussion of selected patterns from the book "Domain-Driven Design," Addison-Wesley 2003, and reenactments of domain modeling scenarios.
Prerequisites: Attendees must have a basic understanding of object-oriented modeling and the ability to read UML. Some involvement, past or present, in a complex software development project is helpful in seeing the applicability of the material, but is not essential. Familiarity with the practices of Agile Methods and/or Extreme Programming is helpful, but not essential.
Interactive reading/discussion session, and simulations of the activities and processes that go into making domain design decisions.
Eric Evans is a specialist in domain modeling and design in large business systems. Since the early 1990s, he has worked on many projects developing large business systems with objects and, since 1999, has been deeply involved in three projects committed to the Extreme Programming process (XP), and has trained teams in the Extreme Programming process. Out of this range of experiences have emerged the synthesis of principles and techniques shared in the book "Domain-Driven Design," Addison-Wesley 2003.
Ralph Johnson is a co-author of the now-legendary book, "Design Patterns" (Addison-Wesley, 1995). He is on the faculty of the Department of Computer Science at the University of Illinois. He is the leader of the UIUC patterns/Software Architecture Group and the coordinator of the senior projects program for the department. His professional interests cover nearly all things object-oriented, especially frameworks, patterns, business objects, Smalltalk, COM and refactoring.
Some people consider use cases and agile development to be contradictory concepts, writing use cases as mere replacements for whatever requirements documents they were writing on their all-requirements-first, document-centric projects. Alistair Cockburn, one of the few people expert in both use cases and agile development, will review how to work with use cases on those other projects, where you choose to spend less time on documentation, do it later, need to save money, or plan on changing your mind along the way.
Part of the secret is in writing less, more clearly. The tutorial will include tips for structuring use cases to take less time to write, becoming both shorter and clearer, siphoning less time from project progress, and communicating crucial information more quickly. Part of the secret lies in knowing what parts to omit and when to omit them. The tutorial will include tips for shortcutting both the process and the use case structure for those projects that choose those tradeoffs. Not much can be said about tools, but what is known about setting up tools for agile use cases will be addressed. Along the way, the tutorial will review the fundamentals of both use cases and agile development, addressing particularly the basic structure and common misconceptions surrounding each. The presenter will allocate time within the session to answer arbitrary questions that the curious attendee might bring along.
This tutorial is intended for people who are curious about agile development, or those familiar with agile development and skeptical about adopting use cases.
Prerequisites: Some previous exposure to use cases is required. No special knowledge of agile development is needed.
Lecture and discussion
Dr. Cockburn is a highly-regarded instructor and is known as one of the premier experts on use cases as well as one of the authors of the Manifesto for Agile Software Development. His book "Writing Effective Use Cases" set the standard in the area. That and his "Agile Software Development" both received the Jolt Productivity book awards in 2001 and 2002, respectively. Dr. Cockburn has taught use case writing since 1994, and has also acted as consultant on project management, object-oriented design, and methodology to the Central Bank of Norway, the IBM Consulting Group, and the First Rand Bank of South Africa. Materials that support his workshops can be found at http://Alistair.Cockburn.us.
The Principles Behind the Agile Manifesto state that, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." How should that be done? This tutorial will present techniques for project retrospectives that allow teams to discover what they're doing well so that successful practices can be repeated and identify what should be done differently so that teams can improve. Retrospectives are not "finger pointing" sessions, but rather a highly effective series of activities in which teams can reflect on the past in order to become more effective in the future. Participants will be introduced to the retrospective process, learn techniques for leading retrospectives, hear the experiences of the tutorial leaders who have led retrospectives in various kinds of projects, and participate in a retrospective simulation.
Prerequisites: Participants should have been part of at least one development experience.
Introductory lecture and simulated retrospective
Linda Rising has a Ph.D. from Arizona State University in the area of object-based design metrics. Her background includes university teaching experience as well as work in industry in the areas of telecommunications, avionics, and strategic weapons systems. She has been working with object technologies since 1983. She is the editor of "A Patterns Handbook," "The Pattern Almanac 2000," and "Design Patterns in Communication Systems." She has experience leading retrospectives in a number of companies and academic settings around the world, as well as giving presentations on the benefits of retrospectives. She has over 20 years of academic teaching experience and over 15 years of industrial training experience.
Mary Lynn Manns has a Ph.D. from DeMontfort University in England in the area of software patterns. She is on the faculty at the University of North Carolina at Asheville. She has taught seminars on project retrospectives and has led numerous retrospectives in both industry and academia.
This panel brings together coaches to discuss all aspects of the practice: how to become a coach, choosing a coach, and describing what is to be an (in) effective coach. A coach watches, provides feedback, and suggests subtle direction. The coach may be more—for example—an architect or team lead—but that is a matter for debate. This session will be run as a panel with two open "fish bowl" seats, only one of which may be occupied by audience members at any one time. The panelists will defend their positions and offer feedback. Panelists were asked to offer their observations on three questions: How did YOU become a coach? What's the toughest thing you've had to do as a coach? What's your advice for teams looking for a coach?
This panel brings together practitioners with experience in Agile and XP methodologies to discuss the approaches and benefits of applying Test Driven Development (TDD). The goal of TDD is clean code that works. The mantra of TDD is: write a test; make it run; and make it right. Open questions to be addressed by the panel include:
Quality software systems require quality software architectures. Otherwise it is hard, if not impossible, to meet their functional and non-functional requirements and to master their inherent complexity. For instance, software architectures for systems with end-to-end quality of service demands, systems with stringent security requirements, or systems that are supposed to be in operation for 20+ years cannot be created on the fly, using contemporary middleware and tools. Instead, these architectures must be crafted with care, following a defined specification process and making thoughtful design decisions.
This tutorial explores some of the timeless secrets of building high-quality software architectures, in terms of process, methodology, design goals, and architectural properties, to convey the foundations of building successful software.
Prerequisites: Participants must have experience with object-oriented software design and development.
Frank Buschmann is senior principal engineer at Siemens Corporate Technology in Munich, Germany. His interests include Object Technology, Frameworks and Patterns. Frank has been involved in many software development projects. He is leading Siemens' pattern research activities. Frank is co-author of "Pattern-Oriented Software Architecture -- A System of Patterns" and "Pattern-Oriented Software Architecture -- Patterns for Concurrent and Networked Objects."
This tutorial introduces the Framework for Integrated Test (fit) and demonstrates its use in Test-Driven Development (TDD), as practiced in Extreme Programming and other agile development methods. Projects use fit-style tests both to guide programming and to test the correctness of the result. Test-driven designs are more easily "refactored," making it the only programming method that expects programs to get "cleaner" over time.
Short lectures will explain just enough of Extreme Programming to establish the context for test-driven design. These will be followed by live demonstrations and laboratory exercises. The labs will use simple Java, but the emphasis is on familiarity with the frameworks, tools and techniques, not programming. If you are unfamiliar with Java, you will learn enough just by watching to be able to complete some of the exercises and obtain all of the benefits of the tutorial.
Bring a laptop, or join someone who has one, to do hands-on exercises. Bring a wireless networking card to participate in additional "online" activities. Install Java at home to save time in class. Google "sun java download" to find a version for your computer.
Prerequisites: Some programming experience with an object-oriented language is required (not necessarily Java). Familiarity with downloading and installing software is also required.
Lecture, demonstration, and optional exercises
Ward Cunningham is a founder of Cunningham & Cunningham, Inc. He has served as Director of R&D at Wyatt Software and as Principle Engineer in the Tektronix Computer Research Laboratory. Ward is well known for his contributions to the developing practice of object-oriented programming, the variation called Extreme Programming, and the communities hosted by his WikiWikiWeb.
Many modern object-oriented applications must manipulate data stored in relational databases (RDBs). There is a well-known technical impedance mismatch between the object-oriented and relational models that must be overcome to permit such integration. Equally important but less publicized, there is also a cultural impedance mismatch between OO developers and relational database professionals. If modern software development is to succeed, we need to find ways to overcome both mismatches.
This tutorial addresses both the technical and cultural impedance mismatches between object and relational technologies and practitioners. To address the technical mismatch, we discuss techniques that data professionals can follow to support agile software development efforts, including database refactoring, evolutionary data modeling following the practices of Agile Modeling using the UML, mapping techniques, object/relational database implementation strategies, and Test-Driven Development (TDD). To address the cultural mismatch, we describe the skills and knowledge that agile software developers need to gain over time to be effective with respect to data-oriented development activities.
Prerequisites: Attendees must have an understanding of the fundamentals of agile software development.
Scott Ambler is a noted expert in data management and agile methods. He is author of several books, including "The Object Primer 3rd Ed.", "Agile Modeling," and "Agile Database Techniques."
The Rational Unified Process (RUP) is a comprehensive process covering almost all aspects of software development projects. Due to its great level of detail, RUP has--quite wrongly--the reputation of being too heavyweight for agile development projects. In this tutorial, you will learn how to configure RUP for agile development. Topics covered include what artifacts to use and not to use, best practices for planning and monitoring projects, best practices for handling requirements, analysis and design, and how to introduce agile RUP into a project or in an organization. About 25% of the time of the tutorial is devoted to a demonstration of a real world project which has been successfully completed with an agile version of RUP.
This tutorial is aimed at project managers, software architects, software process specialists and software developers who are evaluating RUP for agile development or who are involved in a project where RUP is already used and want to make it more agile. Knowledge of RUP basics is helpful but not required.
Lecture and demonstration
Michael Hirsch has 20 years of experience in the software industry in various roles, including project manager, software architect and software developer. During the last 10 years, he has been with Zühlke Engineering AG, a software contractor and software consultancy in Switzerland. He has been using RUP since 1998, when he led a team that introduced RUP at Zühlke Engineering and adapted it to the company's needs. Since then Zühlke Engineering has successfully completed about 20 projects with an agile version of RUP. Today, Michael splits his time between managing software development projects, coaching and mentoring project teams, and teaching classes on software processes and object oriented analysis and design. He is a member of ACM and IEEE, and has a degree in electrical engineering from HTL Bregenz in Austria and a degree in software engineering from HTL Berne in Switzerland.
Programming skills are back in style!
Test-driven development is based on a cycle of testing, coding, and refactoring. The meat of this session is a real-time workout where you explore and exercise your skills in techniques that build rippling muscles for Java developers.
Whether you want to become a bodybuilding champion or a top-drawer developer, choice of regimen is critical. For developers, writing the tests first changes the way you design, improves the quality of your code, and guarantees your code is testable.
Like a bodybuilder's high-protein diet, refactoring shows you how to take code that merely works, and turn it into lean, easy-to-understand code that you'll be proud of.
This tutorial cranks up the workout intensity with pair programming (a form of spotting), a contest, and prizes, all designed to maximize your sweat equity in building your Java muscle.
This class is for Java programmers only. Bring a laptop if you can, with a Java environment and JUnit installed and working. If you don't have a laptop, that's cool--we'll pair you with someone who does. Either way, please contact William.Wake@acm.org and tell him whether you're pumping your own iron or need to share.
Prerequisites: Attendees must be able to program in Java.
Lecture and hands-on exercises with partners
William Wake is an independent consultant interested in agile methods, patterns, and human-computer interaction. He is the author of "Extreme Programming Explored" and the "Refactoring Workbook."
Steve Metsker is a researcher and author who explores and writes about ways to expand the abilities of developers. Steve is the author of "Building Parsers in Java," "Design Patterns Java Workbook," and the forthcoming "Design Patterns C# Workbook."
"Self-directed team" is one of the mantras of Agile Methodologies. Self-direction means that the team's manager is relegated to a facilitator role with little or no influence over day-to-day activities. For example, Kent Beck has written that the manager of an XP project can do four things: ask for estimates on cost and results, move people around among projects, ask for status reports, and cancel the project. Agile literature in general says that managers shouldn't be directly involved in analysis, design, coding, testing or integration. They may (but only occasionally!) facilitate the process between the customer and the developers; and it would be nice if they provided food and toys to keep the team happy. It appears, then, that the agile manger is expected to hover on the fringes of a project asking a few questions and throwing in goodies—but with ultimate power (cancellation) in her hip pocket. This scenario makes one wonder. Do managers really matter to the success of an agile project? Are they superfluous? What happens when managers step over the prescribed line—does it mean that the end of Agile Methodology as we know it and as handed down by the Agile Manifesto? The panel will explore this ticklish terrain by answering the following questions: Why Agile Methods and managers don't mix. Or do they? What can/should managers do in an agile environment? Under what conditions are managers an absolute requirement in an agile environment? (e.g. Government applications?) Do good management techniques apply to both Agile and non-Agile environments? Is management a dead-end profession in an Agile world?
Agile Methods are advocated as a way of producing better software. Advocates of agile methods suggest that practices such as keeping in close communication with your customers, frequent integration, and frequent assessment of project status will enable us to produce software that has value for the customer—quality software. It's hard to argue with that. But why is this any different than simply "good" software development practice? Why does saying "Scrum" "Agile" or "XP" grab peoples' attention? Why does it take a name for useful practices to be accepted? This panel will help us understand the role of hype in getting useful practices accepted or rejected. We will explore why it is that these good ideas have not been more widely used. Some of the questions that the panel and the audience will explore are: Why do we ignore proven practices until we see them packaged as a "method?" Can we do something different in the workplace or in school to teach these practices? Or is it the case that these practices are not universally good? This panel talks about agility in a different context than what is typical: we won't just discuss what agile practices are. We will explore why they are not more widely adopted, especially when not packaged as part of a "named" method like XP, and we will discuss why projects suffer even when the methods that can help them are well known. This panel will provide an entertaining and thought provoking forum for discussing an issue that is ever present in the world of technology: the role of hype. We concentrate on agile practices, moving beyond simply enumerating them, to discussing why they are not more widely adopted.