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
Pathologies of Tight Coupling
We continue our conversation on code qualities with a discussion of why tight coupling is undesirable. Again, I want to stress, as I did in the last post, that we’re not striving for no coupling in a system. A system with no coupling is a system that does nothing. We want the right kind of …
Continue reading “Pathologies of Tight Coupling”
Read MoreCohesion and Testability
I feel like I try to go around and get developers to do little things that will make a big difference in their work. For example, if you need to add some behavior to your system, rather than putting that behavior into some pre-existing entity, you should probably create a new class for that new …
Continue reading “Cohesion and Testability”
Read MorePathologies of Uncohesive Code
Uncohesive code is code that either has too many responsibilities or has poorly defined responsibilities. Typically, it’s code that tries to do too much. Poorly cohesive classes are difficult to understand and maintain. They’re harder to debug and more difficult to extend. The bottom line is the more issues a class has to deal with, …
Continue reading “Pathologies of Uncohesive Code”
Read MoreQuality Code is Cohesive
The first code quality we’ll discuss is my very favorite: cohesion. Cohesive code is highly focused code that’s straightforward and easy to read. I like cohesion because it’s the easiest one for me to spot, but I recognize that that’s not true for everyone. People have told me that cohesion is actually the hardest for …
Continue reading “Quality Code is Cohesive”
Read MoreKeep it CLEAN
I like dirty martinis and R-rated movies but my code is one place I always want to keep CLEAN. CLEAN is an acronym I use to remind myself of the five key code qualities that I’ve found to have the biggest impact for improving the maintainability and extendibility of code. Before I describe exactly what …
Continue reading “Keep it CLEAN”
Read MoreQuality in Software
Quality is a word we throw around a lot, but without much consensus on what it really means. And it can mean different things in different contexts. Quality in software is very different—the word has a fundamentally different meaning—from quality in goods or services. This is because software is fundamentally different than goods or services. …
Continue reading “Quality in Software”
Read MorePropagate Knowledge
There is a huge amount of professional wisdom in software development. These are things that we have never bothered to write down but are standards nonetheless. This general knowledge is communicated through individual interactions as well as the code we write, so it’s really important that we have high quality interactions within the team and …
Continue reading “Propagate Knowledge”
Read MoreSwarm on Showstoppers
Swarming is a practice where the entire team works together temporarily to solve a problem. Swarming is most useful for certain kinds of problems, problems that impact the entire team. If no one can do anything until the problem is resolved then it may make sense, and improve morale, if everyone on the team has …
Continue reading “Swarm on Showstoppers”
Read MoreSpike on Unknowns
As an Agile developer, I often start projects without a clear sense of exactly what I’m building. This used to be very difficult for me. I wanted to start with a complete specification for what I was to build, but today I know that it’s more efficient and effective to discover exactly what needs to …
Continue reading “Spike on Unknowns”
Read MoreBuddy Programming
Sometimes the practices of Extreme Programming can be a bit too extreme when first introducing them to a team. This is especially true with pair programming. Of all the practices that I teach software developers, I get the most resistance from pair programming, Both developers and their managers are skeptical about pair programming, although each …
Continue reading “Buddy Programming”
Read MoreStrong-Style Pairing
Pair programming is not about taking turns using the computer or being someone else’s typist. It’s about engaging two minds on the same problem so that a solution can be developed more quickly and with higher quality than if one person was working on it alone. The two roles in pair programming are referred to …
Continue reading “Strong-Style Pairing”
Read MorePing-Pong Pairing
Another pair programming configuration I like is called ping-pong pairing. In ping-pong pairing the driver writes a test for a behavior then asks the navigator to implement the behavior and make the test pass. Once completed, the keyboard is passed from driver to navigator and the new driver writes the next test for the new …
Continue reading “Ping-Pong Pairing”
Read MorePairing versus Mobbing
I was talking to some friends at Agile 2016 about which they thought was more effective, pair programming done well or mob programming done well, but we ended up deciding that the jury is still out on this question, at least for the time being. In terms of learning and spreading knowledge across a team …
Continue reading “Pairing versus Mobbing”
Read MoreTime Box to Scope Box
Both Extreme Programming (XP) and Scrum have the notion of time boxing. In XP, they call it iterations. In Scrum, they call it sprints. I am not a big fan of the term sprint because it connotes the idea of hurrying through. That’s not how I view iterative development. It is not a race but …
Continue reading “Time Box to Scope Box”
Read MoreTime Boxes
Time boxes help teams develop the discipline of building small pieces of valuable software. But time boxes are in some sense artificial. What if you finish early or late? Well, this is one of the uses for measuring velocity so we can schedule the right amount of work within an iteration. Iterations should be as …
Read MoreDuplication versus Redundancy
You may have noticed that I don’t use the XP term duplication when talking about code quality. I prefer to use the term redundancy instead. This is because duplication is the most obvious form of redundancy but redundancy can take many other forms that are far subtler and harder to detect. When I ask developers …
Continue reading “Duplication versus Redundancy”
Read MorePractices We Aren’t Taught
As a software developer I resonate with the technical practices of Extreme Programming. Software engineering, like other forms of engineering, should have common standards and practices, but we really don’t. Yes we all learn programming languages in school but we’re rarely taught how to apply them in ways needed to build enterprise systems. This is …
Continue reading “Practices We Aren’t Taught”
Read MoreCollaborate
Collaboration requires a set of skills that must be practiced and mastered. Most software development projects involve collaboration among many developers so being able to work as part of a team, and to communicate complex ideas effectively, are important skills to have. Pair programming is one approach to collaborative development. Pair programming is not about …
Continue reading “Collaborate”
Read MoreChange Your Mind
One characteristic I consistently see among outstanding software developers is that they’re not afraid to change their minds, to change their approach, or to change their designs. In Agile we start building right away before we have all the requirements nailed down and we let new requirements emerge as we’re building. To those unfamiliar with …
Continue reading “Change Your Mind”
Read MoreIntegrate Frequently
You want to create a build system that’s so easy to use that it’s invisible to the developers on the team. It should be able to be invoked with a single click and should automatically build, test, and validate new code that’s added to the system. Teams that are first adopting continuous integration sometimes ask …
Continue reading “Integrate Frequently”
Read MoreVersion Everything!
I’ve come across a few teams in my career who have unstable build and test environments. When they develop a feature and test it on their test servers everything’s fine, but as soon as they move the code into production bugs that didn’t show up before begin to manifest. I had one client whose system …
Continue reading “Version Everything!”
Read MoreOne-Click Builds
We want to make invoking the build as simple as possible. So simple in fact, that it becomes a non-event that’s nearly invisible to us. The build should be accessible from the desktop or in the IDE. It should require only a single click to invoke. A local build should be invoked first, compiling only those …
Continue reading “One-Click Builds”
Read More