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
Bits and Pieces

Domain Language

Software is a model. We’re used to thinking of models as physical models that occupy space, but software represents a different kind of model, not a physical model but rather a behavioral model. Behavioral models take place in time rather than in space. You can think of them as black boxes where some input comes …

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
Bits and Pieces

Changeability

What does changeability mean in the context of software? Software is soft so shouldn’t it all be changeable? Not exactly. It turns out we have to build changeability into code, but this is rarely done. To do this we have to understand the nature of software and the nature of change. Software doesn’t behave like …

Read More
Bits and Pieces

An Object Model

If you were to draw out all the objects in your system and their relationship to each other at runtime, that would be a graphical representation of your object model. Object-oriented programming is about modeling the behavior of entities. It is a programming paradigm that, when used correctly, helps us build resilient systems that are …

Read More
Bits and Pieces

Acceptance Criteria

Acceptance criteria are simple tests to tell us when we’re finished implementing a feature. Knowing when we’re done building a feature is extremely important to developers because we’re not always sure how robust a feature should be. We don’t like it when our code breaks in the field so we want our code to be …

Read More
Bits and Pieces

Use Examples

Requirements have gone from lengthy specifications that state “The system shall…” for dozens of pages, ad nauseam, to a single sentence story. But stories aren’t meant to capture all the details needed to build a feature, so where do those details come from? Alistair Cockburn describes user stories as, “a promise for a conversation.” Stories …

Read More
Bits and Pieces

Developers Love Development

We software developers are a fortunate lot. We love what we do, and a lot of the time, when we’re actually building software, we’re very happy people. Unfortunately, this isn’t universally true since so many software development projects require developers to do a lot of other things aside from writing code such as sitting through …

Read More
Announcements

Podcast on Legacy Code Rocks

Join me and the owners of Corgibytes, Andrea Goulet and M. Scott Ford, on their podcast Legacy Code Rocks where we talk about how to avoid legacy code: https://www.stitcher.com/podcast/legacy-code-rocks/e/51642611?autoplay=true

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
Bits and Pieces

Collective Code Ownership

Like many artists I used to sign my work. When I wrote a class or a module, I put my initials in a comment that indicated I was the developer who wrote that code. This was a common practice at virtually everywhere I worked from IBM to small shops that developed financial or banking software. …

Read More
Rants

Forget About Velocity

I wrote about increasing velocity in my last post, but I just can’t let it be. I have to tell you about the dark side of velocity and why I don’t recommend that teams track velocity. Velocity is the amount of work a team can accomplish in a fixed period of time. It’s used to …

Read More
Rants

How to Increase Velocity

Do you want to know a trick to increase your team’s velocity? Now that I have your attention I want to tell you that tricks don’t work. I’ve seen people play tricks and sacrifice quality in order to get something out only to regret it later. So here’s my non-trick trick: Increase code quality today …

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
Bits and Pieces

Let Testability Guide You

In my last blog post, Let Code Quality Guide You, I said you don’t have to focus on all five CLEAN code qualities and that if you improve one, it’s typical that the others improve as well because they’re all interrelated. And that’s true, but they’re interrelated at a higher level, which points to a …

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
Bits and Pieces

What I Mean by CLEAN

If you’re reading my blog posts as they come out then you already know about CLEAN, which is my acronym for five code qualities that improve the testability and maintainability of software. If you’re reading these posts as archives in reverse chronological order, then the acronym is: NAELC. It’s unpronounceable, but it still contains goodness. …

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