Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software
The posts in this group of categories relate in some way to my book, Beyond Legacy Code (http://BeyondLegacyCode.com). Post related to one of specific nine practices from the book are assigned subcategories. For more information about my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, please visit my publisher’s website
https://pragprog.com/book/dblegacy/beyond-legacy-code or check out my Amazon webpage https://www.amazon.com/Beyond-Legacy-Code-Practices-Software/dp/1680500791

Integrate Continuously

Commit Frequently

One metric that I think is most important to look at during an Agile transformation is the frequency of commits that developers make due to the build. This gives us a huge amount of information about several important things. First and foremost, it indicates the amount of friction in the build and how much work …

Read More
Write the Test First

Doing More of What We Love

Developers love writing code. It’s what we’re good at. It’s what we do. But all sorts of things get in our way: Meetings. Reading and interpreting specifications. And the worst time-sink of all—debugging. Most of us would rather do anything other than debugging, but that’s where we end up spending a lot of our time. …

Read More
Refactor Legacy Code

Don’t Be Scared to Touch Legacy Code

As Frank Herbert said in Dune, “Fear is the mind-killer.” He could have been talking about legacy code. As soon as we fear touching legacy code, we won’t do it. As a consultant, I know that merely giving my clients tools and techniques for working with legacy code isn’t enough, I also have to help …

Read More
Write the Test First

Flying Blind

The way most software is developed—designing entire programs on paper and then typing them into a computer in their entirety before they run—is like flying blind. Software is virtual. We can’t see it or touch it. The only feedback we get is when we compile and run our program. But on a Waterfall project that …

Read More
Implement the Design Last

Change Your Mind, Again

When I was a kid I was told that it was a woman’s prerogative to change her mind. For some people, though, changing your mind can be seen as wishy-washy. We like to stand by what we say. We like to be right. But giving yourself the freedom to change your mind is one of …

Read More
Build in Small Batches

Think Small

The key to unlocking agility is to think small. The whole purpose of building software in time boxes is to help us get better at scope-boxing, which is working in smaller pieces—breaking large tasks down into smaller tasks. I’m not a big believer in using story points. It’s better to be able to break down …

Read More
Write the Test First

Writing Good Tests

As Misko Hevery, the author of AngularJS, says in his outstanding Google Tech Talk series “Clean Code Talks,” most developers assume they know how to write a good test but they don’t. Knowing how to write a good test is paramount to being successful with TDD. Tests must be unique, expressive, and independent—easier said than …

Read More
Integrate Continuously

Early Automation Experiences

We didn’t do a lot of automated testing as an industry back in the late 1980s, but I did. I was working for IBM on one of the first hypertext implementations, which later became HTML. Our authoring system created very complex data structures that required us to do extensive testing to validate they were correct. …

Read More
Create CLEAN Code

Name Things Well

I’ve said that the five code qualities we’ve been discussing are quantifiable. That is, we can create more of them if we want. Let’s discuss how to do this. The one code quality I’d like to focus on is cohesion. To me, it makes the most sense and I can easily see when my code …

Read More
Collaborate

Pairing and Collective Code Ownership

I’ve been writing a lot recently on pair programming and mob programming and I’ve been syndicating my posts at Dzone.com, which is a web portal for software developers. I’ve received some scathing comments about pairing and mobbing from people who’ve obviously never tried it. If something doesn’t work for you then by all means abandon …

Read More
Create CLEAN Code

Testability Affects Code Quality

Why is it that if we all agree that CLEAN code is good to strive for that the vast majority of software as written lacks these qualities? The only answer I can come up with is that we’re so focused on short-term gains that we forget about the long-term consequences. I have to point out …

Read More
Create CLEAN Code

Let Code Quality Guide You

Back in the 1990s, when I was faced with multiple design choices, I’d have to code them up in multiple ways to figure out which one was best. This was time-consuming, and evaluating design choices was one of the hardest things for me. But now I have a better approach, thanks to code qualities. If …

Read More
Create CLEAN Code

Nonredundancy and Testability

Redundancy is always a maintenance issue. If you have to change redundant code, you have to do it in multiple places. If you have to extend redundant code, you have to do it in multiple places. When you have to test redundant code, you have to modify tests in multiple places. You get the idea. …

Read More
Create CLEAN Code

Pathologies of Redundant Code

Remember Y2K? Before the turn of the millennium, computer storage was at such a premium that years were stored with only the last two digits so the year 1989 was stored as 89. This worked fine—up until the end of 1999, at which point the year returns to 00 which many programs would interpret as …

Read More
Create CLEAN Code

Quality Code is Nonredundant

The last code quality that we’ll discuss in this series, the “N” in CLEAN, calls for code to be nonredundant. On its surface it seems pretty straightforward but there is some subtlety to redundancy as well. It’s easy to see why redundancy in code is a bad thing. It’s a duplicated effort. It means that …

Read More
Create CLEAN Code

Assertiveness and Testability

It’s quite difficult to test inquisitive code. Very often the results of running a piece of code can only be found in another object. Therefore a test must use a separate entity, which we typically call a “spy,” to monitor the external object and validate that it was called correctly. This adds unnecessary complexity to …

Read More
Create CLEAN Code

Pathologies of Inquisitive Code

Objects that are not assertive are by default inquisitive. They are either inquisitive or they are mute. They don’t interact with the outside word at all. If an object interacts with other objects, the real question with regard to assertiveness is, “Who’s in charge?” One object can delegate a task to another object but still …

Read More
Create CLEAN Code

Quality Code is Assertive

The next code quality in this series of posts, the “A” in CLEAN, stands for assertive. I don’t hear a lot of people talking about it but I think it’s an important code quality. We want the software we write to be assertive, to be in charge of its own state. We want objects to …

Read More
Create CLEAN Code

Encapsulation and Testability

Poorly encapsulated software is hard to test because without clear boundaries, what we actually test becomes significantly larger than what we need to test. This makes our tests run slower and it also makes them brittle so our tests are harder to maintain. When code is unencapsulated, it can be hard to lock down behaviors …

Read More
Create CLEAN Code

Pathologies of Unencapsulated Code

Unencapsulated code is code that exposes its implementation or references how it does something. This can happen in subtle ways, so we have to be careful to create strong contracts through our method signatures. Poorly encapsulated code is very difficult to work with. It can quickly sprout new bugs at the slightest change. Lack of …

Read More
Create CLEAN Code

Quality Code is Encapsulated

To encapsulate something is to envelope and protect it. Encapsulation is a fundamental facility that every programming language supports at some level. Encapsulation is about hiding implementation details so ideas can be expressed at higher levels and to protect those details from other parts of the system. To me, most fundamentally, encapsulation means hiding implementation …

Read More
Create CLEAN Code

Coupling and Testability

I can learn a lot about the kind of coupling in a system by listening to how people talk about testing it. If someone says, “I couldn’t test that without instantiating half the system,” then I know they have some coupling issues. Unfortunately, most systems I have seen—and most systems I know other people have …

Read More