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
Write Testable Code
This has become my favorite subject because it turns out that testability, above nearly every other metrics, is important to strive for in developing software. All other code qualities seem to be a reflection of testability. When I say testable code what I mean is code that can be verified programmatically and in a very …
Continue reading “Write Testable Code”
Read MoreDefine Acceptance Criteria
“You are done, finished. Time to move on.” How I long to hear those words when I’m working on a task. Specifications can be squishy and it can be difficult sometimes to determine if the task is complete or not. Software developers don’t want to gold plate. The problem is that we often don’t know …
Continue reading “Define Acceptance Criteria”
Read MoreIntegrate Continuously
I believe that continuous integration is at the very heart of Agile software development. It allows us to go fast by going small. What I mean by this is that we learn by building in small increments that it’s more straightforward to create modular software that’s independently verifiable and by building smaller it gives us …
Continue reading “Integrate Continuously”
Read MoreOne-Click Builds End-to-End
We want to automate the build so that it is easy to use. We wanted to be so brain-dead simple to use that we use it all the time and we invoke the build whenever we make even a minor change to the system. This is how we get the most value from our build–when …
Continue reading “One-Click Builds End-to-End”
Read MoreUse Version Control for Everything
Version control is an important part of file management on every software development project I’ve ever worked on in the last two decades, regardless of the methodology. I’ve used Subversion and Git and several others in the process of building software. I always find it a bit surprising that other industries don’t use version control …
Continue reading “Use Version Control for Everything”
Read MoreWhy Practice 3: Integrate Continuously
Once we define what we want and build the smallest increment, we want to integrate it into our system as soon as possible so that we can see it working and get a true measure of our progress. Continuous integration is at the very heart of every Agile project and so I wanted to introduce …
Continue reading “Why Practice 3: Integrate Continuously”
Read MoreMeasure Efficiency of Feedback Loops
All of the things that I suggest that we measure on software development teams, from these current seven blog posts as well as other things that I’ve written, are all about ways of improving the efficiency of our software development process. We measure to understand and improve. Agile is all about getting and learning from …
Continue reading “Measure Efficiency of Feedback Loops”
Read MoreMeasure Costs of Not Delivering Features
In my last blog post, called Measure Customer Value of Features, I discuss the importance of seeing the value of features from the customer’s perspective. But there is another perspective that the customer can sometimes have that is also important for us to see–the cost of not delivering a feature. Sometimes we’re in time-critical situations …
Continue reading “Measure Costs of Not Delivering Features”
Read MoreMeasure Customer Value of Features
I always say that doing the right thing is far more important than doing the thing right, if we only have to choose one of them. Of course, we don’t we can choose to do both and that’s when software development is at its best. It doesn’t matter how elegant our code is or how …
Continue reading “Measure Customer Value of Features”
Read MoreMeasure Time to Detect Defects
When I was young I read a study by TRW done in the ‘60s that measured the cost of fixing a defect that was detected at different points in the development cycle. If the developer who wrote the defect found it immediately after writing it then we can assign one unit of effort for resolving …
Continue reading “Measure Time to Detect Defects”
Read MoreMeasure Defect Density
One of the things that you’re not going to find in this seven blog posts series on measuring the software development process is measuring velocity. I hate velocity because I’ve seen it misdirect managers and team members far more often than I’ve seen it provide valuable information. Rather than spend time teaching teams about story …
Continue reading “Measure Defect Density”
Read MoreMeasure Time Spent Coding
One of the most important metrics for the effectiveness of a software development team is one that I often find managers pay little attention to. The metric is how much time developers actually spend coding. If our goal as software developers is to produce features in software then our process has to support us by …
Continue reading “Measure Time Spent Coding”
Read MoreMeasure Time-to-Value
I am especially excited to share with you the next seven blog posts, which are based on seven strategies to measure value and software from my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) Of Your Software. You can find the original post that summarizes the seven strategies here https://tobeagile.com/seven-strategies-for-measuring-value-in-software/. I’m …
Continue reading “Measure Time-to-Value”
Read MoreWhy Practice 2: Build in Small Batches
In a lot of ways, I think that Practice 2–Build in Small Batches, from Beyond Legacy Code, is the core practice that made agile and Scrum great. I was breaking down my software projects into smaller pieces as early as the 1980s. I didn’t call it agile back then. In fact, I was a bit …
Continue reading “Why Practice 2: Build in Small Batches”
Read MoreSupport Refactoring
I’d like to conclude this series of blog posts on Seven Strategies for Product Owners with a final strategy that often gets overlooked on development teams but is vitally important: support refactoring. Sometimes Product Owners resist the team’s desire to refactor because they don’t get any new features after refactoring but often times refactoring is …
Continue reading “Support Refactoring”
Read MoreRemove Dependencies
One key characteristic of great Product Owners is that they help remove dependencies whenever the team encounters them. Dependencies can show up in many different forms. Our team may need some code from another team in our company, but the other team hasn’t yet built it for us. Or one feature that we may have …
Continue reading “Remove Dependencies”
Read MoreAnswer Questions Quickly
One of the most important skills for a Product Owner is to answer questions quickly, which means that they have to really know their product and understand WHY it’s needed, WHAT’s needed, and WHO it’s for. Developers have to dive deep when they’re writing software and they come up with questions that non-developers may never …
Continue reading “Answer Questions Quickly”
Read MoreDescribe What You Want Not How to Get It
So much of good software design comes down to separating the WHAT from the HOW. WHAT we want should be expressed in the interfaces of the services that we create. It should clearly state WHAT the service provides, the parameters that it needs to take in, and the value that it returns. Our services should …
Continue reading “Describe What You Want Not How to Get It”
Read MoreHelp Developers Understand Why and for Whom
The traditional ways that we describe how to build something, whether it’s a blueprint for an office building or the specification for a computer program, it always involves a document that describes WHAT to build and often includes information on HOW to build it. However, these documents are often missing critical information on WHY these …
Continue reading “Help Developers Understand Why and for Whom”
Read MoreUse Development for Discovery
Before you begin to build a house and break ground on the foundation you better have a blueprint and know exactly what you’re going to build. In physical construction, we really need to plan things out ahead of time to ensure that we have the right materials at hand and that things come together as …
Continue reading “Use Development for Discovery”
Read MoreBe the SME
I’m kicking off a new series of blog posts based on the Seven Strategies sections in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. The next seven blog posts will each be based on a different strategy from the section in my book called on Seven Strategies for …
Read MoreWhy Practice 1: Say What, Why, and for Whom Before How
In honor of the 10th anniversary of this blog, which I first started under the name Techniques of Design and then became To Be Agile, I’m starting a new blog series. Actually, I’m starting nine new blog series, a series on each of the nine practices from my book, Beyond Legacy Code: Nine Practices to …
Continue reading “Why Practice 1: Say What, Why, and for Whom Before How”
Read More