Category: XProgramming

Historically, this was a category for shorter, more edgy articles. I might just bring it back into common use.

XProgramming will transition slowly over to ronjeffries.com. Be there or be square.

Martin Alaimo asked about the Manifesto Principle "The best architectures, requirements, and designs emerge from self-organizing teams."

Experience with Sinatra, and some thinking, cause us to look at a shift in approach. Martin Fowler was probably right.

Ignatz and Jmv38 on the Codea forums commented on the previous article. I had hoped to do more anyway so here's the next one.

Based on a simple example on the codea.io forums, I decided to write an article showing all the stuff I might do on a production calculator project. Wow.

Robin Dymond asked me to write about making stories small. Well, there's this.

Scrum top dogs announce combined site for Scrum definition.

XProgramming.com needs a new implementation. Want to watch?

A small progress report on the new site implementation.

Put makeup on your own pig, make it look as good as you can. Don't go around finding ugly imaginary pigs to stand it beside.

A report on the books, tools, and toys that have recently wandered through my life.

There has recently been a lot of noise on the lists, and questions at conferences, about putting refactoring "stories" on the backlog. Even if "technical debt" has grown up, this is invariably an inferior idea.

Recent Twitter conversations inspire me to pull out some of my concerns with SAFe and talk about them.

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.

The Agile Manifesto says "Deliver working software frequently". Learn to do that. The rest will follow.

Kate's Gang chat about estimates, time, and cost.

I recently took the SAFe SPC training. My bottom line assessment is that it will be a marketing success, organizations trying it will see improvement, and some will see great improvement. And I don't like it.

Don't buy a brand. Seek out good ideas, and apply them to your situation.

The sky is blue on my planet. I live in the same real world you do, and have probably done so longer.

There’s a lot of interesting talk and thinking, going on under the heading of #NoEstimates. I think it's great, and I'm all for it. To do #NoEstimates, people will need some help ...

Robert Pirsig's protagonist "Phaedrus" said "Quality is what you like". We talk a lot about "value". My aim here is to suggest to you that value is what you like.

Are "manual" versus "automated" useful terms? As a matter of fact, yes, they are ...

It's time to tell you a bit about the point of this little game we're working in.

In this episode, the code tells us to move toward a subordinate drawable object, the Polyline. We listen.

I'm starting to work on an application in Codea, a Lua system for the iPad. Here's the first spike.

Kate gives Dan Devlin, the company owner, an overview of Scrum.

Piers Thompson sent me a good question about my recent database articles. I suspect others would like to hear the question and answers.

Here's the current code, and some commentary, for the "But We Need a Database" article. UPDATED: Comments on Python style.

Last week Chet and I taught a delightful XP Experience class in Delaware. As often happens--where by often I mean always--the participants ran into trouble trying to apply Simple Design ideas when it came time for the system to demonstrate the ability to store and retrieve information. Let's talk about that.

Kate met Dan Devlin at the coffee shop on Main Street where he had originally recruited her. They shared the lovely weather and caught up to date on their lives. But Dan had a question.

It is with some regret that I'm discontinuing my articles about J and about iLua on the iPad. Here's why. Also, I have a question.

Need a little help getting some data in and out of Second Life. World's most rudimentary scripting language, world's most ignorant scripter.

I've downloaded the iLuaBox app for my iPad. This is a small but robust implementation of core Lua. Very interesting!

I did a bit more refinement on the Lua bowling example from last time. First, I package the rolls. Then a Frame appears!

A twitter pal has been working on bowling with a frame display notion, like at the bowling alley. Hmm ...

No, really. This is hard. People ask me why I'm doing it. There are reasons ...

Just recording random discoveries as I work through the EasyJ book. Read if all that interested in how I think ...

To do J, you must change the way you think. You must also learn many new words and other parts of speech. Working on part one today ...

J is doing strange things to my mind. I must report now, before my thoughts are too alien to communicate at all.

Chet and I are thinking of doing an app for iPhone / iPad. Can we do it on a shoestring? Advise us.

Alan Shalloway blogged on "Big Change Up Front", suggesting that it's not always the best thing to do. This made me think ...

"Why don't you believe in testing?" said Lanette Creamer, the Testy Redhead. Ah, but I do. I care about what, when, and at which end of the horse.

An odd anonymous article on "LearnTFS" purports to debunk Agile by moving closer to waterfall. Interesting, but not quite right.

I've had the privilege of observing He Jinbao, a martial arts master. He doesn't hurry. Maybe we shouldn't either.

Are there places where lower quality has less negative impact? Possibly. Except maybe on your soul.

No one I know can operate at their peak performance all the time. How do we know how hard to work on quality? Same way you get to Carnegie Hall.

You can always find someone to argue for cutting quality corners to "go faster". Is it possible to waste time cleaning code? Sure. Is it possible for code to be too clean? No.

Teams often want to write "technical stories" to cover things like testing and improving the design or infrastructure. There is rarely a need to do this. Here's why.

Alan Shalloway and I were tweeting about whether Scrum could be improved because it doesn't include some damn thing or other. Scrum is working as designed. We and the Alliance need to get to work.

Chet and I will be meeting with both the new and the outgoing Managing Director of the Scrum Alliance. I asked for input on Twitter, and have received some. Here, some thoughts.

Kate's team has noticed that their burn down chart shows trouble. The chart is right.

"Just tell us when you'll be done with all these requirements" is not how to guide an Agile project, be it Kanban, Scrum, or XP. Not remotely.

Some people have difficulty living up to the values and principles of the Agile Manifesto. Should we improve the Manifesto? Raise your game: we meant what we said.

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?

Jon Bettinger has found a failing test! Excellent!

My critiXXXXX advisors expected a more function-oriented solution. Here's something a bit better, perhaps ...

Philip Schwarz provided a nice-looking implementation. Let's look at it and try to build on his ideas.

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.

Just for something to do, I'm learning? Scala. Having deep confusion making JUnit suites run. Advise me in comments if you're up for it?

"His brand is bad: my brand is good." Isn't it well past time we got over that kind of thinking? I'll take a good idea from anywhere. So should you.

Should we ease into Agile, or jump in? How fond of being eaten by bears are you?

Let's consider two "dimensions" of a project, the extent to which it adheres to "Agile" values, and the extent to which it is an effective or successful project.

Susan said, “I can’t do it, Kate. No one could do it. There’s too much to do.” Kate paused until Susan seemed more steady. Then she said “Exactly. And that’s how we get done on time.”

Cut quality to go faster? It could happen. There's more to the story, however.

The thing about software development ...

There has recently been another discussion of Kanban on one of the Scrum lists. Kanban has some interesting ideas, and yet it seems to conflict with Scrum in some essential ways. The problem isn't Kanban: it's the notion of "essential ways".

It's time for the Scrum Alliance to stop using the C word, "Certified". It is holding us all back.

Some thoughts from Chet Hendrickson on the CSD program.

Why, anybody can have a brain. That's a very mediocre commodity. Every pusillanimous creature that crawls on the Earth or slinks through slimy seas has a brain. Back where I come from, we have universities, seats of great learning, where men go to become great thinkers. And when they come out, they think deep thoughts and with no more brains than you have! But they have one thing you haven't got - a diploma.

The Scrum Alliance is instituting a Certified Scrum Developer program (finally). Chet and I are involved. Here's why and how ...

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.

Choose your tools wisely, that they allow for the development of your skill.

Jim Shore has written a short item with the above title. Let's think about it a bit.

After a failed iteration, the team regroups with a few new stories.

The team has fallen far short in the most recent iteration. What should they do?

Author Matthew B. Crawford is a physicist, has a Ph.D. in political philosophy, and is a motorcycle mechanic. What's not to like? Recommended for practitioners, managers, executives.

Have all your desired features or make an exact date. What's so hard about that?

There are essential practices in Scrum and Agile. Not because we say so. It's the nature of the beast.

Agile projects very often seem to stall out after gaining perhaps twenty-five percent of the possible benefit. Why is this? What can be done?

Incremental and iterative development processes provide frequent opportunities for teams to "Inspect and Adapt". What should we inspect? How should we adapt? Is this part of the process?

I just thought I'd make a page with links that may be worth exploring. If you have some, let me know. I have not explored all of these, nor, probably, have you. That's why I'm listing them.

Here are a few links relating to collocation, thanks to Adrian Howard and others.

Scrum luminaries freely grant the necessity for good developer practices, and the Scrum Alliance is thinking about developer certification. Some important people in the community are involved, and so am I. Read on ...

There has been some discussion of late regarding the use of Test-Driven Development ideas in non-software areas. This is a really good idea and I would like to talk about it here.

When terms like Agile or Scrum or TDD get watered down, everyone loses.

Susan Prior drops in on Kate to talk about some new products she would like developed.

A pizza of radius z and thickness a has volume pi*z*z*a. That is all.

We humans like to take a very soft cloud of ideas and give it a name, and then to insist on how good our Named Cloud is compared to some other Named Cloud.

What should an iterative-Agile team do if it appears that not all the stories they signed up for will get done? Is Kanban the answer?

OK, let's talk about when to automate tests for the ten thousandth time. I'm patient, in a manner of speaking. I can keep doing this until you get it.

Scrum's job ends with the problem. Your job begins with the problem.

I don't believe this quite as much as I did when I wrote it. How about you?

Anything as hokey as this title needs to be preserved. Really.

Article by Kent Beck and Dave Cleal offering an alternative to fixed-price contracts.

We have Worst Things First, which tells us what to worry about. On the other hand, our division of responsibilities tells us that the customer decides which stories to work on. Does WTF only apply within the particular story we have in hand now, or do we somehow exercise programmer forethought in deciding what we need to worry about?

The Distributed Computing link lets you get a copy of the C3 team's famous article in Distributed Computing.

We recently got some questions about the story "We'll Try". Send us your questions! The article assumes that the deadline is fixed and that the client should trade off the project objectives. It seems to ignore the possibility that there are other things the client might want to trade off such as cost and deadline or more complex issues like aspects of quality such as maintainability, flexibility, reliability, usability, etc.

You XP guys advocate testing, not inspections or program proofs. Everyone knows that testing can only show that errors exist, not that they don't.

A very experienced QA manager recently emailed me some tough questions. Here they are, with are my answers. As always, comments and further questions are welcome!

Here, in order, are the online chapters of Annals of Kate Oneal

Ward Cunningham posted a video on Technical Debt, and Kent Beck and Ed Yourdon (and I) have been tweeting about it. Let me share some thoughts with you here.

Bad product? Bad customer service? Don't care.

In order to do Scrum or XP or any form of Agile successfully, you must refactor. Sorry, not optional. Necessary.

Let's talk about more about code improvement. Some people seem to think that code improvement has a high associated cost. I think it only has a high cost if we're not very good at it.

The traditional CSM course is only two days. That's not enough time to cover the things a ScrumMaster needs to know to help their team be successful.

Many teams seem to get in trouble because they do not have good technical practices. In Scrum terms, they can't get "Done". Is Scrum flawed because these teams do not "discover" such practices?

Some people think that there is a necessary trade-off between internal code quality, and getting things done rapidly. I believe they are quite mistaken.

The amount of context focus is too damn high!

Let's talk about the importance of pair programming.

How many times do I have to tell you this???

The statement means "I cannot refute your foolish and unrealistic argument but I don't intend to change my mind."

On the leandevelopment list, there has been a bit of a discussion on how long the "backlog" should be, and why.

Pressure only works if I get them done: otherwise it just frustrates me, makes me feel bad, makes me slower still.

When we make decisions based on any kind of "true faith" approach, be it religion, Waterfall, or Agile Zealotry, we know we are right. If things don't work out as we hoped, it's not our fault.

Some thoughts on always carrying a throw-down duck.

Burn stories, not tasks. Don't do tasks. Do stories.

Is a call for more principle behavior going to improve our performance? Frankly, I have my doubts.

As my old friend Charles Bair used to say, that's a two-part question. "How?" and "should user stories be written?" The answer to the second question is "No, not really."

SHORTEN THE ITERATION!!!

Code that slows us down is bad design.

There's nothing like a bean counter when it comes to improving your shopping experience.

Test-Driven Development checks intention. Customer Acceptance Tests check desire.

Scrum works, when it does, because you do just two things.

A link to a gem of an article.

Michael Feathers asks: Are nested classes really a good idea?

Recent discussions on the lists inspire me to take a radical position. Or maybe it's my life. Or an accident of birth. Anyway: Agile Software Development requires software development.

MUCH LATER: Organizations certainly need good productivity. Sometimes they ask for improved productivity, and a way to show that we have improved. Is this always evil?

Carl is concerned about small releases, and catches Kate in the coffee room. They talk about why small releases matter to Kate, and they both learn a bit.

After Dan Devlin, President of Oak River Software, dropped in on her at the coffee shop, Kate agreed to consider helping with the proposed new Empire project. Empire was life or death for Oak River. Without Empire, they'd go under, and Dan couldn't afford to fund it.

The forum was set up as an experiment to see whether a self-sustaining forum-style site would work. This one, at least, has not. With regret, I'm shutting it down.

"Kate" puts a word in about how things really got started, and promises to come back and sort Ron out if he needs it.

Chet and I have decided that the thing to do is to build the software page using full-on Ruby generators and get it out of the way. Here we go again. This doesn't turn out at all as we expected. Project cancelled! Has XP failed???

We review cards and letters, and we finish our first elementary story. We think we will start over. Oh, and my computer is now fast again. Read on ...

We start on the first story, but get into some trouble with my machine. And you're probably wondering what we're actually up to anyway ... take a look!

We take a few moments to write stories and talk about what should be done. Who says we don't plan?

After a long hiatus, we're back! We're tired of Java and C# and decided to do something with Ruby on Rails. Come along for the train ride. Or wreck, as the case may be.

With a little time on our hands, we make our sketched story run and smooth out the code. Generality is showing up, almost by magic. Except it isn't magic -- you can do it too!

We move forward incrementally, improving the report generation by adding new paragraphs, observing missing ideas, and removing duplication. Could that be all there is to this? Is "all" a good word in that question?

In which our intrepid heroes leap fearlessly directly into a flaming pot of YAGNI. Will they surface? Will they be fried?

Our tests run, the code structure is good, yet we are not entirely happy. What's up with that?

Distracted by the Style and Grace planning and other things, Chet and Ron have been away from the Shotgun project for a while. They need to reload their minds and get back to it. Will our heroes prevail? You know they will.

After a lot of reflection on how things are proceeding in our favorite software community, Chet and Ron have decided to hold a public workshop to share and practice building software in teams, with an eye to helping all the attendees ... including ourselves ... sharpen software and team skills.

With great courage and at great personal risk, Chet and Ron attempt a new world's record in high-altitude pair programming.

We've been working for a couple of weeks of elapsed time now, we figure, so it's time to focus a bit more on end to end. How about a draft PDF report?

When we went to the unit square implementation of PatterningSheet and ShotPattern, we stopped after the FitNesse tests ran, but before we modified our image-drawing spikes. Here, we complete that implementation and clean up the code as we do it.

We get all the tests running after scaling to the unit square, and clean up the code substantially. Full listings in this issue, so stand back when you open the page.

A few more notes from our friends, and a solo pass over the code. Redneck's last words? "Watch this!"

Last time, we jammed our new density code into the system, adding some incompatible methods and values. Today we're going to begin to smooth out that code to get the design back closer to good. Will we succeed, or fall on our faces?

A little experiment for confidence, and we make our Customer's Density test complete, and make it pass. The world does not come to an end. (Updated: a remark on time.)

Much less effort, a step toward perfection. And perhaps we know why ...

We draw some density pictures, improve some code, and recognize at least some of our flaws.

Chet and I get together for the first time in 2007, to some useful effect. Also I try to provide a bit more insight into what we're doing, and not doing, and why.

Today's plan was to write the acceptance test for another story, and make it run. The best-laid plans ...

Here's the call for participation for the Agile2007 conference, August 13-17, 2007, in Washington, DC.

I was reading some interesting stuff on Andy Hunt's blog, and as it was 6 AM and I had nothing else to do, I took this test ..

There has been some interesting discussion of image processing ideas and such on the lists, owing to our discovery that the paper has some 1500 holes, and the picture only about half as many visible strikes. Here are some of the pictures, and some thoughts on what we're about.

All right, already! We break down and draw a visible picture, mostly because I wanted Chet to share in the discovery and I knew I couldn't hold off over the holidays. It looks cool. Does it tell us anything?

We combine the PatterningSheet into ShotPattern, and discuss the effects of doing so.

Today we think we'll work on consolidating pixels into actual hits, or an approximation thereof. Join us at Borders. If nothing else, you'll see a prodigious 18 minute spewing of code.

On the plane to Florida, I got an idea for how to clump adjacent pixels to represent a single hit. Apres moi, le rat hole. Here's a report ...

A new low! We're taken to task for thinking in our free time! I attempt an explanation, and add some random thoughts. Quelle surprise!

We've agreed to do this project the way that we think projects should be done, and that includes Acceptance tests. Today we'll try for the first one.

I have the day off, and I drew a nice picture for the previous article, so I decided to work on a spike for Chet's radial pattern density chart. Let's find out what happens.

We've been working for almost two full days now, and it seemed time to refine some stories. We found some conflicts between ourselves as programmers, ourselves as customers, and ourselves as advisors to projects

We've been spiking long enough to learn some key things, and it'll soon be time to create better stories and estimate them. Today we finish up the spike on density and learn a few things about those libraries everyone thinks we should use.

Our first spike took a bit longer than we had hoped, but we successfully interpreted a BMP file. We worked to improve our code, while people wrote to us to tell us how ignorant we are. Fun all around.

Input from a few readers, and our initial estimates for the shooting project.

While we wait for the estimates to come rolling in, and before I forget, here's a report on our work so far on the Shot Pattern Analysis program.

Estimation, simplicity, TDD, tracking. Chet and Ron undertake a project a bit larger than their usual run, to see what happens.

The Frame object in our Haskell-inspired Java program has an awkward interface. Let's take a look at it and see what can be done.

Let's proceed with making the Haskell-inspired Java version "better", focusing on writing tests for a new Frame object. The code gets odd, but turns out better after a while ...

The Haskell experiment we did at the Simple Design and Testing conference has led to some questions and some answers. I'd like to discuss some of them here, and start in a slightly different direction based on the learning.

The continuing saga of recursive implementations of Bowling, email from our fans, and a refactoring of my Java code.

Lots of fine feedback on the Haskell article. Alternative implementations in Java, Ruby, and even Haskell! Much fun! PLUS!! FATAL FLAW DISCOVERED IN RECURSIVE VERSIONS!!

At the Simple Design and Testing conference, Dan Mead bravely agreed to implement the infamous Bowling Game exercise, TDD style, in Haskell. It was fun and interesting. Here I present some discussion, his program, and a Java program in a similar style.

During our Agile Experience session with a client a couple of weeks ago, Chet and I were helping them with FitNesse for .NET. We thought it would be interesting to get FitNesse working with Ruby, so we've begun to work on that. Here, the results of that trial ... Now! With new explanations and graphics! See the end of the article.

On a few of the Agile lists, Paul Arrowood asked: "How does Agile address a conventional Risk Log? I wouldn't call these 'blocked items' (aka issues). But more or less the [Scrum Master's?] watch list for things that could go awry (content not fabricated, new/unfamiliar technology, geographically dispersed team, interdependence with another project, etc)." I wrote an answer, and liked it well enough to put it here.

It is my pleasure to offer the Agile community a new resource, an Agile Forum. I'm hoping it will be a brand-neutral, consultant-neutral place, open to and shared by everyone who is interested in advancing him- or herself in Agile, or in bringing Agile to the world. I'm inviting you to help make it a place you'd like to be.

The code is beginning to ask for some help. We're processing a simple array of cells instead of an object, and the classes don't feel cohesive. Let's push some methods off to new classes and see what happens.

I've read a bit more about Sudoku, and even played part of a game. Plus, the ideas of others in the lists and in email have me thinking. Should I try some of these ideas ... or not? UPDATED: My strategy conclusion is wrong!

A little more explanation of what I'm up to, and a test of a method that actually figures out what could go in a cell. Whee!

A number of people on the tdd list have reported having a lot of fun TDD programming the game of Sudoku. I've not played the game, though of course I've tripped over the piles of books in the bookstores and at the airport. But discussion of the thing makes it sound like it might be fun to TDD on it, as people are saying. Let's get started.

The program reached an impossible state during the first test of the algorithm that I turned loose. I thought I had made a mistake, but it turned out I had not. Well, not a coding mistake.

A comment from Alan Shalloway, on the Lean Development group, points the way to fame and fortune!

Sure, test automation is a good thing. But we can't, and shouldn't, automate them all. Why then, ask people to "automate all tests"?

June Kim posted a J Language version of bowling that is very vector-oriented. As an experiment, I coded up a vector-style version in Ruby, TDD of course. It turned out to be kind of interesting.

An allegory? Sarcasm? Humorous pastiche? You decide.

Justin Gehtland, Ben Galbraith, and Dion Almaer bring us a valuable and enjoyable book describing Ajax. It is full of running examples, points out the major gotchas, and it's a good read too! Recommended!

Between the new book review page and a few other things, I just spent a few days in a painful, test-free update of my web site scripts. Here, a report on how much it hurt. Lessons learned? We'll have to see what I do. Like lots of folks I know, I haven't figured out how to do what I know I should.

Scott and Pramod have done an excellent job with this book. It's full of practical advice about how to improve your database design, when to do it, and even how to manage the transitions. If your project involves a database, this book can help.

More features will always bring more revenue, more customer satisfaction, other good things. Therefore there is always pressure for people to work harder, longer hours. This is demonstrably a Bad Idea. Here's some evidence, and some ideas about how to know if pressure is too high.

On the agile-testing group, there has been a little discussion about offshore testing. Herewith, some thoughts, cleaned up slightly from my comments there.

I was glancing at the delegates version of the code last night, and I have the impression that the frame status requirement will be more readily implemented there. So today we give that a try. The results are strikingly better than yesterday's!

Today we set out to finish the essentials of the FrameStatus implementation for the Kicker version of the Bowling Game. Things go in easily, without many surprises. But we have a lot of code, and it doesn't all feel good.

We have a very procedural implementation of the bowling game, and a very nifty OO version with classes representing states of a state machine. Which implementation is more responsive to new requirements? We'll find out soon!

We use the C# "delegate" feature to come up with a solution to the Bowling problem that is perhaps a bit less OO, but is also only 40 percent the size of the version with the Kicker classes. Fun exercise, but the proof will be in the next stories. [updated, see footnote]

I wrote this answer in response to a question on one of the Yahoo groups: "What is the list of documents produced when you are implementing a pure Agile project?" Martine Devos liked it, so I decided to preserve it here in hopes that someone else might like it as well.

We build some superclasses to remove the duplication from the Kicker classes. One false start sends us down an unpleasant path, and we decide to start over more cleverly. As for the end result, we have our doubts. The proof will be in the updating, later on. Right now, it's hard to see why five times bigger is better, just because it looks like Object-Oriented.

Chet and I get this version running all the way, by implementing the Strike functionality. We do some cleanup, and plan next steps. We can get a pretty good look at the OO-style version of bowling. Is it better? It's not clear.

In which our heros find a straightforward way to replace conditional logic in the Frame with series of Kicker objects. The design so far is quite "object oriented", and is turning out as was envisioned. But is it better? That remains to be seen.

Using a pinball "kicker" metaphor, Chet and I are going to try a version of the Bowling Game. We'll talk about the metaphor a bit, and then check our intuition that it will work out well.

A TDD demonstration of the Bowling Game suggested that there is material there worth mining. Let's start digging.

Recently on the Scrum list, I characterized the practice of having designated "QA" people on the team as a "second- or third-class practice." Here's some expansion on that ...

A poster to the CrystalClear list offered a classification of Agile methods, triggering these brief thoughts about integrating the ideas rather than dividing them.

The ScopeTransform experiment was a good one, but I think that scope transformation should be part of XSet, not a separate operation. We'll work on that ... and it turns out pretty nicely. More to do, of course, and things are a bit fuzzy, but I think we're on a good path.

Our previous work left me thinking about whether there would be lots of redundant Scope Transform bytes needed in all the records. I chatted with Chet about it, and thought about it a bit more, and I think we're OK. This article will bring you up to date on the thinking. No new code, but I will include the complete listings as of now just to keep you up to speed.

We're walking a narrow path bounded by theory and practice. This time we'll do some work on those records with holes in them, like the first-name set. In so doing, we'll try not just to hack in the code, but to keep it consistent with our understanding of the math. We don't really understand the requirements, or the theory. Can we possibly succeed?

We'll push forward with Scope Transformation ideas. First step will be to make the :restrict operation return a ScopeTransform set. That part will be easy. Then we start thinking about just what that :contents method means. Still, good progress for a little time in an airplane.

We need to look around a bit, to decide where to take this project. To do so, we need to get a bit more clarity on the big picture, and the small one.

Some cleanup efforts lead us to a theoretical idea, and to a successful spike. Out of chaos, order.

There's this hack where we return the elements of a set as if they were sets. Nothing like theory to fix a hack, is there? Naturally there are some stumbles along the way, mostly involving the tests. Remember who you're dealing with.

I did an offline experiment to figure out what to do about this :each thing that returns two items instead of the usual one. Based on that, we'll create a new little object, wire it in, then clean up the tests a bit. Join us ...

Just for a little something to do, let's add iteration capability to our XSets. [Added: Clarification of something that threw at least one reader off.]

A small experiment, implementing "restrict" in Ruby. As usual, warts and all.

Some friendly folks have been making suggestions and asking questions. I'm still in the mode of figuring out what to do and how to do it. For those who are interested ...

For some reason, I'm thinking -- at 2 AM -- about Extended Set Theory. An interesting topic, to me, even at this hour. But should I build something? I don't know; help me out.

It seems like every development project begins with the date, and we're held responsible for "making the date". Making the date is a management responsibility, not a development responsibility. Here's why.

Delivery of the running, tested, features the customer wants is the purpose of the development team. Sometimes the work we signed up for won't quite fit into the iteration. What should we do?

Chet and I got together at Borders in Brighton yesterday, and talked about teams going "off the road" and what a process should do to address this concern. We recorded the chat and have put it up as a sort of podcast. We hope you enjoy it, and request your help.

There's a recent thread on the Scrum list about how an executive or highly-placed manager could get Agile going. I've been one of those guys, and I know a bit about Agile, and here's how I'd proceed. First, focus management attention on cyclic delivery of running tested software. Second, provide the resources to learn how to do that.

Ron and I have been doing some Smalltalk lately. He has been writing about coding the bowling game as an exercise to help get our chops back, so I thought I should do something to help us catch up with the current state of Smalltalk development.

To really take an important role in practice, ideas need to get built into people's heads. Since most practitioners don't read much, they get most of their ideas from people they talk to, things they can read quickly, and most of all, from ... practice.

Our mission, should we choose to accept it, is to "spike" a map drawing program. We know nothing about maps or drawing, and very little about programming. How might we proceed?

Harald Mueller and I have been having a little mailing list debate about documentation. I've been taking the position that we want understanding, not documents. He's been saying that documents are one good way to get understanding. So far, we haven't gotten on the "same page" yet, but I trust that we will if we keep going. In the light of that conversation, though, here are some thoughts on documenting this little product we're working on.

These questions were recently asked on the XP group, in the context of a review of Mike Cohn's User Stories Applied. The answers are a function of the whole project, not just User Stories.

Based on a suggestion, I'm going to build the BowlingGame in yet another way: based on a Stream concept. This will be more fun for me than what I should be doing: I hope it's the same for you.

A famous author also refreshing his Smalltalk proposes a single method solution. Going where no man dares to tread, I'm going to try to refactor it into the style I consider to be "good". You decide.

Some discussion of style triggered by reader input. Then on to another "improvement", followed by discussion of whether it's an improvement, and why we did it.

I had this cool idea for another way for Bowling to work. I'm snowed in, so I tried it. The results were good ... and very thought-provoking.

Let's try some more incremental improvement to the objects. Meanwhile, some people think I'm taking bites that are too big. Let's think about that as well.

Let's reflect a bit on the Smalltalk bowling experiment so far. And then ... I've got an idea!

In the previous article, we made our first test run, and sketched a bit about how Smalltalk helps us. Let's make some more tests run.

After a long time away, I had occasion to start using Smalltalk again. To get my chops back, I started with the Bowling Game exercise. My experience quickly reminded me why Smalltalk rocks. (Updated: includes changes and remarks about "==" vs "=".)

To paraphrase Red Green, if the audience doesn't find you informative, they should at least find you entertaining. Chet and I addressed the XP West Michigan group recently, and here's an article from the Grand Rapids Business Journal that resulted.

It's time to revisit the topic of Big Visible Charts. Display important project information not in some formal way, not on the web, not in PowerPoint, but in charts on the wall that no one can miss. [Updated: Velocity Charts]

Brian Marick, in a blog entry that is quite interesting on its own, points to a very provocative article about group think, German philosophy, and the old Saturday Night Live gang. It got me thinking about Extreme Programming and the "Agile" methods. Have I mentioned passion lately?

I was wondering what would happen if I injected a Frame object into the bowling example, early on. What happened is that I got in a bit over my head. Come along and point and laugh.

It's important to take grammar seriously, even if she has been dead for years.

To every Card, turn turn turn, there is a season, turn turn turn, and a time for every Suit under heaven. It's not the Suits, it's the Game.

We need a test. We discuss why we work that way, then we write the test and make it run. In so doing, we learn something very important: maybe we don't want ArticleList to be a typed collection after all!

Programming can't be successful without design. But I begin my projects with very little design and seem never to do any. On the contrary, I'm designing all the time. That's what makes incremental delivery possible.

Inspired by an example from Jonathan Pierce, I typed in a walkthrough of the .NET CollectionBase, a base class used for building typed collections. Chet and I talked about it at Borders today, and it inspired us to look at the ArticleList in the blog software. We tweaked it to make it more like a typed collection, and it's definitely better.

In which we set out to drain the swamp, encounter some alligators, and quite possibly add a little water to the swamp in the process.

I've got a little time here, and there are those tests set to Ignore. Let's fix them so we don't have to ignore them.

Inch by inch, step by step, we work on improving the internals of the ArticleFiler. No master plan, no grand design. Just gently polishing until the object is visibly better. A good way to proceed? You decide.

When I'm programming, I work very incrementally, almost intentionally with no grand plan other than my stories. I pay attention to the design, but I'm not working toward a planned design. When the code starts pushing back, I make it better. This feels to me like a course of discovery rather than bringing about some carefully thought out transformation.

This book includes some really excellent examples of pair programming sessions with XP superstars such as Chet Hendrickson and Paul Friedman. Author Ron Jeffries has chosen some great partners. It's too bad they couldn't be with him more often. (New note inside review.)

Nearly every metric can be perverted, since up- and down-ticks in the metric can come from good or bad causes. Teams driven by metrics often game the metrics rather than deliver useful software. Ask the team to deliver and measure Running Tested Features, week in and week out, over the course of the entire project. Keeping this single metric looking good demands that a team become both agile and productive.

The irony of Extreme Programming is that while detractors continue to explain why it cannot work, software developers all over the world are having success with it.

Bill Bryson writes a delicious book that lives up to its title. The cosmos, the earth, atoms, geology, life, homo sapiens -- it's all here.

And thirdly, the Code is more what you'd call guidelines than actual rules. -- Captain Barbossa (Pirates of the Caribbean)

I can put off anything except procrastination. When I make a "ToDo" list, a card is too small and they get all bent and dirty before everything is done. Wait! I'm an XP guy. I'm trying separate "ToDo Story Cards" to see what happens.

This isn't just one of those self-improvement books. It asks us to dig deeply into our own feelings about people and situations. Reading this with an open mind will ask some hard questions that need answers.

This book is painful to read for anyone who understands what XP is, because it goes to such pains not to understand, to take out of context, and to distort. It is dangerous to read for anyone who does not understand what XP is, because it goes to such pains not to understand, to take out of context, and to distort.

Beta testing is a common final check on system content and accuracy. When feature or defect problems come back from beta testing, that's bad news, and we might have to freeze the code. Therefore, treat beta testing as "business as usual". Plan to have no problems come back.

Barry Boehm and Richard Turner have produced an important and balanced book about agile versus plan-driven methods. Unfortunate title, perhaps, and a few things to disagree with, but highly recommended.

With the best of will and effort, sometimes things still go wrong. When that happens, the way we deal with the problem can make the difference between an unhappy customer and one who is actually happier than he was before the problem happened. This letter tells about such a time.

The YAGNI principle says that we should not build any code that we do not currently need. But some parts of our systems benefit from being built from data rather than from code. Therefore if we follow YAGNI we could never build such code. But wait? What about the rules of simplicity?

I'm been struggling for years with notions like having empathy with our mistakes, Kerth's Prime Directive, and the like. Springing from a couple of notes on the extremeprogramming group, and a blog entry from Dale Emery, here's my latest rant.

Frank Gannon wrote this column for New Yorker, if I'm not mistaken, back in 1987. I think it deserves another run. I wrote a year ago for permission to publish, but so far cannot find the copyright owner. It's about flowers and gardens, so perhaps it's appropriate for this Valentine's Day. (Frank found this page somehow and has kindly granted his permission to post the article, which appeared in Atlantic, not New Yorker. Thanks, Frank!)

The Logitech io Personal Digital Pen remembers what you write or draw and then uploads it to your computer when next you plug it in. It must be good for something. How does it work? The paper has coordinates built in!

Jeff, an experienced XP coach, takes a hard look at Pete McBreen's book, and finds it to contain good questions. He feels that the answers fall short -- perhaps due to Pete's inexperience with XP.

Wyatt provides a detailed, exciting, and valuable diary of a project moving towards Extreme Programming. Highly Recommended.

The authors show us how they use aspect-oriented programming in AspectJ to facilitate isolation of testable units, without hand-crafting Mock Objects or using a specialized Mock Object generation tool.

We're often afraid that if we don't do enough design up front, our program may bog down and become hard to maintain. This will cause expensive rework, or worse, project cancellation. Simple design with refactoring isn't rework. You may proceed without fear.

Some of the XP practices may be things we want to do all the time. Some we may wish to do only part of the time. When we are really skilled in use of a technique, we're best equipped to decide when to use it. Here are some exercises that may help build skill. And make up your own exercises. Let us know about how they work. Added: Planning Etudes.

Using a simple deck of cards, examine how Extreme Programming gives you a new and better way of managing software.

All too often, they change the priorities and our project gets cancelled, or put on "hold", before it's done. This is frustrating, demoralizing, and wasteful of resources. Ship it before they can stop you! This maximizes the value of your work, and reduces stomach acid, all at the same time.

When you're in a group that serves many customers, your backlog list tends to become infinitely long. You're not sure whether to report on things that aren't being done, or to pretend they are being done, or what. Don't keep a backlog list at all. The result could be greater clarity for your customers, and far less hassle for you.

I was recently invited to write a new introduction to the Korean edition of Extreme Programming Installed. What a rush! International fame and glory. Thanks to Ann and Chet for making it possible. Here's what I wrote

A recent discussion on the Extreme Programming mailing list addressed whether there is an "80-20" rule in software development. Let's take a look at some numbers.

Feedback helps a developer know he needs "something". No process will help us notice that mathematical proof is needed if we have never heard of mathematical proof. Some processes choose to list all possible techniques. XP does not.

SonicBlue (Rio) has built a device I've been wanting for years. It eats your CDs and plays them back digitally: 40gig worth of them! Here's an early review of my experience with this new toy. Update: It has a bit of XP in it!

I have no excuse for this material. It just came out of my pen. And Wyatt Sutherland's.

On the "Agile Testing" mailing list, Michael Bolton asked for an example of XP-style testing and programming. This example was the result. It represents about 90 minutes of work, counting two phone calls and doing the original writeup.

It is said that by meditating on the words and actions of the masters, we may be enlightened. Sometimes it's just entertaining.

If you are serious about your profession, if you are serious about teamwork, if you are serious about success, please read this book.

Updated to include our first review of Java Tools for eXtreme Programming. These books are all about agile software development, even those written before the term existed. They're all worth having and reading, more than once. Dig in!

Chet and Ron have been working with Ruby, because it's the nearest thing there is to Smalltalk. Here are the books we use.

Chet looks at some humor and some ancient architecture. We leave it to you to figure out which is which.

A detective in puce, mentoring, massive parallel processing, and two books on writing. What more could you want?

Sean Shubin has begun using Test-First development. He wanted to share these ideas and guidelines with us.

Maybe it's just the name: Extreme Programming. Maybe it's something we said. Whatever the cause, there are lots of misconceptions about XP. From time to time we'll try to correct some of them here.

Fear is good if there's a tiger in the room. Not so good if there's a bug in the software.

This is the first of a regular series of book reviews. We'll only review books we have read, and we'll call them the way we see them. This time we look at five books, ranging from XSLT to the world of Dream. Updated to add a sixth on time management

People work together to get what they want. One thing that everyone wants in one form or another is knowledge. How can we share knowledge about XP?

Bryan Dollery reports on an interesting conversation between Achilles and the Tortoise. This one is about design, or the lack of it, in XP. Thanks, Bryan

Ellen Ferlazzo, of Sprezzatura Systems, took my rant on documentation seriously. Ellen says that if you do it right, you can deliver the documentation at the same time as the software. I was willing to give the writers an extra iteration. Rock on, Ellen!

In this review, Extreme Programming Installed, Planning Extreme Programming, Extreme Programming Explained, The Humane Interface, and Adaptive Software Development.

"Outside of a dog, a book is man's best friend. Inside of a dog, it's too dark to read." --Groucho Marx Outside your extreme programming project, you will probably need documentation: by all means, write it. Inside your project, there is so much verbal communication that you may need very little else.Trust yourselves to know the difference.

Here's a bit of a rant I wrote some time back, talking about how to write the manuals for an XP project by using writers as part of the team. It's a serious proposal, written with tongue a bit in cheek.

One of the most common raps against XP isn't even true. People think we say that documentation is a bad idea. XP is focused on conversation for maximum effectiveness. Our recommendations on documentation follow from that simple fact.

Test everything; eliminate duplication; express all ideas; minimize entities:These few simple rules, applied locally, can help a high quality global design to emerge.

One of the most common failings of XP teams is insufficient testing. XP asks for more testing than many teams are used to. But what about projects that need reliability at a substantially higher level? Are they out of luck?

Kent Beck has described XP as designed to go with people's natural instincts. In this short series of articles, we'll take a look at how XP accomplishes goals without a need for lots of discipline or management pressure. In this article, the topic is documentation.

XP seems to be made up of a lot of practices. They might be good, but what's the bottom line for a business person? The acid test for XP isn't what the team does, but what they deliver. Here's what you should get from your XP team.

Pair programming might be useful between peers. But it seems like an inefficient use of a "senior" person's time to be tied down to a "junior" person. Experience shows that pairing almost always pays off for both parties. However, not all readers are convinced: how about you?

People ask whether they have to do the XP practices to be doing XP. In some environments, some of the practices are difficult or impossible. You don't have to do the practices to be doing XP: You have to have done them. Practice makes perfect.

The XP Circle of Life helps keep projects alive. A key aspect of this cycle is the Acceptance Test. Acceptance Tests are critical to communication among team members, especially between customer and programmer.

When unexpected defects arise, it can take a long time to isolate the problem. This can have large and unpredictable impact on the team's progress. Extreme teams release software frequently, keeping their unit tests at 100 percent. The result is smoother progress toward completion, fewer unhappy surprises, and continuing improvement in quality.

A pre-introduction to XP from the perspective of the average corporate developer.

Let's try to get a sense of what is good process and what is not, without a lot of rigmarole about the specific practices.

An XP approach may deliver more value throughout the entire project.

Building a C++ Dependency Analyzer Test-First.

Here's the C3 programming space!

Bill discusses the benefits of test first programming in an instrumented C++ telecommunications application.

Experiments with XP in a difficult environment.

Growing an application one test at a time. From a Series.

Alistair says that XP does not flatten the exponential cost of change curve.

Business analysts should work as aides to the customer, not as an interface between customer and programmer

Building a C++ Dependency Analyzer Test-First.

Houses aren't software. You can build software incrementally.

We build a simple alarm clock object, applying the XP rules of simplicity, just to see how it will turn out.

How do XP and CMM relate?

Let's get some data about XP!

Repeated estimation and tracking results in improved ability to estimate.

Modeling the cost and return of anticipation shows that it may not be as valuable as we think.

The overly complex cards once tried on C3. Don't try these at home.

Questions about how and when to do some XP practices.

An introduction to some of the key XP practices

A somewhat hokey tale about the XP variables, Resources,Scope, Quality, Time.

How can we approach a project with a very limited analysis phase.

"Of all the words of tongue or pen, the saddest are these .. it might have been."

The STQE link provides access to Ron Jeffries' less famous article in that magazine.

They're not XP's rules, they're the team's rules.

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.

Simplicity + Communication + Testing = Aggressiveness

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.

Here are a few of the key code formatting patterns we use. The names and some of the examples are from Kent’s book.

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.

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.

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.

We all code to the exact same standards. We name our classes and methods the same way, we format code the same way.

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.

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.

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.