What I Mean by CLEAN
If you’re reading my blog posts as they come out then you already know about CLEAN, which is my acronym for five code qualities that improve the testability and maintainability of software. If you’re reading these posts as archives in reverse chronological order, then the acronym is: NAELC. It’s unpronounceable, but it still contains goodness. …
Continue reading “What I Mean by CLEAN”
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 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 MoreWorld-Class Communicators
I think we software developers get a bad rap. We are portrayed in the media as being antisocial and introverted, unable to carry on a conversation at a party. In my experience, these stereotypes do not hold true. Okay, maybe it holds true for some of us (like me) but most developers I meet don’t …
Continue reading “World-Class Communicators”
Read MoreRearrange the Furniture
The best development teams that I know not only sit together but face each other so they can see each other and hear each other throughout the day. This is in direct contrast to most office spaces where individual team members have their own offices so they can work in quiet without being distracted. This …
Continue reading “Rearrange the Furniture”
Read MoreLifecycle Artifacts
One difference I see between the Waterfall projects I used to work on and the Agile projects I work on now is that my desk is much less cluttered now. A lot of traditional software development methodologies require additional artifacts: UML diagrams, flowcharts, design specifications, UI layouts, the list goes on and on. The Agile …
Continue reading “Lifecycle Artifacts”
Read MoreMore Comments on Code Comments
In my last blog post, Comments on Comments, I was perhaps a bit harsh on the practice of comments in code. What I meant was that excessive what comments, which are comments that explain what the code is doing, are a possible indicator that the developer who wrote them was uncertain that the code could …
Continue reading “More Comments on Code Comments”
Read MoreComments on Comments
I have been accused in the past of encouraging developers to write uncommented code and this is true, but not because I don’t care about maintainability. On the contrary, I care about maintainability a great deal and that’s exactly why I encourage developers to think twice before they write a comment in their code. Commenting …
Continue reading “Comments on Comments”
Read MoreImplementation Independence
“Design to interfaces, not implementations.” This is the advice that the Gang of Four gave us in their book Design Patterns: Elements of Reusable Object Oriented Software. This means to hide implementation details and only present what is to be accomplished by crafting method signatures around testable behaviors. It means using APIs to create clear …
Continue reading “Implementation Independence”
Read MoreLinear versus Exponential
If I offered you a thousand dollars a day for thirty days, or a penny for the first day but I’ll double it every day for thirty days, which would you take? The former is a linear progression: 1000+1000+1000+1000… and the latter is an exponential progression: .01x2x2x2 . . . At the end of the …
Continue reading “Linear versus Exponential”
Read MoreTurn Pain into Gain
Integration is one of the most painful parts of a traditional software development process. After the system is designed and coded it gets integrated together in a Waterfall process, and this is when the nastiest bugs show their faces. It’s also when we really can’t afford to address fundamental issues. When I was doing Waterfall …
Continue reading “Turn Pain into Gain”
Read MoreTime Box to Scope Box
One key characteristic to Agile software development is time boxing. We build software in fixed intervals called time boxes. Time boxes for iterations are usually one to four weeks, with most teams opting for a two-week iteration length. Any fixed time iteration is going to be somewhat artificial. Software development tasks don’t all lend themselves …
Continue reading “Time Box to Scope Box”
Read MoreTest Driven Damage?
Understanding the technical practices of software development is not easy for everyone and a lot of otherwise smart people are failing when they try to apply them. Some people even claim that the practices I cover in my book, Beyond Legacy Code: Nine Practices to Extend the Life and Value of Your Software, don’t work. For …
Continue reading “Test Driven Damage?”
Read MoreAssert Behaviors Through Acceptance Tests
Acceptance Test Driven Development (ATDD) is a relatively new but essential practice in software development. This practice goes by many names, including Behavior Driven Development (BDD) and Specification by Example. This practice is not to be confused with Test Driven Development (TDD) or other forms of testing. ATDD or BDD is something unique. And as …
Continue reading “Assert Behaviors Through Acceptance Tests”
Read MoreSmaller Tasks Have Big Benefits
A central benefit to Agile software development is breaking down tasks into the smallest component that can provide measurable feedback. When we do this we take complex tasks and simplify them by breaking them down into smaller, easier-to-handle tasks. Smaller tasks have four essential benefits: First, they’re easier to understand, which means they cost less …
Continue reading “Smaller Tasks Have Big Benefits”
Read MoreTell Stories
A story is a single sentence description of a feature. Stories tell three things about a feature: • What it is • Why it’s there • Who it’s for. Stories do not tell how to implement a feature or even what it looks like. Stories are very high level. Stories are placeholders meant to remind …
Continue reading “Tell Stories”
Read MoreTechnical Excellence
Ten years after the Agile Manifesto was signed into being, the original authors got back together to review the progress made in the last decade. It was Jeff Sutherland who said, “Demanding technical excellence is a top priority for the next ten years.” But what is technical excellence? Given the state of the software industry …
Continue reading “Technical Excellence”
Read MoreThe Iron Triangle
There are three main constraints in manufacturing that are sometimes referred to as the “iron triangle.” These are scope, time, and resources. In manufacturing they say, “Pick two of these three things to flex, but one must remain fixed.” But this model does not apply to software development. Scope refers to the size of the …
Continue reading “The Iron Triangle”
Read MoreThink Like an Expert
Experts in any field organize their knowledge in specific ways. They have their own unique vocabulary and draw on specific analogies and metaphors. They have established key beliefs and distinctions around their expertise, and though they understand their subject their understanding maybe different and deeper than the rest of us. All experts draw on skills …
Continue reading “Think Like an Expert”
Read More