Encapsulate Change

Software development is a unique human activity but it bears resemblance to other activities such as math, writing, and engineering. I think of writing software as a modeling process but unlike modeling physical things that occur in space, we’re modeling processes that occur in time. Therefore, writing software is a process of creating models that are accurate and understandable.

It turns out that there are many ways we can model processes in software. We can model processes as a set of instructions or procedures. We can model them through a collection of objects that interact. We can even model a process as a series of transformations. Different processes call out a need for different representations.

The way we build software varies tremendously because we solve a whole variety of problems. This is why we have different programming languages and frameworks as well as platforms. There is no one-size-fits-all.

Software is used in almost every industry to solve a huge range of problems so it’s no wonder that the software industry itself has many facets to it. We specialize in languages and frameworks as well as different technologies but beyond that, we have to have some common thread that unites us, a common understanding about software development itself. I feel that all too often this is lacking in our industry. It seems like the goal is often just to do something that works and ship it without much regard to its supportability. The end result is that we’re cutting corners and we’re writing code that’s not as supportable as it could be. This drives up the cost of maintaining software and makes it difficult to extend.

One of the main benefits of object-oriented programming is that it allows us to build encapsulated, modular components that are independently testable and upgradable. However, rarely do I see developers use object-oriented languages to build software with these advantages. Instead of injecting dependencies as needed, they instantiate them inline and the result is that they can’t be tested independently.

In an object-oriented system, behaviors should be encapsulated in objects in order to limit side effects and allow the creation of a more modular system.

Code should be expressive, just like good literature. Code should express what it does and do its job plainly and clearly. Software should be expressed in the domain language and encapsulated in objects so that they’re more maintainable.

By spreading the knowledge of a system across a collection of interacting objects, we minimize the impact of change when it happens because change will typically only affect the objects that are directly involved in the change so the rest of the system will be encapsulated and shielded from the change. This is good because it minimizes the impact of adding new features to existing software.

Software lifecycle is important. We spend only 20% of our budget before release and 80% of our budget after the initial release of software. Less than a third of that is maintenance. The rest is fixing defects and providing enhancements. We are essentially building unmaintainable software in our industry and that is the norm.

Changeable software is not that much more difficult to create. It does take some more typing to put concepts into their own encapsulated entities but it also simplifies testing. Ideally, we would like to produce complex behaviors by applying a series of simple behaviors that we can independently test and verify.

要查看或添加评论,请登录

David Scott Bernstein的更多文章

  • Green Tests and Red Tests

    Green Tests and Red Tests

    In practice, I found that there are times that I want a bit more test coverage than I get from just doing test-first…

  • Radiators and Silos

    Radiators and Silos

    In the old days of corporate America, the way you got ahead was through hard work and perseverance. You strove to…

    1 条评论
  • Makers and Menders

    Makers and Menders

    I’ve been getting back into some research interests of mine that require data acquisition from a variety of sensors so…

  • Core Developer Practices

    Core Developer Practices

    Every field of engineering has a core set of practices that they follow and software engineering is no different. But…

    1 条评论
  • Still XP After All These Years

    Still XP After All These Years

    Are you humming in your head Paul Simon’s “Still Crazy After All These Years”? I am. And it does seem crazy.

  • The Importance of Continuous Integration

    The Importance of Continuous Integration

    Perhaps the most important yet easiest to implement of all the software development practices in Agile is continuous…

  • The Importance of Technical Practices (Again)

    The Importance of Technical Practices (Again)

    Software development has undergone many revolutions over the last few decades. The way we build software today is…

  • Summary of Seven Strategies Series

    Summary of Seven Strategies Series

    I finished my “Seven Strategies” series of 72 blog posts with seven strategies for implementing each of the nine…

    1 条评论
  • Refactor to Learn What Not to Do

    Refactor to Learn What Not to Do

    One of the things that I was not expecting when I started refactoring other people’s code was that I started to see…

    4 条评论
  • Refactor to Clean Up Before Moving On

    Refactor to Clean Up Before Moving On

    Of course, the best time to refactor code is while it’s fresh in your mind, right after having worked with it. Once I…

社区洞察

其他会员也浏览了