Rebecca Wirfs-Brock


Rebecca Wirfs-Brock (born 1953 in Portland, Oregon) is an author and consultant in object-oriented programming and object-oriented design, the founder of the information technology consulting firm Wirfs-Brock Associates, and inventor of Responsibility-Driven Design, the first behavioral approach to object design. Wirfs-Brock first coined the „-driven” meme in an OOPSLA 1989 paper she co-authored with Brian Wilkerson. Before that time, the most prevalent way of structuring objects was based on entity-relationship modeling ideas (popularized by James Rumbaugh, Steve Mellor and Sally Shlaer). She wrote about object role stereotypes in 1992 in a Smalltalk Report article and this influenced the UML notion of stereotypes. Her invention of the conversational (two-column) form of use cases that was then popularized by Larry Constantine.

Presentation I :

Pragmatic, Not Dogmatic TDD: Rethinking How We Test

Speakers: Rebecca Wirfs-Brock, Joseph W. Yoder

Language: EN

One thing that has discouraged people from incorporating TDD into their organization is the common misperceptions that tests should always be written first, before writing any production code, and, that tests and code should be developed in many tiny increments. We believe that TDD is more about thinking carefully about how best to validate that your software meets your requirements. Testing and validation should drive your development process (that’s why we are fans of being Test Driven), but we think there is so much more to testing than writing lots of unit tests.

The typical approach to TDD usually focuses on having developers write many unit tests that may or may not add value. Instead, we recommend you adopt a testing strategy that gives you the ost leverage. So, for example, rather than merely writing many unit tests, you can often get more value by defining the appropriate user-level acceptance tests. Testing should drive your development but not at the expense of every other coding and design practice). One size or one approach for testing does not fit every organization or team.

This talk challenges the “norm” for TDD. Testing should be an integral part of your daily programming practice. But you don’t always need to derive your code via many test-code-revise-retest cycles to be test-driven. Some find it more natural to outline a related set of tests first, and use those test scenarios to guide them as they write code. Once they’ve completed a “good enough” implementation that supports the test scenarios, they then write those tests and incrementally fix any bugs as they go. As long as you don’t write hundreds of lines of code without any testing, there isn’t a single best way to be Test Driven.

There’s a lot to becoming proficient at TDD. Developing automated test suites, refactoring and reworking tests to eliminate duplication, and testing for exceptional conditions, are just a few. Additionally, acceptance tests, smoke tests, integration, performance and load tests support incremental development as well. If all this testing sounds like too much work, well…let’s be practical. Testing shouldn’t be done just for testing’s sake. Instead, the tests you write should give you leverage to confidently change and evolve your code base and validate the requirements of the system. That’s why it is important to know what to test, what not to test, and when to stop testing. More discussion about Pragmatic TDD can be found here:

Presentation II:

Why We Need Architects (and Architecture) on Agile Projects

Language: EN

The rhythm of agile software development is to always be working on the next known, small batch of work. Is there a place for software architecture in this style of development? Some people think that software architecture should simply emerge and doesn’t require ongoing attention. But it isn’t always prudent to let the software architecture emerge at the speed of the next iteration. Complex software systems have lots of moving parts, dependencies, challenges, and unknowns. Counting on the software architecture to spontaneously emerge without any planning or architectural investigation is at best risky.

So how should architecting be done on agile projects? It varies from project to project. But there are effective techniques for incorporating architectural activities into agile projects. This talk explains how architecture can be done on agile projects and what an agile architect does.

Tutorial I :

Testing System Qualities

Speakers: Rebecca Wirfs-Brock, Joseph W. Yoder

Duration: 2 hours

Language: EN

Agile teams incrementally deliver functionality based on user stories. In the sprint to deliver features, frequently software qualities such as security, scalability, performance, and reliability are overlooked. Often these characteristics cut across many user stories. Trying to deal with certain system qualities late in the game can be difficult, causing major refactoring and upheaval of the system’s architecture. This churn isn’t inevitable. Especially if you adopt a practice of identifying those characteristics key to your system’s success, writing quality scenarios and tests, and delivering on these capabilities at the opportune time. We will show how to write Quality Scenarios that emphasize architecture capabilities such as usability, security, performance, scalability, internationalization, availability, accessibility and the like. This will be hands-on; we present some examples and follow with an exercise that illustrates how you can look at a system, identify, and then write and test quality scenarios.

Tutorial II :

Project Retrospectives (Why, How, When)

Speakers: Rebecca Wirfs-Brock, Joseph W. Yoder

Duration: 2 hours

Limit: 40 attendees

Language: EN

Retrospectives is becoming an accepted an important practice as part of the software development process. In fact, most Agile practices promote some form of regular retrospectives. At periodic times throughout any software project, team members will benefit from taking some time to examine what is going well, what is not going well, and what can be done to correct any challenges. But how does a team do this? When and how often should they be done? This tutorial will introduce techniques for conducting project retrospectives. Participants will get the opportunity to try these techniques so they can take them back to their teams.

  • jdd


Złoci sponsorzy

Srebrni sponsorzy

  • EPAM
    • j-labs
      • UBS
        • Sii
        • Sponsorzy

          Sponsor Afterparty

          Sponsor Internetu i Gamezone

          • EPAM
          • Patroni medialni

            • Teetbee
            • helion
            • Polish JUG
            • Poznan JUG
            • SDJ
            • pcfoster
            • pcfoster
            • pcfoster