(Jun 27, 2016)
Some interesting tweets make me wonder: if I were creating a method today, what would it be?
(May 27, 2016)
Over the past few days, an ancient twitter thread accidentally revived, talking about how you don't need quality code when you're just validating assumptions. What do the ants have to say about that?
(Dec 18, 2015)
I was asked a question via email and liked my answer enough to write it up. I hope you like it too.
(Nov 3, 2015)
A Twitter thread gets me thinking about Mock objects and whether they're more than just a matter of personal taste.
(Nov 2, 2015)
Let's try this again. The previous article was not clear to all readers. I suppose this is often the case with my work but in this case I thought I'd try again.
(Oct 30, 2015)
At the time of the Agile Manifesto, we all did the best we knew. Here's something I wish we had done. (Revised)
(Oct 18, 2015)
The Backlog is an essential artifact in Scrum. It may also be the root of serious dysfunction.
(Oct 12, 2015)
Generalizing from a few results isn't proof. In this article I'm going to prove that by generalizing from a few results. Wait, what?
(Jul 29, 2015)
If we can't build software well, all our Agile is for nothing.
(Feb 13, 2015)
Content from XProgramming has been moved to this site. Some brief retrospective thoughts.
(Oct 7, 2014)
Robin Dymond asked me to write about making stories small. Well, there's this.
(Apr 1, 2014)
My friends and colleagues in the #NoEstimates circles have some good ideas, as I've commented elsewhere. I'm left, though, with a couple of concerns.
(Mar 27, 2014)
The Agile Manifesto says "Deliver working software frequently". Learn to do that. The rest will follow.
(Aug 23, 2010)
At the Agile Developer Skills course at the Raikes School, I commented that we don't usually test accessors. But we test everything. Is this a contradiction?
(Aug 5, 2010)
Jon Bettinger has found a failing test! Excellent!
(Aug 4, 2010)
Philip Schwarz provided a nice-looking implementation. Let's look at it and try to build on his ideas.
(Aug 4, 2010)
My critiXXXXX advisors expected a more function-oriented solution. Here's something a bit better, perhaps ...
(Aug 3, 2010)
I've been working with Scala a bit, just to learn what it is. I've found it interesting, if frustrating. Here is a bowling experiment.
(Mar 8, 2010)
Uncle Bob Martin comments on "Developer Certification WTF?" in a recent blog entry. Let's talk a bit about developer quality, and some things that are being done about it.
(Mar 6, 2010)
Choose your tools wisely, that they allow for the development of your skill.
(Mar 5, 2010)
Jim Shore has written a short item with the above title. Let's think about it a bit.
(Dec 23, 2009)
There are essential practices in Scrum and Agile. Not because we say so. It's the nature of the beast.
(Apr 10, 1998)
They're not XP's rules, they're the team's rules.
(Apr 8, 1998)
(Mar 24, 1998)
The C3 project team has voluntarily adopted a large number of practices. Every team member follows these practices closely. We have found that designing, coding, and testing in a consistent way means that the team becomes quite well integrated and that team members know just what they can expect from each other. Software quality is kept more uniform, and at a high level.
(Mar 23, 1998)
Never underestimate the power of inspecting and changing things with Inspectors. Perhaps your GemStone database is messed up: a bunch of People have excess Parts in certain Bins.
(Mar 23, 1998)
There is some written documentation for the software, more commonly interpreting requirements than documenting design. Sometimes we document an approach to some particularly difficult area. We "never" document code.
(Mar 23, 1998)
A few times during the project, a team took on a task and did not complete it within the iteration. They wanted to complete the task and kept it for the next iteration. This generally turned out to be a mistake.
(Mar 23, 1998)
We call the combination of frequent release with tests at 100%: continuous integration, relentless testing. The result is rapid progress and a system that always works better than it did the day before.
(Mar 23, 1998)
In general, we do not comment our methods. Beck teaches that a comment is used to indicate that a method is not yet finished. That’s how we use them.
(Mar 23, 1998)
We all code to the exact same standards. We name our classes and methods the same way, we format code the same way.
(Mar 23, 1998)
Here are a few of the key code formatting patterns we use. The names and some of the examples are from Kent’s book.
(Mar 23, 1998)
We do use class comments to describe what a class is for, and sometimes how it works. We probably don’t do this often enough, and we probably don’t keep them as up to date as we should.
(Mar 23, 1998)
Simplicity + Communication + Testing = Aggressiveness
(Mar 23, 1998)
We use CRC card design almost exclusively. Developers, managers, and users are all comfortable with the cards, since they are non-threatening. Moving the cards around makes it easy to describe how classes work, and it is easy to throw a couple of cards away and create new ones if the design isn’t working out.