Session 27

Pragmatic Debugging


810:188
Agile Software Development


Agile Moments

Taking Versioning to the Mainstream

Martin Fowler suggests that version control a lá source code control is an idea with potential to help non-developers.

Other than software developers, few computer users use version control. Yet as software developers know, version control is a great mechanism for collaborative work, allowing multiple people to work together on a single software system. ...

We've reached a point where it's practical for everyone to use version control systems in their work. Subversion is a freely available system that supports binary formats easily and removes many of the limitations of CVS. Disk space is cheap enough that you can put people's entire working directory under version control.

(Sadly, too few software developers use automated version control...)

Martin has a great idea here. Many software developers-turned-book authors have used version control tools as a way to collaborate on their books: text, code, images, the whole bit. The technology is well-developed; developers of software for end users just need to think about building version control into their software. Can you imagine Microsoft Word or your favorite word processing software having version management and branching built right in to it?

(Version control would have to be built in in a native way. Non-programmers don't want to think about the details, and I think that our experience with CVS reminds us that the user interface to CVS is still way too Unix-y!)

Keep this idea in mind when you are a software developer and are looking for a way to make your software different and better...

A Pithy Quote from a Master

Yesterday, someone reminded me of my friend Rich Pattis's Quotations for Learning Programming. I jumped randomly to the Os and had not scanned too far down the page when I saw this quote:

As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications.

- D. Parnas

Parnas is a famous computer scientist, well known for his work on modularity and software design. Many give him credit for best explaining encapsulation as a design technique. He is revered as an icon of traditional software engineering.

Yet, when I read this quote, I could help but think, "Parnas may be a closet agile developer." (I do this occasionally... See my discussion of Dijkstra as a test-driven developer. :-)

Whether Parnas is sympathetic to the methodological side of agile software development, this quote points out an essential truth of software development that is central to agile approaches. Software tends to work properly only after failing for a while. One of the ideas underlying agile approaches is to get to working software sooner. The primary motive for this is so that developers can learn from the code. But perhaps a secondary value is it can begin to fail sooner -- but in the lab, under test-driven conditions, where developers can learn from the failures and begin to fix them sooner.

More Subconsciously Agile Quotes?

As I scanned Rich's list in this agile state mind of mind, a few others caught my eye...

Blaise Pascal, the first refactorer?

I have made this letter longer than usual, only because I have not had the time to make it shorter.

- Blaise Pascal

A cautionary tale about agile methods -- but also about traditional software engineering?

Ready, fire, aim (the fast approach to software development).
Ready, aim, aim, aim, aim ... (the slow approach to software development).

- Anonymous

Maybe those guys in Redmond know something...

Microsoft, where quality is job 1.1

- Anonymous

And this quote has long been a favorite of mine, and I have it hanging on the wall in my home office:

We are what we repeatedly do.
Excellence, then, is not an act, but a habit.

- Aristotle

This quote isn't agile so much as pragmatic, the hallmark of a professional. It's also a good guide for life in general.

One of the useful thing about reading quotes of this sort, the clichés of our discipline, is how they sometimes oversimplify the world. As a result, you will almost always encounter contradictions in cliches. For example, I can surely find a Parnas quote that could easily be interpreted as condemning agile software methodologies (in particular, I'm guessing, their emphasis on not doing big design up front). I don't worry about such contradictions; I prefer to use them as learning opportunities. When you see such a quote, take a moment to think... Under what conditions can this be right? When does it fail? What can I learn from this idea that will make me a better programmer or developer?


Quick Activity: Your Thorniest Bug

Take one minute to jot down a sentence or two about your thorniest bug, the one that had you banging your head on the wall, the one that had you talking to yourself on the street, the one that made you question your belief in God and all that is good.

Then share your bug with a classmate, even if its ultimate simplicity embarrasses you now.


Pragmatic Debugging

At the source of every error which is blamed on the computer, you will find at least two human errors,
one of which is the error of blaming it on the computer.

Debugging is a psychological challenge. It requires different skills from programming itself. But, as with skills, we can learn to do it better. ...

Some lessons on debugging from Andy and Dave (local mirror):

(Actually, this article is about working with large legacy systems. It is based on a metaphor to archaeology. See the 2001 OOPSLA workshop on Software Archeology: Understanding Large Systems.)


Quick Activity: Your Bestest Debugging Strategy

Debugging is anticipated with distaste,
performed with reluctance,
and bragged about forever.

Take one minute to jot down a sentence or two about your favorite debugging strategy, the one that knocks down walls, the one that restores your sanity, the one that made you restores your belief in God and all that is good.

Then share your strategy with a classmate, and learn from his or hers.


Learning from Experience

... design patterns, bug patterns ...

... FindBugs, a bug pattern detector for Java

An example: The "Just What I Need (Almost)" Bug (local mirror)

Look for patterns in your experience. Share them with one another. Categorize, generalize, specialize, learn from them. They folks who write Design Patterns or debugging patterns aren't necessarily smarter than the rest of us; they are just reflective enough to try to learn from their experience, codify it, and share it with others...


A Final Story about Debugging

Another anonymous story seen on Rich Pattis's quotes page.

The huge printing presses of a major Chicago newspaper began to malfunction on the Saturday before Christmas, putting all the revenue for advertising that was to appear in the Sunday paper in jeopardy. None of the technicians could track down the problem. Finally, the manager made a frantic call to a retired printer who had worked with these presses for over 40 years. "We'll pay anything; just come in and fix them," he was told.

When he arrived, he walked around for a few minutes, surveying the presses. Then he approached one of the control panel and opened it. He removed a dime from his pocket, turned a screw 1/4 of a turn, and said, "The presses will now work correctly." After the manager thanked the old printer profusely, he told him to submit a bill for his work.

The bill arrived a few days later, for $10,000.00! Not wanting to pay such a huge amount for so little work, the manager told the old printer to please itemize his charges, with the hope that he would reduce the amount once he had to identify how little he had done. The revised bill arrived: $1.00 for turning the screw; $9,999.00 for knowing which screw to turn.

The moral of the story: Most bugs are easy to fix. Figuring out where the bug is is hard.

Which gives me another agile moment -- link to follow.


A Final Quote

I couldn't resist:

Good teaching is more a giving of the right questions than a giving of the right answers.

- J. Albers

I ask a lot of questions...


Wrap Up


Eugene Wallingford ==== wallingf@cs.uni.edu ==== December 7, 2004