Agile Documentation: Specification by Example (26-Aug-2009)
Published at InformIT, this article is 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.
Agile Reflections:A Dozen Years or so of Agile Development Practices (2-May-2011)
Written with Tim Ottinger for PragPub. Tim and I reflect on the various “agile development practices” (perhaps better classified as the technical practices from extreme programming).
Building a Simple BlackBerry Application Interface (14-Aug-2008)
Written for Developer.com. 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.
But We Have These Distributed Folks (Oct-2011)
Written with Tim Ottinger for PragPub. Is “distributed agile” an oxymoron or reality? Tim 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.
Can Refactoring Produce Better Code? (6-Mar-2007)
A simple example of how you can refactor some of your longer methods so that they can read well as “high-level policy.” Hosted at Developer.com. (Hopefully it’s clear from this article’s title that I don’t always have the final say on things like titles and blurbs.)
Cohesive Software Design (Dec-2010)
Written with Tim Ottinger for PragPub. Tim 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.
Connecting the Dots (8-Mar-2002)
An article published in Software Development magazine (now part of Dr. Dobbs) about using test-driven development in conjunction with GUI development. The article demonstrates an approach using Java and Swing to build a small game.
Considering Test-After Development (24-Sep-2007)
Written for Developer.com. Should you write tests first (before you write production code), or should you write tests after you build the production code?
Crafting Java with Test-Driven Development, Part 1: Getting Started (13-Jan-2006)
The first installment in a new series at Informit. 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.
Crafting Java with Test-Driven Development, Part 2: Testing Equality (20-Jan-2006)
The second installment in the TDD series at Informit discusses how to drive out the development of a
.equals method using TDD.
Crafting Java with Test-Driven Development, Part 3: Testing Hash Codes (27-Jan-2006)
The third installment in the TDD series at Informit follows up on the discussion of building a
.equals method by discussing the need (or not) for test-driving a
Crafting Java with Test-Driven Development, Part 4: Shuffling and Dealing (3-Feb-2006)
The fourth installment in the TDD series at Informit ponders a number of ways to test that a deck is shuffled so that cards are dealt in a random order.
Crafting Java with Test-Driven Development, Part 5: Handling Exceptions (17-Feb-2006)
In the fifth installment in the TDD series at Informit, I show how to write tests for exceptional conditions.
Crafting Java with Test-Driven Development, Part 6: Refactoring Tests (10-Feb-2006)
In the sixth installment in the TDD series at Informit, 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.
Crafting Java with Test-Driven Development, Part 7: Adding Some Bulk (17-Mar-2006)
In the seventh installment in the TDD series at Informit, I add support for dealing the rest of a hold ’em hand. I also discuss the practice of adding “todo” reminders in code.
Crafting Java with Test-Driven Development, Part 8: It’s Just Code (24-Mar-2006)
In the eighth installment in the TDD series at Informit, 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.
Crafting Java with Test-Driven Development, Part 9: Driving a User Interface (7-Apr-2006)
In the ninth installment in the TDD series at Informit, I show how it’s possible to drive development of a Swing GUI using TDD.
Crafting Java with Test-Driven Development, Part 10: Building the View (14-Apr-2006)
In the tenth installment in the TDD series at Informit, I show how test-drive building a simple view, emphasizing the need for heavy refactoring of Swing code.
Crafting Java with Test-Driven Development, Part 11: Making Things Happen (21-Apr-2006)
In the eleventh installment in the TDD series at Informit, I show how to trigger behavior on mouse clicks without cluttering the view with logic.
Crafting Java with Test-Driven Development, Part 12: TDD at Cassatt: An Interview with Jerry R. Jackson (28-Apr-2006)
In the twelfth installment in the TDD series at Informit, I ask Jerry Jackson about his experiences with test-driven development at Cassatt.
Crafting Java with Test-Driven Development, Part 13: Nine Reasons Why You Should Be Using TDD (26-May-2006)
In the final installment in the TDD series at Informit, I talk about how TDD enables more rapid development.
Doing TDD Well (19-Nov-2007)
TDD is a simple discipline: “a minute to learn, a lifetime to master.” This Developer.com article offers a number of nuggets on how to improve your mastery of test-driven development.
Don’t Mock Me (22-Jun-2004)
A discussion of the forces that drive the need for mock objects, as well as the design impacts of introducing mocks. This is the peer-reviewed submission to the 2004 Agile Developers Conference. (The original article appears in Jeff’s Blog.)
Enlightened Java Style (12-Feb-2002)
A solution published in Software Development magazine (now part of Dr. Dobbs) 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.
Evolution of Test and Code via Test-First Design (Jan-2001)
An article 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.
The Formatter Class in J2SE 5.0 (18-Mar-2004)
A very brief article written for Gamelan.com (part of Developer.com) 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.
Getting Test Doubles in Place (3-Jan-2008)
Written for Developer.com. 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.
Half of a Third of a Century in TDD (6-Jul-2016)
A reflection on why I’ve found TDD to be an indispensable practice for the past sixth of a century. Published for PragPub–get the whole issue with a pile of great articles at The Prose Garden.
How Virtuous Is Your Code? (Aug-2011)
Written with Tim Ottinger for PragPub. 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.”
Java 5’s BlockingQueue (22-Nov-2006)
Article appearing at Gamelan.com (part of Developer.com). A code-based discussion that demonstrates use of the BlockingQueue class found in Java 5’s concurrency packages.
Java 5’s DelayQueue (18-Jan-2007)
An article appearing at Gamelan.com (part of Developer.com) that 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.
Making the Grade (part 2 of 3) (12-Mar-2004)
The second in a series of three articles published in Software Development magazine (now part of Dr. Dobbs) about the changes in Java J2SE version 5.0. This installment digs deeper into the new generics feature.
Pair Programming Benefits (6-Jul-2011)
Written with Tim Ottinger for PragPub. 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.
Pair Programming in a Flash (2-Jun-2011)
Written with Tim Ottinger for PragPub. 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.
Pairing Across Time and Space (2-Mar-2016)
Written with Tim Ottinger for AgileConnection. 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.
Principles for Agile Metrics (7-Dec-2007)
Written for Developer.com. 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.
Rule #1 for Distributed Teams–The 2015 Edition (Apr 2015)
Written for PragPub. revisits his own coding history and finds it necessary to revise one of his basic principles. Along the way he shares some hard-won insights on how to make distributed development teams work.
Shu Ha Ri–Learn, Detach, Transcend: Steps to Agile Mastery (Nov-2010)
Written with Tim Ottinger for PragPub. 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.”
Software Volatility (2-Mar-2011)
Written with Tim Ottinger for PragPub. The final in a series of four articles on the “big ideas” in software development. This article discusses what volatility is, what problems it can create, and how to begin controlling it.
Succeeding With and Sustaining TDD (Dec 2011)
Published in the Java Tech Journal, this article presents 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.
Sweet and Simple (part 3 of 3) (12-Apr-2004)
The final installment in a series of three articles published in Software Development magazine (now part of Dr. Dobbs) 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.
Test Abstraction: Eight Techniques to Improve Your Tests (2-Apr-2011)
Written with Tim Ottinger for PragPub. 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.
Test-Driven Development: A Guide for Non-Programmers (2-Nov-2011)
Written for PragPub. Want your manager to understand test-driven development (TDD)? This article overview 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.
Test-Driven Development in C/C++ (15-Apr-2003)
A lead article originally published in (the now defunct) C/C++ Users Journal about how to do test-driven development when working in C. Written with Dr. Robert Koss.
Testability and Design (10-Oct-2007)
This article discusses some supporting ideas for this argument that, in most cases, a good design is also a testable design (and conversely, that an untestable design is not a good design). Hosted at Developer.com.
Tiger Stripes (part 1 of 3) (10-Feb-2004)
The first in a series of three articles published in Software Development magazine (now part of Dr. Dobbs) about the changes in Java J2SE version 5.0. This installment overviews the changes and begins a discussion on the generics feature.
Tools, Iterations, and Stories (29-Oct-2007)
A brief article written for Developer.com. 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?
A Unit Testing Framework for the BlackBerry (24-Jul-2008)
Written for Developer.com. 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.
Note that this article contains a link to code that can be found at Developer.com. That code will likely not get updated. You should instead use the link http://langrsoft.com/ftp/bbtest.zip.
What Agile is Not (Oct-2010)
Written with Tim Ottinger for PragPub. Tim and I present some stories about dogmatists, cowboys, and authoritarians, demonstrating a few ways that your transition to agile can be derailed.
Why Pair?: Challenges and Rewards of Pair Programming (7-Feb-2007)
An article written for Developer.com that discusses many of the merits behind pair programming.
Working With Design Patterns: Abstract Factory (4-Sep-2008)
Written for Developer.com. 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.
Working With Design Patterns: Adapter (6-Feb-2008)
Written for Developer.com. 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.
Working With Design Patterns: Bridge (5-Mar-2008)
Written for Developer.com. 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.
Working With Design Patterns: Builder (21-Apr-2008)
Written for Developer.com. 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.
Working With Design Patterns: Chain of Responsibility (7-May-2008)
Written for Developer.com. 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.
Working With Design Patterns: Composite (2-Jul-2007)
Written for Developer.com. The composite pattern takes advantage of recursion to help produce elegant solutions. This example diverges from the typical examples of the composite pattern.
Working With Design Patterns: Decorator (18-Jul-2007)
Written for Developer.com. 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.
Working With Design Patterns: Facade (21-Feb-2007)
Written for Developer.com. Object-oriented languages provide great opportunities to isolate complexity in a system. A facade buries an unwieldy interface behind a simplified one.
Working With Design Patterns: Factory Method (28-Aug-2008)
Written for Developer.com. 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.
Working With Design Patterns: Interpeter (22-May-2008)
Written for Developer.com. 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.
Working With Design Patterns: Iterator (9-Jul-2008)
Written for Developer.com. 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.
Working With Design Patterns: Mediator (5-Jun-2008)
Written for Developer.com. 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!
Working With Design Patterns: Memento (10-Jan-2008)
Written for Developer.com. The Memento design pattern presents a consistent solution for storing state, allowing you to build undo and redo support in your applications with ease.
Working With Design Patterns: Odds and Ends (18-Sep-2008)
Written for Developer.com. 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.
Working With Design Patterns: Prototype (2-Apr-2008)
Written for Developer.com. 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.
Working With Design Patterns: Proxy (1-Aug-2007)
Written for Developer.com. (The original, official title is Design Patterns: Proxy) 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.
Working With Design Patterns: Singleton (20-Mar-2008)
Written for Developer.com. The singleton pattern is one of the simplest in the catalog of design patterns. Lurking beneath its simplicity is the potential for testing trouble!
Working With Design Patterns: State (19-Jun-2008)
Written for Developer.com. The state pattern can help simplify complex conditional logic by representing individual states as classes, each with its own simple behavior.
Working With Design Patterns: Template Method (27-Apr-2007)
Written for Developer.com. 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.
Working With Design Patterns: Visitor (28-Jan-2008)
Written for Developer.com. 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.