Pathologies of Redundant Code
Remember Y2K? Before the turn of the millennium, computer storage was at such a premium that years were stored with only the last two digits so the year 1989 was stored as 89. This worked fine—up until the end of 1999, at which point the year returns to 00 which many programs would interpret as …
Continue reading “Pathologies of Redundant Code”
Read MoreQuality Code is Nonredundant
The last code quality that we’ll discuss in this series, the “N” in CLEAN, calls for code to be nonredundant. On its surface it seems pretty straightforward but there is some subtlety to redundancy as well. It’s easy to see why redundancy in code is a bad thing. It’s a duplicated effort. It means that …
Continue reading “Quality Code is Nonredundant”
Read MoreAssertiveness and Testability
It’s quite difficult to test inquisitive code. Very often the results of running a piece of code can only be found in another object. Therefore a test must use a separate entity, which we typically call a “spy,” to monitor the external object and validate that it was called correctly. This adds unnecessary complexity to …
Continue reading “Assertiveness and Testability”
Read MorePathologies of Inquisitive Code
Objects that are not assertive are by default inquisitive. They are either inquisitive or they are mute. They don’t interact with the outside word at all. If an object interacts with other objects, the real question with regard to assertiveness is, “Who’s in charge?” One object can delegate a task to another object but still …
Continue reading “Pathologies of Inquisitive Code”
Read MoreQuality Code is Assertive
The next code quality in this series of posts, the “A” in CLEAN, stands for assertive. I don’t hear a lot of people talking about it but I think it’s an important code quality. We want the software we write to be assertive, to be in charge of its own state. We want objects to …
Continue reading “Quality Code is Assertive”
Read MoreEncapsulation and Testability
Poorly encapsulated software is hard to test because without clear boundaries, what we actually test becomes significantly larger than what we need to test. This makes our tests run slower and it also makes them brittle so our tests are harder to maintain. When code is unencapsulated, it can be hard to lock down behaviors …
Continue reading “Encapsulation and Testability”
Read MorePathologies of Unencapsulated Code
Unencapsulated code is code that exposes its implementation or references how it does something. This can happen in subtle ways, so we have to be careful to create strong contracts through our method signatures. Poorly encapsulated code is very difficult to work with. It can quickly sprout new bugs at the slightest change. Lack of …
Continue reading “Pathologies of Unencapsulated Code”
Read MoreQuality Code is Encapsulated
To encapsulate something is to envelope and protect it. Encapsulation is a fundamental facility that every programming language supports at some level. Encapsulation is about hiding implementation details so ideas can be expressed at higher levels and to protect those details from other parts of the system. To me, most fundamentally, encapsulation means hiding implementation …
Continue reading “Quality Code is Encapsulated”
Read MoreCoupling and Testability
I can learn a lot about the kind of coupling in a system by listening to how people talk about testing it. If someone says, “I couldn’t test that without instantiating half the system,” then I know they have some coupling issues. Unfortunately, most systems I have seen—and most systems I know other people have …
Continue reading “Coupling and Testability”
Read MorePathologies 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 More