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 …
Continue reading “Use Examples”
Read MoreDevelopers 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 …
Continue reading “Developers Love Development”
Read MorePodcast 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 MoreName 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 …
Continue reading “Name Things Well”
Read MorePairing 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 …
Continue reading “Pairing and Collective Code Ownership”
Read MoreCollective 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. …
Continue reading “Collective Code Ownership”
Read MoreForget 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 …
Continue reading “Forget About Velocity”
Read MoreHow 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 …
Continue reading “How to Increase Velocity”
Read MoreTestability 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 …
Continue reading “Testability Affects Code Quality”
Read MoreLet 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 …
Continue reading “Let Testability Guide You”
Read MoreLet 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 …
Continue reading “Let Code Quality Guide You”
Read MoreWhat 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. …
Continue reading “What I Mean by CLEAN”
Read MoreNonredundancy 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. …
Continue reading “Nonredundancy and Testability”
Read MorePathologies 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 …
Continue reading “Pathologies of Redundant Code”
Read MoreQuality 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 …
Continue reading “Quality Code is Nonredundant”
Read MoreAssertiveness 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 …
Continue reading “Assertiveness and Testability”
Read MorePathologies 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 …
Continue reading “Pathologies of Inquisitive Code”
Read MoreQuality 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 …
Continue reading “Quality Code is Assertive”
Read MoreEncapsulation 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 …
Continue reading “Encapsulation and Testability”
Read MorePathologies 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 …
Continue reading “Pathologies of Unencapsulated Code”
Read MoreQuality 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 …
Continue reading “Quality Code is Encapsulated”
Read MoreCoupling 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 …
Continue reading “Coupling and Testability”
Read More