Use Helper Methods
What? Helper methods? Whenever I see a class called Helper in code I think that the developer who wrote it wasn’t willing to take the time to discover what objects were really responsible for those behaviors. Although we would like to believe otherwise, in reality, there is no benevolent helper class in the world that …
Continue reading “Use Helper Methods”
Read MoreInstrument Your Tests
Here is the first of seven blog posts based on the section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, called Seven Strategies for Using Tests as Specifications. In this first post, I’ll discuss a technique called instrumentation that I learned from Scott Bain and Amir …
Continue reading “Instrument Your Tests”
Read MoreWhy Practice 7: Specify Behaviors with Tests
Developing software is a complex activity. Having worked with thousands of professional software developers, I recognize that there are many ways to implement any set of requirements and many are equally valid. This is true at least from the computer’s perspective but from the human perspective, we favor software that’s straightforward to understand and modify …
Continue reading “Why Practice 7: Specify Behaviors with Tests”
Read MoreMake Each Test Unique
I want to conclude this series of Seven Strategies for Great Acceptance Tests with the advice to make each test unique. I know this is easier said than done but it does get to the very core of what quality software development it’s all about. When our unit tests test units of behavior, then every …
Continue reading “Make Each Test Unique”
Read MoreSplit Behaviors on Acceptance Criteria
We think about what we build at different layers of abstraction. At the highest level, we have the minimum marketable feature set or MMF, which is composed of a list of features. A feature is some value that someone gets from using the system. This may involve the fulfillment of several things in the system, …
Continue reading “Split Behaviors on Acceptance Criteria”
Read MoreUse Examples
One of my favorite books on acceptance test-driven development is by Gojko Adzic called Specification by Example. This book talks about how you can specify the features of a system through examples cleanly and clearly so that they are straightforward to work through. Examples allow us to quickly flesh out details and drive out inconsistencies …
Continue reading “Use Examples”
Read MoreSpecify Edge Cases
Another huge benefit of Acceptance Test-Driven Development or ATDD is that it helps us flesh out edge cases, exceptions, and alternate paths for a story to follow. I far prefer to specify edge cases and exceptional paths through acceptance tests rather than with use cases because acceptance tests are more articulate and they are executable. …
Continue reading “Specify Edge Cases”
Read MoreAutomate Acceptance Criteria
You can do acceptance test-driven development (ATDD) manually without the aid of a tool by just keeping track of the acceptance criteria for a story and noting when it meets the criteria. Automating the process is helpful but the real value comes in articulating the acceptance criteria ahead of time. It is estimated that more …
Continue reading “Automate Acceptance Criteria”
Read MoreKnow Who it’s for and Why They Want it
Another huge benefit of acceptance test-driven development or ATDD is that it helps us get clear on defining features for a specific type of user. And it also helps us get clear on why they want that future. Why is really the key question. Why do we want to implement or build a feature in …
Continue reading “Know Who it’s for and Why They Want it”
Read MoreGet Clear on the Benefits of What You are Building
I have heard it said from a number of sources that the largest source of defects and the ones that are the most expensive to fix are our misunderstandings of requirements. Requirements are essential. If we build the wrong stuff, something the customer doesn’t want or need, then it doesn’t matter how beautiful our code …
Continue reading “Get Clear on the Benefits of What You are Building”
Read MoreWhy Practice 6: Write the Test First
I wrote Beyond Legacy Code to talk about the value of technical practices in software development. One of the most valuable technical practices for me has been test-first development and I really wanted to discuss it in ways that I hadn’t seen it discussed before that I found to be productive. Having exposed thousands of …
Continue reading “Why Practice 6: Write the Test First”
Read MoreKeep Code Testable
I’d like to wrap up these Seven Strategies for Increasing Code Quality with a strategy that kinda sums up all the rest of them—keep code testable. Untested software carries a great deal of risk. If a developer who implements a feature test it manually only once then that feature may be affected by other changes …
Continue reading “Keep Code Testable”
Read MoreName Things Well
Shakespeare said, “a rose by any other name…” To him, a name was just a label for something deeply intrinsic within the thing itself. But in software, it’s the opposite. There is no intrinsic-ness to any software objects except what they do and so our names become more than labels, they become expressions of the …
Continue reading “Name Things Well”
Read MoreHide How with What
As I was writing my book, Beyond Legacy Code, I started to see a pattern emerge. Practice 1 is “say what, why, and for whom before how.” One of the anti-patterns in software development, and therefore something that we want to avoid, is leaking implementation details in our code by saying how we do something …
Continue reading “Hide How with What”
Read MoreUnderstand Trade-Offs
When we talk about code qualities and code quality practices we may have a tendency to believe that more is better, universally but that’s not always the case. We want software to run fast but we also want it to be easy to understand when we go to change it. Sometimes these characteristics and qualities …
Continue reading “Understand Trade-Offs”
Read MoreLet Go of Perfectionism
It was Voltaire who said, “Don’t let the perfect be the enemy of the good.” By that what I believe he meant was that while it might be good to strive for perfection we have to realize that we won’t always achieve it and if we are going to insist on everything being perfect we …
Continue reading “Let Go of Perfectionism”
Read MoreShare Common Quality Practices
In addition to sharing a common definition of what quality means in terms of CLEAN code, we also must share some common quality practices that can help us increase the quality of the code we create. These practices should be straightforward to apply so we can easily make them our habits. Here are some of …
Continue reading “Share Common Quality Practices”
Read MoreGet Crisp on the Definition of Quality
When we talk about quality we may think of a fine piece of furniture or the quality service we receive at a fancy restaurant but what does quality mean in the context of software? I find that when we talk about the domain of ideas, and software is in the domain of ideas, that we …
Continue reading “Get Crisp on the Definition of Quality”
Read MoreWhy Practice 5: Create CLEAN Code
The fifth practice from my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, is called Create CLEAN Code. CLEAN is an acronym but it’s also a shout out to the books Clean Code and The Clean Coder by Robert C. Martin. and to the Clean Code talks, a …
Continue reading “Why Practice 5: Create CLEAN Code”
Read MoreTrack Progress
As the proverb says, “Data speaks louder than words.” Well, if it’s not a proverb then it should be. The only way to know for sure if pair programming is right for your team is to track progress and see if the metrics that are important to you improve as your team starts to become …
Continue reading “Track Progress”
Read MoreLet Teams Decide on the Details
As hard as it can be sometimes to convince managers to let their teams try pair programming and see if it improves their overall productivity and quality, sometimes I have the exact opposite problem and I have managers who want to force teams to do pair programming, even when the teams don’t feel it’s right …
Continue reading “Let Teams Decide on the Details”
Read MoreTry All Configurations
Another key to discovering what works best for you when doing pair programming is to try all configurations. By that I mean mix it up as much as possible. On each project, you should try pairing with at least everyone once. Also try pairing for different periods of time before you switch pair partners, like …
Continue reading “Try All Configurations”
Read More