Red Squirrel Reflections Dave Hoover explores the psychology of software development

Will I ever stop blogging about Steve McConnell? What can I say, I'm becoming a fan. Though I don't agree with a few of his ideas about software development, there is a lot that I do agree with. There is a lot of wisdom in his books. I enjoyed this sidebar (Rapid Development, 173) so much on the train this morning, I felt compelled to transcribe it here...

"Accuracy" and "precision" are related but not identical concepts, and the difference between the two is important to software estimation. Accuracy refers to how close to the mark a measurement is: 3 is a more accurate representation of pi than 4 is. ... Precision refers to how many significant digits a measurement has: 3.14 is a more precise representation of pi than 3 is.

A measurement can be precise without being accurate, and it can be accurate without being precise. 3 is an accurate representation of pi, but it is not precise. 3.3232 is a precise representation of pi, but it is not accurate. Airline schedules are usually precise to the minute, but they are not very accurate. Measuring people's heights in whole feet might be accurate, but it would not be precise.

In software estimation, false precision is the enemy of accuracy. An effort estimate of 40 to 70 man-months might be both the most accurate and the most precise estimate you can make. If you simplify it to 55 man-months, that's like representing pi as 3.3232 instead of 3. It looks more precise, but it's really less accurate.

Shortest-possible software schedules are achieved by creating the most accurate estimates possible, not the most precise. If you want to achieve maximum development speed, avoid false precision.

Posted by Dave [Link]

I recently finished reading Steve McConnell's excellent Code Complete and found that a lot of his thinking supports Extreme Programming. I am now in the thick of his subsequent book, Rapid Development, and I'm again finding an overlap with XP. I highly recommend Steve's books to anyone who is serious about software development.

Yet, there is one piece of Steve's writing that I find myself continually questioning. In both of his books, Steve relates software development to building a house:

"Just as it makes sense to create a set of blueprints before you begin building a house, it makes sense to create an architecture and design before you begin building a software system." (Rapid Development, 62)

While there is certainly some insight that can be gained from this metaphor, I think it could potentially do more harm than good. By relating software development to the construction of rigid, stationary, real-world objects, aren't we sealing our own fate? Won't this metaphor lead us into developing software that is difficult to change? I'm not sure...Ken and Roy think it might:

"When you use a process meant for building inflexible things like bridges to build flexible things like software, it shouldn't shock you that later change costs more." (Extreme Programming Applied, xl)

On the other hand, maybe we simply need to learn more about construction in the real world. Mary Poppendieck attended a course in construction planning at the Lean Construction Institute. When she was asked by her classmates why she, a software consultant, was in a classroom full of construction foremen, superintendents, and project managers, she told them:

"'In software development, we are told we should manage our projects like construction projects, where a building is designed at the start, cost and schedule are predictable, and customers get what they expect.'

Silence. 'You’re kidding, right?'  'No, honest, that’s what we’re told.'

Incredulity turns to laughter.  The idea that programmers would want to manage projects like the construction industry strikes my classmates as ludicrous."

Mary's article goes on to describe how both software development and building construction can be informed by the methods of Lean Construction. This reminds me of something that Steve wrote in Code Complete:

"By comparing a topic you understand poorly to something similar you understand better, you can come up with insights that result in a better understanding of the less-familiar topic." (7)

I don't know the first thing about building a house, so a metaphor that compares house building with software development is not going to provide me with many insights. As an ex-football player, though, I found this huddle metaphor useful. What past experiences in your life can serve as metaphors for the intellectual challenges you are facing today?

Update: Steve points out a limitation to the house-building metaphor on page 172 of Rapid Development..."Unlike building a home, in software the only way to refine the product concept...is to actually build the software."

Posted by Dave [Link]

"Even if an error at first appears not to be your fault, it's strongly in your interest to assume it is. That assumption helps you debug: It's hard enough to find an error in your code when you're looking for it; it's even harder when you've assumed your code is error free." --Code Complete, p. 628, Steve McConnell

Over the last 24 hours I internalized this idea, hopefully once and for all. One of our web applications was experiencing some very odd and hard to reproduce errors. These errors were just brought to our attention yesterday, though it is thought that they have been happening for the last few months, quite possibly driving traffic (and revenue) away from our site.

The errors only happened after user authentication, and only for a specific category of user. Furthermore, the errors were only happening on one application, though it used the same authentication module as other applications. The frequency of the errors increased during periods of higher network traffic.

My first reaction yesterday afternoon was to blame it on memory and network issues, and was at a total loss about how any application-specific code could be causing this. The problem was particularly difficult to diagnose because of the vague and misleading messages that were written to the log.

While the network and system administrators were checking and re-checking their pieces of the pie, I was drawing a blank. As I walked home, though, I reminded myself of the above quote from Code Complete, and decided that I must begin assuming that the problem was my fault.

Arriving to work this morning, my newfound assumption led me to review the various logical paths of authentication. I started walking through the Java code, transcribing the logical paths into plain English in a spreadsheet. I didn't find anything.

Then I looked to see if any of the authentication module's classes had been extended in the troublesome application. It turned out that one of the classes had indeed been extended. And wouldn't you know it, I was the last person to check that class into version control. I took a look at the class, diff'ing it with the previous version to see what I had done. I had made some modifications to it, and had cleaned up a particularly nasty looking method.

I took another look at that method. I took another look at the older, nasty version. Although my code was nicely indented with English variable names, I had inadvertantly changed the method's logic. I had committed a foolish, foolish mistake. I had refactored without tests.

So the problem did turn out to be my fault. I can't imagine how much longer it would have taken to diagnose if I had assumed otherwise.

Posted by Dave [Link]

I'm still reading Code Complete and finding innumerable precursors and foundations to most of the XP practices. The book quoted Jerry Weinberg yet again (page 747), and it made me think of test-driven development (yet again)...

"Opening up a working system is more like opening up a human brain and replacing a nerve than opening up a sink and replacing a washer. Would maintenance be easier if it was called 'Software Brain Surgery?'"

Jerry's metaphor immediately made me think that keeping the patient conscious during brain surgery is like maintaining an automated suite of unit tests and running it repeatedly during refactoring. Like physicians, software developers' working with existing code must strive first and foremost to do no harm.

Posted by Dave [Link]

Once again, I started posting a blog entry and it evolved into an article. This one ties together reality television, social constructionism, and project retrospectives.

Posted by Dave [Link]

[Archive Index] [Main Index]

Powered by Greymatter