Joseph W. Yoder


Joseph W. Yoder is a founder and principal of The Refactory, Inc., a company focused on software architecture, design, implementation, consulting and mentoring on all facets of software development. Joseph is an international speaker and pattern author, long standing member of the ACM, and the President of The Hillside Group, a, a group dedicated to improving the quality of software development. Joseph specializes in Architecture, Analysis and Design, Java, C#/.NET, Smalltalk, Patterns, Agile Methods, Adaptable Systems, Refactoring, Reuse, and Frameworks. Additionally, Joe is an accomplished author, having written a few dozen published papers, including being an author of the Big Ball of Mud pattern, which illuminates many fallacies in the approach to software architecture. Additionally Joe has trained and mentored developers on various types of software applications.

Joseph W. Yoder evolved from the Software Architecture and Patterns group at the University of Illinois. Joe has worked on various projects during his career that has incorporated many technologies. These range from stand- alone to client-server applications, web applications, web services, cloud computing, service oriented architecture, multi-tiered, various databases, object-oriented, frameworks, human-computer interaction, collaborative environments, and domain-specific visual-languages. In addition these projects have spanned many domains, including Medical Information Systems, Financial Systems, Ordering, Import, Invoicing, Print, Shipping, Warehouse Management, Manufacturing, Medical Examination, Statistical Analysis, Scenario Planning, Client-Server Relational Database System for keeping track of shared specifications in a multi-user environment, Telecommunications Billing System, and Business & Medical Decision Making.

Joe teaches Agile Methods, Design Patterns, Object Design, Refactoring, and Testing in industrial settings and mentors many developers on these concepts.  Other projects involve working in both the Java and .NET environments deploying Domain-Specific Languages for clients. Joe presents tutorials and talks, arranges workshops, and organizes leading technical conferences held throughout the world, including international conferences such as Agile, Agile Portugal, Encontro Ágil in Brazil, AOSD, CBSoft, JAOO, QCon, PLoP, AsianPLoP, SugarLoafPLoP in Brazil, OOPSLA, ECOOP, SATURN, and SPLASH. Joe thinks software is still too hard to change. He wants do something about this and believes that with good patterns and by putting the ability to change software into the hands of the people with the knowledge to change it seems to be on promising avenue to solve this problem. Joe currently resides in Urbana, Illinois. (home page)

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:

When Should You Consider Meta-Architectures? Using Meta to Scale the Cloud

Language: EN

The recent surge in cloud computing has really changed the way architectures are evolving. Platforms as a Service (PAAS) and Software as a Service (SAAS) is becoming where organizations can get necessary resources as needed without having to worry about many hardware and software configuration issues. It is no longer the case that systems need to be isolated to a single platform or set of platforms with a lot’s of possible maintenance issues. The core premise with the cloud is that different resources including services can be allocated and integrated as needed, adapting to the specific needs of the organization or systems being built.

Additionally, “Cloud Computing” allows for a large numbers of users and flexibility for different services being provided. Different types of resources and services provide maximum configuration and flexibility within the cloud and metadata is key for this type of variability. , It is quite often the case that cloud applications need to be able to dynamically adapt at runtime, without stopping the application. It is important to provide a way for users to customize their own experience with cloud applications. Trying to do this without ways for users to describe and adapt to their specific needs will not scale at all. This scaling and adaptability problem becomes even more imperative when you have many different organizations with different requirements. If, in the cloud, these organizations cannot adapt and define their different needs, the cloud solution would not be that compelling to them. In these situations, it is important to allow the ability for different customizations of the services, and to allow the users themselves to dynamically configure the systems. In order to be able to adapt to these dynamic requirements, the demand for Meta-architectures, such as those provided by Cloud solutions such as SalesForce, are necessary to make these types of adaptability possible!

What does it take to build a system that can be changed and adapted without programming? When is it appropriate to consider stepping into the meta world to build such an extensible system specifically in the “Cloud” environment? This talk answers these questions and presents ideas about using meta-architecture to scale in the “Cloud”.

Tutorial I :

Project Retrospectives (Why, How, When)

Speakers: Rebecca Wirfs-Brock, Joseph W. Yoder

Duration: 2 hours

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


Gold Sponsors:

Silver Sponsors:

  • EPAM
    • j-labs
      • UBS
        • Sii
        • Sponsors:

          Sponsor JDD Afterparty:

          Internet and Gamezone Sponsor:

          • EPAM
          • Media Partners:

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