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 MoreQuality Code is Loosely Coupled
While cohesion, which was the subject of the last three posts, is about the internal consistency of a class or method, coupling is a code quality that looks at the relationship between entities. There are two distinct forms of coupling: loose coupling and tight coupling. One is good, the other isn’t—and I always forget which …
Continue reading “Quality Code is Loosely Coupled”
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 MoreBeyond Waterfall Software Development
Developing software in short sprints requires a different approach than traditional software development, though it seems strange to call something only a few decades old “traditional.” Winston Royce coined the term “waterfall software development” in 1970 and he said in that very same article that we shouldn’t use it because it doesn’t really work. Many …
Continue reading “Beyond Waterfall Software Development”
Read MoreFinding the Right Metaphors
In his book, Domain Driven Design, Eric Evans said that there really is no such thing as complexity, complexity happens when we diverge from our models, when we use metaphors inconsistently, and I tend to agree. Very involved systems can be easy to understand as long as they adhere to an appropriate set of metaphors. …
Continue reading “Finding the Right Metaphors”
Read MorePerspectives
Our job as developers is less about being clever or finding efficient algorithms and more about simply perceiving the problem and representing it as accurately as possible. This is an exciting shift in software development because it means our goal is really about understanding. Once we understand a problem everything else can fall into place …
Continue reading “Perspectives”
Read MoreAvoiding Integration Hell
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 be integrated into the project immediately. One of the biggest challenges when writing software is the dependency relationship between the code …
Continue reading “Avoiding Integration Hell”
Read MoreThe Importance of Technical Practices
Software development has undergone many revolutions over the last few decades and the way we build software today is fundamentally different than the way we did just a few years ago. Our industry is maturing and we are beginning to pay attention to the quality of our work. No longer is just fulfilling the specification …
Continue reading “The Importance of Technical Practices”
Read MoreTwo Big Things
I’d like to say that there are two big things we must achieve in software development. We must build the right thing and we must build the thing right. Building the right thing starts with what the customer wants so they can gain value from our work. The way we build the right thing for …
Continue reading “Two Big Things”
Read MoreSuccess to Standish is Failure in Agile
The Standish Group’s CHAOS Report is the largest and longest running research study in the software industry. Standish looks at approximately 34,000 software projects in a range of areas. It includes shrink-wrap applications, operating systems, custom apps, etc. They picked a range of diverse projects to look at. Every ten years the study drops about …
Continue reading “Success to Standish is Failure in Agile”
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 MoreDeveloper on Fire Podcast
I had a very interesting conversation with Dave Rael (@raelyard) on the #DeveloperOnFire #Podcast about what excites me as a developer. Listen to it here: http://developeronfire.com/podcast/episode-206-david-bernstein-beyond-legacy-code
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 MorePodcast on The Agile Uprising
I had a great conversation with Ryan Lockard (@AgilePHL) and James Gifford (@scrummando) on the @AgileUprising podcast. Listen here: https://coalition.agileuprising.com/t/podcast-released-beyond-legacy-code-with-david-bernstein/627
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 More