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
Think About Edge Cases
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy. Although stories are composed of three elements that include WHAT the feature is, WHO the feature is for, and WHY the …
Continue reading “Think About Edge Cases”
Read MoreStart Simple then Enhance
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy. Another great aspect of using stories to drive Agile software development is that we can start with simple stories that create …
Continue reading “Start Simple then Enhance”
Read MoreKnow Why a Feature is Wanted
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy. One of the most powerful and important aspects of user stories is the WHY clause. WHY a feature is wanted is …
Continue reading “Know Why a Feature is Wanted”
Read MorePersonify the Who of Stories
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy. When developers know WHO a feature is for and can identify with that user then they can often build a better …
Continue reading “Personify the Who of Stories”
Read MoreFocus Stories on the What
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy. Focus Stories on the What The most important aspect of a user story is contained in the WHAT clause because …
Continue reading “Focus Stories on the What”
Read MoreSee Stories as Placeholders
Last year, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and I think it’s time to …
Continue reading “See Stories as Placeholders”
Read MoreGreen Tests and Red Tests
In practice I found that there are times that I want a bit more test coverage than I get from just doing test-first development. When I do test-first development, I always write a failing test first and then I create the implementation to make that failing test pass. As a result, I get by default …
Continue reading “Green Tests and Red Tests”
Read MoreRadiators and Silos
In the old days of corporate America, the way you got ahead was through hard work and perseverance. You strove to become an expert in some area that was valuable so the people would come to you for your expertise. This is how you got ahead. This is how you got into management. You got …
Continue reading “Radiators and Silos”
Read MoreMakers and Menders
I’ve been getting back into some research interests of mine that require data acquisition from a variety of sensors so naturally, I’ve gravitated towards using the Raspberry Pi. If you’re unfamiliar with the Raspberry Pi, is a full-blown computer on a card about the size of a cigarette pack and offers a graphical user interface, …
Continue reading “Makers and Menders”
Read MoreHow I Use User Stories
When I write user stories, in addition to the story itself, I like to help define edge cases in my stories and I typically do this as acceptance tests. There are automated acceptance test tools such as FIT and Cucumber that not only allow me to define acceptance tests but also help me run them …
Continue reading “How I Use User Stories”
Read MoreUser Stories Support Object-Oriented Development
The number one worst practice I see consistently in object-oriented software development is writing procedural code. Even object-oriented programming projects contain code that is highly procedural. You’ve probably seen code like this yourself where it’s basically a series of steps that prescriptively describe a process that is then wrapped within a class. This is really …
Continue reading “User Stories Support Object-Oriented Development”
Read MoreHow Small should a Story Be?
Stories should be as small as possible while still providing some value to the user. Usually, we strive to create the smallest increment of value possible but this is sometimes not as straightforward as it may seem. Sometimes we write stories with the intention to build upon them later or combine pieces of common stories …
Continue reading “How Small should a Story Be?”
Read MorePair Programing Paradoxes
Of all the software developer practices I teach, the one I get the most resistance from managers is pair programming. They tell me they have too much work for their team to do and if they paired then their developers’ throughput would be cut in half. There is a naïve assumption in that statement. The …
Continue reading “Pair Programing Paradoxes”
Read MoreDrive to Testability
There are patterns, things that developers do when writing code that support testability of code and there are anti-patterns, which are things that developers do that lead to writing code that is difficult to test. As a developer, I’ve found it helpful to become aware of some of these testability patterns and anti-patterns that I …
Continue reading “Drive to Testability”
Read MoreThe Importance of Continuous Integration
Perhaps the most important yet easiest to implement of all the software development practices in Agile is continuous integration. Continuous integration is simply creating an infrastructure where the code that is being built can immediately be integrated into a project. One of the biggest challenges when writing software is the dependency relationship between the code …
Continue reading “The Importance of Continuous Integration”
Read MoreSummary of Seven Strategies Series
I finished my “Seven Strategies” series of 72 blog posts with seven strategies for implementing each of the nine practices from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. These posts are filled with practical advice for implementing the nine core practices from Scrum, Extreme Programming, and …
Continue reading “Summary of Seven Strategies Series”
Read MoreRefactor to Learn What Not to Do
One of the things that I was not expecting when I started refactoring other people’s code was that I started to see improvements in the way I wrote my own code. I didn’t make those same mistakes. Refactoring other people’s code has taught me a great deal about things to do and things not to …
Continue reading “Refactor to Learn What Not to Do”
Read MoreRefactor to Clean Up Before Moving On
Of course, the best time to refactor code is while it’s fresh in your mind, right after having worked with it. Once I get a feature to work, I go back and think about how I can make the code easier to understand. I’ve done this so often that it’s natural for me, almost of …
Continue reading “Refactor to Clean Up Before Moving On”
Read MoreRefactor to Redesign When You Know More
One of the reasons that I’m such a proponent of doing emergent design or just-in-time design, is that this is how we learn a system and this is typically how a system needs to be built. It’s fallacious to believe that you can easily envision every aspect of a complex system and come up with …
Continue reading “Refactor to Redesign When You Know More”
Read MoreRefactor to Clean Up as You Go
We should be refactoring the code we write and all the code that we encounter all the time. Making little improvements to code should be just something that developers do without even thinking about it. I find that many of the anti-patterns the developers engage in when writing code are easy to spot and after …
Continue reading “Refactor to Clean Up as You Go”
Read MoreRefactor to Retrofit Tests in Legacy Code
The so-called safe refactorings are a subset of the refactorings from Martin Fowler’s book, Refactoring: Changing the Design of Existing Code. We call them safe because they require only straightforward changes to code that can be automated and proven to be correct with no unintentional side-effects. Safe refactorings are refactorings like Rename Method that lets …
Continue reading “Refactor to Retrofit Tests in Legacy Code”
Read MoreRefactor to Make Small Improvements
Another strategy to help you justify refactoring is to do it in order to make small improvements in an existing system. Don’t try to bite off the whole Apple at one time. Really bad legacy code got that way over long periods of time and in my experience, a similar, gradual approach can be good …
Continue reading “Refactor to Make Small Improvements”
Read More