Michael C. Feathers's Blog, page 3

Edges in Software

One of my favorite sayings is “If you take care of the corners, the room takes care of itself.”

For the longest while I thought it was something that Frank Lloyd Wright had said but I haven’t been able to find an attribution. Regardless, I think that the idea is sound. The edge cases in our software define it. Ideally, we shouldn’t have many of them, but when we do they should be there by design. Software without edges is simpler and often more robust but there are tradeoffs. Let’s look at i...

Revealing Interfaces

In nearly every OO application there’s at least one large class. By large, I mean a class that has 15 or more methods. We expect classes to have focus and it’s hard to make the case that a class with that many methods is about one thing. There will be some sort of grouping. Sometimes it’s explicit in the names of the methods, sometimes it’s not. Classes like this can be hard to understand. When we do try to understand them, we often inadvertently make it harder for ourselves - we concentrate...

Unary Call Sites and Architecture

In an ideal world we’d be able to see more in our editors and IDEs. We see our code, and that’s just about enough to work but there’s so much more that we can know.

One of the things I’d like to know is the number of call sites that each method has. In frameworks or libraries, we’ll have methods that are never called internally - other code calls them but we don’t. Inside a component or a repo, most methods are called from more than one place or call site. Other functions are called just onc...

Twitter, Reddit and Conway's Law

Before I started programming I majored in architecture. I have a strong visual imagination and as a teen buildings just “popped” into my head without me putting them there. As a career, it seemed like a natural fit but unfortunately I never really learned how to draw well enough so I moved on to engineering and computer science. Before I made that decision, I spent a lot of time in the library studying design. The most interesting books were ones that described a view of architecture that I...

Is Technical Debt Just a Metaphor?

I’ve been hearing people talk a lot more about Technical Debt recently. I’m glad. Anything we can do to play more attention to long term quality is good. Technical Debt is a valuable frame for those discussions. No one wants to be in an impossible situation and teams that keep accumulating Technical Debt often end up there. It’s a land of risky rewrites - which are essentially an attempt to dig out of a hole.

When I wrote Toward a Galvanizing Definition of Technical Debt what I was doing was...

Scythe - Coverage in Production to Find Dead Code

A while back I wrote about what it takes to kill code. I won’t take up any time repeating why it’s a good idea to get rid of code that’s dead or low value. I think that anyone who’s spent time trying to understand or change some area of code only to find out that it’s never really used knows how frustrating it can be.

As often as this happens, we just tend to live with dead code.

It seems like it should be easy to find code that doesn’t execute, but aside from static analysis tools - which s...

Toward a Galvanizing Definition of Technical Debt

Everyone involved in software development seems to know what Technical Debt is. It’s a powerful metaphor. In Ward Cunningham’s original formulation, Technical Debt was the accumulated distance between your understanding of the domain and the understanding that the system reflects. We all start out with some understanding of a problem, and we write code to solve that problem. But, we learn as we go. If the code doesn’t keep up with that learning, we have to continually stumble over a conceptua...

The Ergonomics of Type Checking

The debate between proponents of static and dynamic typing never seems to die down, but it has matured. Most people I encounter seem to be ready to accede that people can do good work in a dynamically typed language. On the other side, it’s becoming more and more apparent that as type systems grow, the number of error classes we can eradicate grows as well. The fact that more people have experience with both static and dynamic languages today has certainly helped. I think we can thank JavaScr...

Characterization Testing

I think that the most confusing thing about testing is the word testing. We use it for many things, from exploratory testing and manual testing to unit testing and other forms of automation. The core issue is that we need to know that our code works, and we’ve lumped together a variety of practices and put them under this banner. We can look for some common strands between them but they are hard to find.

Most types of testing have the quality of being about correctness. We test our code to se...

To Kill Code

Economics is a great frame for understanding problems, but it can cloud many issues as well. The software development community has fought for years against the idea that IT should be viewed as a cost center. We’d like to see it as a value creating investment. Yet, as much as we’d like to see it that way, we speak about code as a liability. Experienced developers know that if we can deliver value with less code, we’re better off.

Much of the discussion around Technical Debt has this same iss...