All articles are written by Jeff Langr unless otherwise noted. All of the articles on this page were either published in print magazines, at other sites, or submitted to conferences.
The agile manifesto tells us we must regularly reflect and adapt, and they mean it---we really are supposed to moving on to better ways of doing things. That means discarding bad practice, such as the often-frustrating daily standup meeting. This blog post for Industrial Logic, written by Nick Goede and me, uses shu ha ri as a metaphor to discuss your team's need to advance beyond rote practice.
Plenty of articles exist that describe the similarities between expository writing and code writing. Most miss the key point that writing—both code and not code—needs to be a process of continual editing in order to create quality product. This article touches just a bit more on that point.
In the prior article PRs: Shift Left, Please (Part 1), I made the claim that the pull request (PR) process itself is inherently ineffective and inefficient. Its emphasis on minimizing human interaction puts the PR process rightmost on a scale from favoring individuals and interactions to favoring tools and processes. By definition, then, the PR process is not agile. (“So what?,” you respond.) This article explores the “what” regarding the realities of the PR process, which can erode your culture, is inherently ineffective, and is inherently inefficient.
The pull request (PR) process seems an ideal way to ensure that our systems retain high quality. Using pull requests can "promote cooperation, participation, and collaboration" within teams using it. Yet the PR process is the least colalborative out of all the review options available to you, and probably the poorest choice as a result. This Medium article is Part 1 of a two-parter. Part one overviews the PR process, then makes the claim that PRs are poorly done and flat-out not agile. This sets the stage for part 2, in which I discuss the problems that not being agile creates.
No one sets out to write bad code, so how does it get there? This post, written for the Industrial Logic blog by Tim Ottinger and me, explores a half-dozen legitimate reasons why we end up with code that is going to be more difficult to understand and maintain.
In this post, I provide two key rules for making mob programming a successful and enjoyable way to work. You’ll figure out most of the rest of the guidelines for mobbing yourself: Things like respect for your teammates, guidelines about people coming and going, and so on. But these two rules–while simple to employ–aren’t necessarily obvious, and they’ll make all the difference in the world between a tedious, protracted mobbing session and something you’ll actually enjoy quite a bit.
In this post, I present OTAAT: One Thing At A Time, one of the most effective habits you can adopt as a software developer. From tackling stories to designing tests to refactoring, doing more than OTAAT is a guaranteed way to waste time. I’ll talk about how OTAAT instead helps makes life easier in general.
I keep hearing from teams who are mobbing, where everyone is in the same room with a WIP limit of one, that “we go faster.” Really! How is that possible? In this post, I talk about my use of mobbing and pairing in training environments, then segue into a discussion of the value of minimizing WIP. Finally, I present a long list of reasons why mobbing might actually allow teams to go faster.
“A test that passes with no change to your classes is always cause for humility and pause.” We learn red-green-refactor for a reason–it’s not just “green-refactor.” In this post, I talk about the various reasons why you might see tests pass (green) when expecting them to fail. You’ll learn why it’s important to stick to that TDD rhythm.
Yes, coding standards are often a source of discontent within a team… but if you can’t get past agreeing on a few simple things, I suspect that portends something. In this post, I talk about the value, or lack, of having coding standards. I present a set of recommendations for deriving “agile standards,” but ultimately distill all standards down to a singular concept.
There’s no such thing as a free lunch, or free-expensive-steak dinner. You might have to listen to someone ramble about DevOps for hours while not being able to tell you what it is. In this post, I get to vent a little with a story about a steak dinner dominated by blather. I present a few thoughts about what DevOps is, since I can’t seem to find a concise definition anywhere (or get one at a steak dinner).
XP presented four values as the basis for its approach to software development. Humility is perhaps the 5th, missing value. In this post, I offer some thoughts on what it means to be humble. I relate humility to the unease that many seasoned developers feel about TDD–its insistence of building only the software needed to that point in time.
Check out We Do TDD for numerous great stories about test-driven development from people, teams, and companies that test-drive their software. In this post, I talk about Dave Schinkel’s site that features interview questions and answers from a good number of TDD practitioners. I highlight some answers to questions about interesting TDD topics.
No, there’s no one “right” way to practice TDD, though there are plenty of ways that technically are not TDD. In this post, I talk about some of the variant ways of approaching test-driven development (TDD). I first introduce two distinct ways of describing TDD. I then discuss “assert-first,” “one assert per test,” and how tests are best named (or not).
Don’t create a long laundry list of technical buzzwords for hiring. There’s a better, more agile approach. I present six major points to consider when hiring someone for your agile team: three job requirements essentials, and three important aspects to consider during the hiring process.
“The more you spread it, the thinner it gets,” said the late Gerald Weinberg. I talk about the massive growth in the number of software developers worldwide, and how as a result developers have on average less experience than ever before. I talk about some ways in which we might thicken up that jam.
Passive review after code (PRAC) is largely a waste of time. In this post, I provide some reasons why active review is better than PRAC. I discuss pairing and mobbings as two forms of active rule, and present a core rule for review that focuses on outcome instead of mechanism.
03 Jul 2018
With the July 2018 issue, the late PragPub magazine (edited by Michael Swaine) celebrated the beginning of its tenth year. That year also began the 20th anniversary of the publication of Andy Hunt’s and Dave Thomas’s classic book The Pragmatic Programmer. In this article, I talk a bit about what it means to be pragmatic and about how both the book and magazine have helped us be pragmatic over the years.
A tale about a day in a development team's life where we don’t talk about a process, we just live it, with the singular goal of delivering high-quality software frequently. I've lived that seeming fantasy; you can too.
I view modes of working as akin to tools–you want to use the right tool for the right job or situation. In this post, I talk about the distinctions around appropriateness for mob programming and pair programming. I also admit to enjoying the ability to work alone from time to time.
I present seven design principles for the tests you’ll craft as part of practicing behavior-driven development (BDD) or acceptance test-driven development (ATDD). Stick to these principles and you’ll create a body of tests that returns many benefits while allowing you to keep your sanity.
In this post, I wax rhapsodic about TDD… well, maybe not. I don’t love TDD itself; I love the things that TDD enables me to do. I talk about what those things are, along with a bit of my personal history about how I got here.
You’ll pick up a number of ideas about how to approach introducing TDD into your team. While TDD is a simple practice to learn (though a challenge to master), getting developers to think they might want to even consider it is not an easy task. I’ll also talk about why resistance is to be expected.
A number of good questions about BDD arose from the Gurock webinar “BDD Testing Skills.” I felt like answering them all, though I did so rather hastily (so don’t expect a lot of clean editing for this “article”).
Why do TDD at all? My primary reason is because it allows me to go faster, particularly as a system grows. In this post, I talk about some of the reasons why, and iterate some of the high cost of defects along the way.
Yes you can. In this post, I talk about a customer who didn’t realize the pickle they were brining themselves into when they slowly but surely found their way on a path to “too many” tests.
How behavior-driven development (BDD) can help us come to consensus. I share a story about a customer who found value in BDD, even though we were unable to automate their “specs by example.”
The values of negotiating around scenarios when doing behavior-driven development (BDD). Rather than delve deep into the narratives (given-when-thens), this focus will help when it comes to negotiating the scope of a given story.
My experiences doing test-driven development (TDD) at a small startup: Where did we succeed, where did we fail, and what would I change?
06 Jul 2016
A reflection on why I’ve found TDD to be an indispensable practice for the past sixth of a century.
Written with Tim Ottinger. Much like in pair programming, working with a partner through pair writing provides increased support and valuable immediate feedback. But there are additional obstacles when you and your partner are not collocated. Here are some tips on how you can still implement pair writing successfully when you can’t collaborate in person.
01 Apr 2015
Jeff revisits his outlook on distributed development and finds it necessary to update one of the Agile in a Flash lists originally written with Tim Ottinger. Along the way he shares some hard-won insights on how to make distributed development teams work.
01 Jan 2012
Updated reprint (Medium)
Tim Ottinger and I present a breakdown of the FIRST acronym, which presents five guidelines for good quality unit tests.
A laundry list of things you need to look for and monitor in a TDD shop. TDD is a significant investment and challenge; following these recommendations should help you more effectively sustain the practice over time.
02 Nov 2011
Want your manager to understand test-driven development (TDD)? This article overviews what TDD is and discusses its cost and benefits. Jeff also presents some thoughts on how non-programmers might understand whether or not their team is doing TDD well.
01 Oct 2011
Updated reprint (Medium)
Is “distributed agile” an oxymoron or reality? Tim Ottinger and I talk about distributed teams and agile values, covering a number of do’s and don’ts for agile teams. We also provide a number of communication guidelines for working distributed.
08 Sep 2011
Updated reprint (Medium)
Written with Tim Ottinger. What low-tech tools can help in agile, and when and how should high-tech tools be used?
01 Aug 2011
Updated reprint (Medium)
Written with Tim Ottinger. This article is based on the Agile in a Flash card “The Seven Code Virtues.” It presents yet another possible definition for letting us know when code is “good.”
06 Jul 2011
Updated reprint (Medium)
Written with Tim Ottinger. We list over twenty benefits that you can derive from pair programming, categorized as being from the perspective of the team and system, programmers, and managers/project managers.
02 Jun 2011
Written with Tim Ottinger. We discuss three of our Agile in a Flash pairing cards, covering the rules of pairing, pair programming smells, and what to do when not pairing.
02 May 2011
Tim Ottinger and I reflect on the various “agile development practices” (perhaps better classified as the technical practices from extreme programming).
02 Apr 2011
Written with Tim Ottinger. Using smells that identify problems with respect to abstraction in your unit tests, we whittle down an ugly test (take from open source) into a pair of highly readable, maintainable tests.
02 Mar 2011
Written with Tim Ottinger. The final in a series of four articles on Tim's “big ideas” in software development. This article discusses what volatility is, what problems it can create, and how to begin controlling it.
01 Feb 2011
Updated reprint (Medium)
Written with Tim Ottinger. The third in a series of four articles on Tim's “big ideas” in software development. In this article, we talk about abstraction using the perspective of Robert C. Martin's definition: "the elimination of the irrelevant and the amplification of the essential."
01 Jan 2011
Updated reprint (Medium)
Written with Tim Ottinger. The second in a series of four articles on Tim's “big ideas” in software development. In this article, we dig into various kinds of dependencies and present thoughts on how to minimize them.
08 Dec 2010
In a guest blog post for a defunct Ruby learning site, I talk about my experiences building quick’n’dirty scripts in Ruby and Python, and how that’s almost always a mistake.
01 Dec 2010
Updated reprint (Medium)
Tim Ottinger and I talk about one of the four “big ideas” in software, cohesion. Cohesion–the principle that “things that belong together should be kept together”–makes code easier to understand, debug, and test.
01 Nov 2010
Written with Tim Ottinger. Our well-meaning agile coach’s maturity model was based, either deliberately or subconsciously, on Shuhari, a Japanese martial arts concept involving three stages of mastery: “first learn, then detach, and finally transcend.”
01 Oct 2010
Tim Ottinger and I present some stories about dogmatists, cowboys, and authoritarians, demonstrating a few ways that your transition to agile can be derailed.
01 Sep 2010
Tim Ottinger and I introduce our Agile in a Flash project, and talk about the value of the index cards by presenting three meta-cards.
A companion piece to Mike Cohn’s book Succeeding with Agile: Software Development Using Scrum. It takes an automated test example from the book and demonstrates how to enhance it to act as clearer documentation on the system’s capabilities.
The design patterns book lists 23 design patterns, but that’s just the beginning! Many more patterns exist, including the specification pattern, lazy initialization, object pools, and the utility class pattern.
One of the bigger challenges with using design patterns is knowing when to use one pattern over another. The abstract factory creational pattern looks similar to the builder pattern but is used to help solve a different problem.
Your production code isn’t the only place you will find a use for design patterns. The factory method pattern helps you answer a question about how to organize your test classes.
Building applications for the BlackBerry involves a few interesting wrinkles. Explore some of these challenges in building a front end for a new BlackBerry unit testing framework.
What do you do when there’s no effective unit testing framework for your programming environment? Why, build your own, of course! Building a simple unit testing framework for the BlackBerry provides some interesting insights into the BlackBerry programming environment.
Patterns exist for virtually all common programming challenges, even one as simple as “how to traverse a collection of objects.” The iterator pattern provides a consistent solution for something that programmers do daily.
The state pattern can help simplify complex conditional logic by representing individual states as classes, each with its own simple behavior.
Objects talking to each other and no one in control? Messages going all over the place? The mediator pattern can help you control the chaos!
Many of the design patterns lead a double life–the structure of some patterns are exactly alike, but the intent differs. An interpreter is a composite whose purpose is to support interpretation of a simple grammar.
The chain of responsibility pattern allows you to emulate a real-life chain of command. In a chain of responsibility, a request moves from handler to handler until someone is able to manage and return it to the client.
A common theme in design patterns is organizing things so as to separate high-level policy from low-level underlying details. The builder pattern does just that, by allowing a single construction policy to be realized by many different implementations.
Like the abstract factory pattern, the prototype pattern helps you adhere to a clean design by moving object creation into a polymorphic hierarchy. When using the prototype pattern, you create objects by making copies of already existing instances.
The singleton pattern is one of the simplest in the catalog of design patterns. Lurking beneath its simplicity is the potential for testing trouble!
Separating interface from implementation is a fundamental object-oriented strategy, one that’s also the essence of the bridge design pattern. You can use the bridge pattern to help solve the more complex problem of separating tangled hierarchies.
Not all design patterns are complex. The adapter pattern provides a simple mechanism for conforming an interface into one that’s more useful for a client application.
Visitor is often viewed as a complex pattern that’s often regarded as difficult and troublesome. But the appropriate use of visitor demonstrates what’s at the heart of good object-oriented design.
The Memento design pattern presents a consistent solution for storing state, allowing you to build undo and redo support in your applications with ease.
Test doubles (aka fakes or mocks) are a great tool that allow for deeper ability to test-drive solutions. The most common way to use test doubles is to pass them via constructors or setters. But there are at least a couple other solutions.
Deriving metrics in an agile software development process can be an integral part of managing and improving execution. As with any tool, metrics used poorly can actually damage a project. A set of guiding principles for agile metrics can keep your team on track.
TDD is a simple discipline: “a minute to learn, a lifetime to master.” This article offers a number of nuggets on how to improve your mastery of test-driven development.
Are you focusing on the wrong things? Agile promotes de-emphasizing tools, but as agile grows, tools are becoming more pervasive. Agile centers around iterations, but are you focusing too much on the iteration to the detriment of delivering stories?
Some supporting thoughts around the argument that, in most cases, a good design is also a testable design (and conversely, that an untestable design is not a good design).
Should you write tests first (before you write production code), or should you write tests after you build the production code?
Get rid of those pesky “if null” constructs invading and cluttering your code by using the null object pattern!
A pragmatic example of the observer pattern, which provides an important technique for eliminating dual dependencies.
The proxy pattern provides a protection layer for your objects by exposing a stand-in to interested clients. I’ll explore one possible use for the proxy pattern in this article. (Note: The published title of this article is actually Design Patterns: Proxy.)
The decorator pattern gives you the flexibility to wrap special behavior around objects. Unlike inheritance, which gives you the ability to predefine specialized behavior, using the decorator pattern allows you to dynamically attach specialized behavior.
The composite pattern takes advantage of recursion to help produce elegant solutions. This example diverges from the typical examples of the composite pattern.
A simple implementation shows how the strategy pattern can be used to swap in varying algorithms.
Java takes one more tiny step away from its C legacy with this enhancement to version 6.
Got millions of objects? The flyweight pattern can help!
A brief overview of OpenJDK, officially announced at JavaOne, and its implications.
What can we do with duplication? The template method pattern allows us to move common portions of an algorithm to a base class, and leave “holes” to be filled in by derived classes.
Not your usual pattern article. How do we arrive at a command pattern implementation if we’re just test-driving code?
There are a few ways to approach writing unit tests for a Java main method. Should you bother? I think so!
A simple example of how you can refactor some of your longer methods so that they can read well as “high-level policy.” (Hopefully it’s clear from this article’s title that I don’t always have the final say on things like titles and blurbs.)
Object-oriented languages provide great opportunities to isolate complexity in a system. A facade buries an unwieldy interface behind a simplified one.
An emphatic viewpoint on the value of comments, in response to an earlier Developer.com article on comments by Mike Gunderloy.
An article that discusses many of the merits behind pair programming.
Discusses the class java.util.concurrent.DelayQueue, first available as of Java J2SE 5.0. The DelayQueue provides a thread-safe blocking queue that requires objects to remain in the queue for a minimum period of time.
Twenty-one specific recommendations for pair programming.
Part three of a three part introduction to acceptance testing using FitNesse.
An overview of agile software development methodologies.
Part two of a three part introduction to acceptance testing using FitNesse.
A code-based discussion that demonstrates use of the BlockingQueue class found in Java 5’s concurrency packages.
Part one of a three part introduction to acceptance testing using FitNesse.
In the final installment in the TDD series, I talk about how TDD enables more rapid development.
Crafting Java with Test-Driven Development, Part 12: TDD at Cassatt: An Interview with Jerry R. Jackson
In the twelfth installment in the TDD series, I ask Jerry Jackson about his experiences with test-driven development at Cassatt.
In the eleventh installment in the TDD series, I show how to trigger behavior on mouse clicks without cluttering the view with logic.
In the tenth installment in the TDD series, I show how to test-drive building a simple view, and emphasize the need for heavy refactoring of Swing code.
In the ninth installment in the TDD series, I show how it’s possible to drive development of a Swing GUI using TDD.
In the eighth installment in the TDD series, I move the application toward a better design through a series of incremental refactorings. The beautiful part about code is that it’s easily changed, especially if you have tests to be confident about it.
In the seventh installment in the TDD series, I add support for dealing the rest of a hold ’em hand. I also discuss the practice of adding “todo” reminders in code.
In the fifth installment in the TDD series, I show how to write tests for exceptional conditions.
In the sixth installment in the TDD series, I talk about the need to keep tests as refactored as production code, so as to better document class capabilities and keep maintenance costs low.
The fourth installment in the TDD series ponders a number of ways to test that a deck is shuffled so that cards are dealt in a random order.
The third installment in the TDD series follows up on the discussion of building a
.equals method by discussing the need (or not) for test-driving a
The second installment in the TDD series discusses how to drive out the development of a
.equals method using TDD.
The first installment in a new article series on TDD. This 13-installment series will introduce and discuss test-driven development (TDD) concepts. The series presents the incremental development of an application to play the poker game of hold ’em. Installments will appear roughly every other week for about six months.
A brief article on the foreach loop in J2SE 5.0.
The final installment in a series of three articles about the changes in J2SE version 5.0. This installment covers the remaining new features, including foreach, autoboxing, varargs, typesafe enum, static import, and metadata.
A very brief article that discusses the Formatter class in Java J2SE 5.0. The Formatter class allows for String formatting similar to printf in C; it depends on the availability of the varargs feature in J2SE 5.0.
The second in a series of three articles about the changes in Java J2SE version 5.0. This installment digs deeper into the new generics feature.
A very brief article that overviews the varargs (variable arguments) feature in J2SE 5.0.
The first in a series of three articles about the changes in Java J2SE version 5.0. This installment overviews the changes and begins a discussion on the generics feature.
A lead article from the (defunct) C/C++ Users Journal about how to do test-driven development when working in C. Written with Dr. Robert Koss.
An article about using test-driven development in conjunction with GUI development. It demonstrates an approach using Java and Swing to build a small game.
A critique of Pete McBreen’s book Questioning Extreme Programming, hosted at Ron Jeffries’ original site on extreme programming.
A solution for what I call “simple style.” Three rules, instead of an entire book, to give you a simple approach for ensuring that your code remains highly readable and maintainable.
01 Jan 2001
Presented at OOPSLA 2001. A simple exposition of how to build code using test-first design. The example produces a class that the author still uses for reading CSV (comma-separated values) files.