Category: Classics

Here are just a few of the unsolicited favorable comments I've received about 'The Nature of Software Development'. Some drawings included.

This morning, rather than toil over the scattered bodies of evil but admittedly cute space invaders, I'm minded to talk about privilege.

When I was blurting about the Increment as the most important thing, just the other day, GeePaw Hill mused about collaboration as the most important thing. Today, I'll muse on that and his notion of makers-making-made.

There's a lot of whinging going on about imposing 'Agile' methods and practices. These whiners just don't know how to do imposition correctly. Me either, but here's what I'd try.

Based on our Scrum Gathering 2017 talk, we discuss the impact on real software development of growing focus on the 'enterprise'.

Scrum is good, when done as intended. Otherwise it can be oppressive and dangerous to developers. Let's study: Defense Against the Dark Arts of Scrum.

Privilege. No privilege. Screw it, improve your situation. Or don't. It's up to you.

Actions have consequences. It may be best to be OK with that.

This is an NSFW rant regarding the whiny, mewling *bastards* who bitch, whine, and complain about Agile methods, Scrum, and similar topics.

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

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

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!

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

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

Code that slows us down is bad design.

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.

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

An allegory? Sarcasm? Humorous pastiche? You decide.

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.

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?

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.

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.

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]

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.

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 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?

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!)

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

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.

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

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.

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

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

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!

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.

"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.

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

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.

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.

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

Here's the C3 programming space!

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

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

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