Barry has played various roles in his 17 years in the software industry, including lone developer, team lead, director, and Agile coach and mentor. Barry is one of the few native Atlantans, currently specializing in coaching and mentoring for Agile software development in addition to doing contract software development. Over the years, he has developed on multiple platforms, focusing primarily on Microsoft technologies and then Java from 2003 onward. He views technology as a set of tools, and embraces the use of dynamic as well as statically-typed languages, procedural, object-oriented, and functional programming, each having their own strengths in a given problem domain.
Prior to his career in software, Barry Hawkins spent 10 years designing, selling, and delivering turn-key industrial packaging and marking systems into manufacturing plants throughout the southeastern United States. He was responsible for the implementation, maintenance, and support of every system he sold, which was a formative experience that continues to influence his approach to consulting and coaching.
The first book on Domain-Driven Design was published in 2003, authored by Eric Evans, who first coined the term and distilled the time-tested principles and patterns that make up the practice of DDD. In recent years, simplification and increased testability through frameworks like Spring, Hibernate, and others has substantially reduced the complexity of application infrastructure, allowing teams to turn their focus to honing their approach to software design. Domain-Driven Design meets practitioners in that quest with principles, practices, and process to recapture the spirit of software excellence that has been lost in so many of today’s technology practices.
This talk will introduce the foundations of Domain-Driven Design, and present several facets of DDD in action:
A large number of Agile adoption initiatives start at a grassroots level among software developers who have grown uncomfortable with the blatant inefficiencies of classic approaches to software development. The teams who succeed often find themselves working more efficiently, but the impact of their success is hindered. They are still relegated to taking large functional specifications and digesting them into iterations of work, with little if any feedback from the business side of the house. A series of successful sprints can still be met with the cliche “that’s not what we wanted” response, leaving development teams relegated to the “well that’s what you wrote” response. Until the business people are participating in iterative feedback and realizing the flexibility and freedom they have in working with these Agile teams, there will always be a ceiling on their success.
Attendees of this talk will be guided through pragmatic, proven approaches for building that bridge to the business representatives. A thorough treatment of how user stories can be used as an effective tool that allows business and development sides of the house to meet in the middle, as well as when and how to bend in order to move the adoption process forward. It will also cover the sometimes subtle pitfalls and hotspots of promoting a fully Agile process with participating business team members, and ways to hopefully allow good deeds to continue to go unpunished.