(Jul 28, 2017)
Thoughts about Technical Debt
(Jul 28, 2017)
Time to do some work after the heavy refactorings involving quantum mechanics. Let's see if we remember how.
(Jul 26, 2017)
I was asked a question about one of today's modern approaches to Agile software development. Here are some general thoughts.
(Jul 25, 2017)
In this short session, we inch forward and wind up in a better place. Not THAT better place. I just mean the code is better.
(Jul 20, 2017)
What's next for the iPad project? Refactoring, it turns out.
(Jul 13, 2017)
We knew last Thursday that we had an issue with folders and folder names. A week later, we dig back in.
(Jul 12, 2017)
An innocent email question leads me off into wildness and chaos. What's new with you?
(Jul 6, 2017)
We really hope to get from end to end today. You won't believe what happens next. Unless you're paying attention.
(Jul 4, 2017)
Tozier and I shoot again for end to end on the iPad project. What happens next? As I write these words, I don't know either.
(Jun 30, 2017)
We're clearly closer than we were, and it feels very close. But not as close as we thought.
(Jun 28, 2017)
Bill and I decided to do a bit more on the iPad publication project. You won't believe what happened next. Unless you expect trouble.
(Jun 26, 2017)
What if I were to create a new software development framework? I'd never do that, but if I did, what might I do? Let's find out. Let's talk today about Whole Team.
(Jun 25, 2017)
Terms seem important to me today. (Revised 2017-07-05: Techniques)
(Jun 25, 2017)
Some Notes on the theme "If I were going to create a new framework, what would it be?".
(Jun 20, 2017)
Today Tozier and I will do a Quick Design Session and start TDDing something that will, I hope, turn into the actual app.
(Jun 16, 2017)
In which we suddenly realize something about Tozier.
(Jun 15, 2017)
Tozier and I start with some Ruby code for FTP or something.
(Jun 14, 2017)
Tozier and I try some things.
(Jun 10, 2017)
I'm told the iPad is the new Mac, or something. Anyway, it'd be nice to be able to write articles on the iPad and get them on my web site without lugging around my Macbook.
(Feb 19, 2017)
I've been trying to learn a 3D drawing program. Yesterday I noticed that I was working but not learning.
(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)
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)
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)
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 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.
(Mar 23, 1998)
Simplicity + Communication + Testing = Aggressiveness
(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)
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)
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.