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
Seven Strategies for Remote Teams
It used to be thought that if only we could write a good specification that accurately described what was to be built, we could take advantage of the cheap labor overseas to cut costs and get software built faster. Unfortunately, reality often shatters such naive hopes. However, outsourcing overseas can help for many tasks and …
Continue reading “Seven Strategies for Remote Teams”
Read MoreSeven Strategies for Working with an Onsite Customer
One important characteristic of agile development over non-agile processes, such as waterfall, is the presence of an onsite customer. Unlike the Project Manager or ScrumMaster, whose job it is to keep the team healthy, the Product Owner or onsite customer representative’s job is to be a proxy for the real customer and ensure development is …
Continue reading “Seven Strategies for Working with an Onsite Customer”
Read MoreSeven Strategies for Customer Collaboration
My wife is a video producer. Her job is not very different from our jobs as software developers. Both jobs demand lots of creative problem-solving where we face different challenges every day, and both jobs often involve close collaboration with our customer or a subject matter expert. My wife, Staci, is great at creating videos …
Continue reading “Seven Strategies for Customer Collaboration”
Read MoreSeven Strategies for Team Swarming
I don’t see a lot of talk about team swarming (sometimes referred to as mobbing) yet it can be one of the most powerful problem-solving techniques for breaking through really difficult challenges. A swarm is where you get the whole team together to focus on solving a single problem. You can also focus on multiple …
Continue reading “Seven Strategies for Team Swarming”
Read MoreSeven Strategies for Pair Programming
Of all the agile developer practices I teach, pair programming gets the most resistance from management. Managers often ask me how putting two developers on the same task can possible be more efficient than having them work independently on different tasks…but it most definitely is. Well, you may not find a huge increase in the …
Continue reading “Seven Strategies for Pair Programming”
Read MoreSeven Strategies for Agile Infrastructure
The first step in achieving agility and technical excellence is to set up an infrastructure to support it. The infrastructure we will discuss here, an automated build server, is one of the most important aspects of agility because we can only consider a story as “done” when it is fully integrated into the build. Here …
Continue reading “Seven Strategies for Agile Infrastructure”
Read MoreSeven Strategies to Foster Hyper-Performing Teams
Hyper-performing teams do exist. I know teams that are an order of magnitude more productive than average teams. Achieving hyper-performance is possible if everyone on the team has the skills and a burning passion to do their best. Here are seven tips that can help your team become high performing, if not hyper-performing: 1. Know …
Continue reading “Seven Strategies to Foster Hyper-Performing Teams”
Read MoreAvoid the Legacy Trap
Some of my clients put their best software developers on a project to build a system and then afterwards they put new hires on to maintain and extend it. Often the intention behind the original design is not clear to the people who have inherited the system and so they tend to make changes that …
Continue reading “Avoid the Legacy Trap”
Read MoreIntegrate Early and Often
A story, use case, or requirement is not done until it is integrated into the rest of the build system. “Well, it works on my machine,” is not a statement we want to hear on an Agile project. A story that is not integrated into the build is not complete and worth zero story points …
Continue reading “Integrate Early and Often”
Read MoreThe TDD Zealot
On December 22, 2010 Mark Seemann published a blog post The TDD Apostate. Since then several friends and associates have sent me links to his post as if to say, “See, TDD is not all it is cracked up to be.” It is an excellent post and I agree with much of what the author …
Continue reading “The TDD Zealot”
Read MoreWhy Short Iterations Work
Software developers are infamous for not being good estimators. They say programmers have three timelines they work with: “done”, “not started” and “nearly finished”. It is easy to get caught up in the implementation details and not know exactly how long it will take to wrap up the task. Time boxing can be very helpful …
Continue reading “Why Short Iterations Work”
Read MoreWhat is Quality?
How do you define quality? Ford says that quality is job one but what is it and how do we create quality? We all recognize quality service at a fine restaurant and a quality product like a fine piece of furniture but what is quality in software? I ask this question a lot to developers …
Continue reading “What is Quality?”
Read MoreRetrofitting Tests
Retrofitting tests into legacy code is difficult process but can give us the ability to redesign and improve the quality of that software as we go. It is generally a good idea to add tests before refactoring code. Tests serve as a safety net so if I make a mistake in refactoring the test will …
Continue reading “Retrofitting Tests”
Read MoreTest Driven Documentation
Part of allowing change to happen during development is by building software with engineering practices that support change. The most important of these practices is correctly using unit tests. Tests represent a way to both embody understanding of the system and prove that the system works. Unit tests are really a form of specifications because …
Continue reading “Test Driven Documentation”
Read MoreReflections on the Three Steps of Test First Development
Decide what to do, figure out how to do it and then do it well. These are the three essential steps we perform over and over again in TDD. Each step is different and requires us to focus on different things. Separating out these steps helps us focus on each one at the right time, …
Continue reading “Reflections on the Three Steps of Test First Development”
Read MoreHow Many Tests Are Enough?
How much code coverage should we have? I say 100%. Do we really need to test getter and setter methods? No and yes. We don’t need to verify the trivial behavior of getters and setters but it can be valuable to have a test for them so that their existence is specified. Likewise, I have …
Continue reading “How Many Tests Are Enough?”
Read MoreTriangulation
If I get stuck and I don’t know how a complex algorithm should work I’ll write a test for an error case. Then I’ll write a test for the simplest non-error case I can think of and return a hard coded value. Then I’ll write another test case and see if I can figure out …
Continue reading “Triangulation”
Read MoreIt’s Not Easy Being Green
Kermit the Frog used to say that it’s not easy being green and he was right. In TDD we want to stay in the green as much as we can. When our tests are green life is good. Turning the red bar green can be easy at first but keeping it green can be very …
Continue reading “It’s Not Easy Being Green”
Read MoreGreen Bar Guilty Pleasures
I’ve already written about the importance of getting to the red bar and the value of a failing test but once we get the red bar we want to move on and get to the green bar as soon as possible. In fact, turning the red bar green, which is really what TDD is all …
Continue reading “Green Bar Guilty Pleasures”
Read MoreCelebrate the Red Bar
Many important things happen getting to the red bar. In a test first approach where we write our test before we write our production code, we define the method signature before we build its implementation. That means we are thinking about how to call a method before it is written. This reinforces designing to interfaces …
Continue reading “Celebrate the Red Bar”
Read MoreWhen Are Tests Most Valuable?
Don’t we get the most value from our tests when they fail? We may wear our seatbelt every time we get in the car but when we get into an accident and use our seatbelt is when we are most grateful for having it. This is also true with tests. It is not until a test breaks …
Continue reading “When Are Tests Most Valuable?”
Read MoreIn TDD Failures Can Be Good
Rarely is failure a good thing in life but in test driven development a failing test can be a very good thing. Many TDD developers dread the “red bar” but it is really worth celebrating and here’s why. Developers are often under the mistaken impression that TDD is about getting to the “green bar”. This …
Continue reading “In TDD Failures Can Be Good”
Read More