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 MoreBoth 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 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 MoreCheck out my podcast with Amos King on This Agile Life, where we talk about Agile adoption issues and why technical practices are essential: http://www.thisagilelife.com/123 Oops, it looks like their website is no longer active. Sorry.
Read MoreYou 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 MoreI 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 MoreAs 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 MoreCollaboration 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 MoreOne 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 MoreYou 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 MoreThe 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 MoreOne 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 MoreI’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 MoreWe 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 MoreIn 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 MoreI 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 MoreFor me, software agility is best summed up in the first principle from the Agile Manifesto, which talks about continuous delivery of valuable software. Agile software development is supposed to be a flow that doesn’t conform to prescribed phases. Instead, it breaks projects down into features and tasks. We build the features that are most …
Continue reading “The Heartbeat of a Project”
Read More“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 MoreIn my blog post The Single Level of Responsibility Principle, I talked about the virtues of separating out perspectives in code so that any entity is only dealing with a single perspective. In this post, I’d like to tell you about the practice I use that helps me separate out perspectives in code without even …
Continue reading “Programming by Intention”
Read MoreThere are many techniques for splitting stories depending upon the situation you’re in. The goal is to break down work into the smallest increments that still provides some value, but the value can simply be a step in the right direction—as long as it produces visible results. Most big stories are compound stories, meaning they’re …
Continue reading “Story Splitting Techniques in a Nutshell”
Read MoreA number of Agile methodologies rely on artificial time boxes such as sprints or iterations. The purpose of these time boxes is to get you good at breaking down work so you’re only building a small piece of functionality at a time. One of the critical skills in Agile development is being able to split …
Continue reading “Splitting Stories”
Read MoreHere’s a link to the Technically Speaking Podcast I did at Agile 2016: https://soundcloud.com/teamdaugherty/david-bernstein. In addition to talking about my conference session, my book, and the state of Agile, we also discussed my previous career as a filmmaker and the youth environmental video I made in the 1990s called Connect: A New Ecological Paradigm. This …
Continue reading “Technically Speaking Podcast”
Read More