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
Automate 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 MorePut in an Honest Day
While I am a big believer in pair programming I don’t believe that we should do it all the time. Pairing is exhausting! After a pair programming session, I am usually wiped out because I am working hard the whole time. I have someone looking over my shoulder analyzing everything that I do. That’s great …
Continue reading “Put in an Honest Day”
Read MoreSwap Roles Frequently
Another important technique for engaging developers in pair programming is to swap roles frequently. For new pairs who are just starting to work together, I recommend swapping roles every 2 to 20 minutes. For more established pairs who’ve worked together well, I recommend swapping roles every 20 to 60 minutes, although that could become much …
Continue reading “Swap Roles Frequently”
Read MoreEngage Driver and Navigator
Pair programming is really a very simple concept. It’s about writing code in groups of two or more people. The person currently at the keyboard is called the driver. The person or people who are not at the keyboard are called the navigator or navigators. The driver’s job is to deal with the minutia of …
Continue reading “Engage Driver and Navigator”
Read MoreTry It, You’ll Like It
When I was a kid growing up in the 1970s there was a television commercial for Alka-Seltzer where one guy is giving some other guy some scary-looking food and says, “Try it, you’ll like it.” That became the catchphrase for an entire generation and it meant not to pass judgment on something until you have …
Continue reading “Try It, You’ll Like It”
Read MoreWhy Practice Four: Collaborate
Practice four from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of your software, is Collaborate. You may wonder why a technical book on agile software development practices would include a practice called Collaborate but it turns out that even though we often don’t get formal training in school on …
Continue reading “Why Practice Four: Collaborate”
Read MoreFix Broken Builds Immediately
There are good crutches and bad crutches in life. Being addicted to using heroin is a bad crutch but being addicted to using a working build is a good, healthy crutch. This is the kind of crutch that I want to encourage. A healthy, well-maintained build is the heartbeat of a project. Removing friction from …
Continue reading “Fix Broken Builds Immediately”
Read MoreKeep Test Coverage Where it is Needed
I’m not a believer in having standards for test coverage. I know teams that require 60%, 70%, or 80% test coverage for their code. I don’t like having standards like this because different code has different requirements for testing. Straightforward code like getters and setters don’t really need to be tested. However, more complex code …
Continue reading “Keep Test Coverage Where it is Needed”
Read More