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)


Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work

Język: EN

Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming, smelly anti-patterns. Yet how BBoM architectures come into existence and successfully evolve is much more nuanced. BBoMs often do not result from well-intentioned design ideas gone wrong. Nor are they simply an accretion of expedient implementation hacks. Often BBoM systems can be extremely complex, with unclear and unstable architectural boundaries and requirements. Because of their complexity, BBoM architectures are likely not understood by any single mind. They typically are fashioned out of many parts, which together comprise a sprawling whole. So BBoM systems can and do have good, as well as bad and ugly parts. Successfully deployed BBoM systems continue to work well enough, in spite of their design flaws. How can that be?

Much has happened in our industry since the original discussion and publication of the Big Ball of Mud paper in 1998. When that paper was originally published, agile methodologies such as eXtreme Programming and Scrum were just beginning to gain popularity. The growth and popularity of agile practices might be partially due to the fact that the state of the art of software architectures is so muddy. Being agile, with its focus on extensive testing and frequent integration, arguably makes it easier to deal with evolving architectures and keeping systems working while making significant improvements and adding functionality. However, although Agile has been around for quite some time, we can see that it still does not prevent Mud.

This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier. Some of these include: Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship and the like.. The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.

  • jdd


Platynowy Sponsor

  • Luxoft

Złoci sponsorzy

Srebrni sponsorzy


Sponsor Afterparty

Patroni medialni

  • Teetbee
  • Kariera PLUS
  • Programosy
  • KSUG
  • helion
  • Polish JUG
  • Poznan JUG
  • SDJ
  • pcfoster
  • pcfoster
  • pcfoster