A website on building software effectively
If there's a theme that runs through my work and writing on this site,
        it's the interplay between the shift towards agile thinking and the
        technical patterns and practices that make agile software development
        practical. While specifics of technology change rapidly in our
        profession, fundamental practices and patterns are more stable. So
        writing about these allows me to have articles on this site that are
        several years old but still as relevant as when they were written.
As software becomes more critical to modern business, software needs to
        be able to react quickly to changes, allowing new features to be
        conceived, developed and put into production rapidly. The techniques of
        agile software development began in the 1990s
        and became steadily more popular in the last decade. They focus on a
        flexible approach to planning, which allows software products to change
        direction as the users' needs change and as product managers learn more
        about how to make their users effective. While widely accepted now, agile
        approaches are not easy, requiring significant skills for a team, but more
        importantly a culture of open collaboration both within the team and with a
        team's partners.
This need to respond fluently to changes has an important impact upon
        the architecture of a software system. The
        software needs to be built in such a way that it is able to adapt to
        unexpected changes in features. One of the most important ways to do this
        is to write clear code, making it easy to understand what the program
        is supposed to do. This code should be divided into modules which allow
        developers to understand only the parts of the system they need to make a
        change. This production code should be supported with automated tests that
        can detect any errors made when making a change while providing examples
        of how internal structures are used. Large and complex software efforts
        may find the microservices architectural style
        helps teams deploy software with less entangling dependencies.
Creating software that has a good architecture isn't something that can
        be done first time. Like good prose, it needs regular revisions as
        programmers learn more about what the product needs to do and how best to
        design the product to achieve its goals. Refactoring is an essential technique to allow a
        program to be changed safely. It consists of making small changes that
        don't alter the observable behavior of the software. By combining lots of
        small changes, developers can revise the software's structure supporting
        significant modifications that weren't planned when the system was first
        conceived.
Software that runs only on a developer's machine isn't providing
        value to the customers of the software. Traditionally releasing software
        has been a long and complicated process, one that hinders the need to
        evolve software quickly. Continuous Delivery uses
        automation and collaborative workflows to remove this bottleneck,
        allowing teams to release software as often as the customers demand. 
        For Continuous Delivery to be possible, we need to build in a solid
        foundation of Testing, with a range of
        automated tests that can give us confidence that our changes haven't
        introduced any bugs. This leads us to integrate testing into
        programming, which can act to improve our architecture.
Photostream

San Francisco
Data Management
There are many kinds of software out there, the kind I'm primarily
          engaged is Enterprise Applications. One of the enduring problems we
          need to tackle in this world is data management. The aspects of data
          managment I've focused on here are how to migrate data stores as their
          applications respond to changing needs, coping with different contexts
          across a large enterprise, the role of NoSQL databases, and the
          broader issues of coping with data that is both Big and Messy.
Domain-Specific Languages
A common problem in complex software systems is how to capture
          complicated domain logic in a way that programmers can both easily
          manipulate and also easily communicate to domain experts. Domain-Specific Languages (DSLs) create a custom language
          for a particular problem, either with custom parsers or by conventions
          within a host language.
Books
I've written seven books on software development, including
          Refactoring, Patterns of Enterprise Application Architecture, and UML
          Distilled. I'm also the editor of a signature series for
          Addison-Wesley that includes five jolt award winners.
My Books Page...
Conference Talks
I'm often asked to give talks at conferences, from which I've
          inferred that I'm a pretty good speaker - which is ironic since I
          really hate giving talks. You can form your own opinion of my talks by
          watching videos of some my conference talks.
My Videos Page...
Board Games
I've long been a fan of board games, I enjoy a
           game that fully occupies my mind, clearing out all the serious
          thoughts for a bit, while enjoying the company of good friends. Modern
          board games saw dramatic improvement in the 1990's with the rise of
          Eurogames, and I expect many people would be surprised if they haven't
          tried any of this new generation. I also appear regularly on Heavy Cardboard.
My Board Games page...