Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

heusserm (4461)

  (email not shown publicly)
AOL IM: MatthewHeusser (Add Buddy, Send Message)

Matt Heusser is JAPH and an XP-Er []. (The Methodology, not the Operating System.) Right now, he's doing a lot of Test Driven Development in Perl.

Journal of heusserm (4461)

Tuesday September 20, 2005
12:40 AM

Agile Project Management

I'm reading APM, the new Highsmith book. I really stuggled with this book - Highsmith spends the first hundred pages or so hitting us over the head with the concept of agility. Blah blah blah, the factory analogy doesn't work, blah blah blah the best products come from self-organized teams, blah blah examples, blah blah more Philosophy I allready agree with.

Then he finally gets to the good stuff. Most of it is recompiling and repacking the existing body of knowledge, but after sixty more pages, I do have a couple of ideas to take home and reconsider.

Overall, I'd say the book is best framed as an introduction to agile methods for people only familiar with old-school PMI/Waterfall projects. The intended audience for this book actually _do_ need a gentle introduction. That just makes me ... very sad.
12:39 AM


I just read the two articles by Brian Marick on Emerson, Methodologies and Ontology. Really Interesting Stuff, but it was dense. It deserves a second and third read. Marick points to Kent Beck, who wrote that, essentially, when the code is trying to tell you what to do, try to follow it. According to Marick, developers are in a dance of agency with the software we write, as the software emerges. (You can read it for yourself, it's good stuff: this and this)

Now, I used to be a huge Issac Asimov Fan, and I remember one essay where he talked about how his characters essentially 'take over' the story. One moment, he is directing the stoy, the next, the characters are simply doing what they would do next. That's flow for Asimov, getting to the place where story is writing itself, and he's a kind of passenger. I think this is what Marick means by unreflective actions "actions people take because they are the obvious things to do in

I think Emerson was trying to get at the incredible potential of humanity - I know that Asimov was. I don't see any big disparities between the Emersonian worldview and my own faith - for example, we Catholics believe that creativity is an attribute of God's Character, and thus expressing that attribute is an act that is essentially divine. "Joyous" is about as close as you can get in secular terminology.

Which brings me to why I love what I do. I love it so much that don't want to stop, even on a Sunday at 9:30AM over the rockies. If development is a road race, the "Process Improvement" folks found a single road rut and then created a process which must always be followed, regarless of weather or not your particular road had a rut. In the end, driving around those extra gates and cones can take more time than driving through. The agile folks are focusing on removing the cones and gates that don't make sense; they want the simplest commute that could possibly work.

IMHO, The next step will be a methodology that puts a better engine in the car - and that reads more like mentoring and coaching and skills improvement, combined with a light-weight, description ("how we generally think about problems here") framework over a prescriptive ("do it this way or else") methodology.

What's my point? What we're doing here, all this talk about constant improvement and how to do it better - that _is_ the methodology. Expanding our experiences and knowledge. Sharpening the saw. I'm having a blast. Thanks for being along for the ride.
12:35 AM

BusinessWeek, PeopleWare, Microsoft ...

Joel Spolsky wrote that when he went to the supply cabinet as an intern, there was a large stack of copies of PeopleWare right next to the pens and paper and staplers. The company was Microsoft. Criticize MS for it's monopolistic or anti-competitive or closed-source behavior all you want, they knew how to hire the best and keep them productive.

I picked up BusinessWeek because the cover story was on the brain drain at Microsoft. The article claims that Microsoft is becoming a big company - slow, process-heavy, hard to get anything done. Steve Ballmer recently cut health benefits, cut vacations for new employees, stopped the free towel service at the on-site fitness club, proposed seven-figure salaries to key VP's, mid-Six figure salaries to group managers, and pegged staffer's salaries to the industry average. Also, he had an interview with BusinessWeek where he talked like a press release and didn't answer pointed questions. His answers weren't completely evasive -- at least, not all of the time. I've seen worse, but it was disappointing.

Which tells me that senior brass at Microsoft is now behaving as if they never read PeopleWare. Maybe they never have. Who knows. The article said that Ballmer was trying to transform the company as described in Jim Collins "Good To Great." News Flash: Microsoft _WAS_ great. Collin's previous book was called "Built to last", and MS could have been a case study. So now they are experiencing record profits, sitting on $60 billion in cash, and they cut insurance so employees have a $40 copay.

What the heck am I missing? Seriously - what am I missing? Has the leadership at MS forgotten how to manage software development, or is the article just biased?
Wednesday September 14, 2005
11:59 AM

Potholes PT 2

A snip of the intro to my talk to the Indiana QA Conference on "Magic Pixie Dust: Improving the pace of software delivery through People" is below. I really like the methodology stuff, but it doesn't fit - I may cut everything after "share a few with you." Mostly I wrote it up here to tie it back in with the potholes analogy.

Have you ever been faced with an impossible deadline, where senior management tells you that adding staff, moving the date, decreasing quality, or removing features was "simply unacceptable?" After all, your job is to solve problems, not to whine.

It’s seems as if Senior Management wants you to spread some magic pixie dust and make everything better.

Well, yes, and to some extent, I believe that’s possible. Or, that is to say, there are tradeoffs you can make to improve the pace of development – and I would like to share a few with you.

1st Generation Methodologies were about preventing common mistakes.
The problem was that code reviews took time to organize, and this increased time-to-market and waste.
So our 2nd Generation Methodologies reacted to that to remove waste.
XP puts the customer in the same room, so you never have to wait a week to get an answer when you’re blocked.
XP moves people to more generalist roles, rather than specialists, which decreases handholding, confusion, friction, and points of failure. Pair Programming focuses a group on the task, eliminating a great deal of web browsing and goofing off.

So 2nd Generation Methodologies remove waste. Our theory is that 3rd generation methodologies will improve the pace of development.

How do you do that? Some techniques, like exploratory testing, work to make the practitioner more effective. What I’m going to talk about today are techniques to accelerate innovation within teams, and it’s consequences.
Tuesday September 13, 2005
09:05 PM

Pothole Methodologies

Precursor: I don't like artificially created generations or bogus models. In the post below, I use this first/second/third generation methodology paradigm - mostly because I want to get this post out quickly. It's a contrivance I'm using to describe generalities - please don't think i'm taking myself too seriously. :-)

Also note that methodology is just a fancy way of saying "the way we think or conceptualize our approach to solving problems around here." I use the word a lot in the post, I'm open to other options for word choice.

And now, on with the show ...

Sean McMillan and I were talking about the evolution of methodologies today at lunch. He had some really interesting observations.

Think about the first methodologies that came out. (Waterfall, various customized versions of the waterfall, and, eventually, the uber-model, the CMM) Try to read between the lines. These models were all about FEAR: Fear that management does not have control, fear that the customer will not accept the finished work, fear that the project will be late, over budget, etc, etc.

So these first methologies addressed that fear in a number of ways: They froze requirements, they forced requirements "sign off", they insist on artifacts that have review, are version controlled, audited, etc - they tried to make software development "defined, repeatable, stable, and measured", they try to institutionalize process so that management is not dependent on the heroics of any individual, they eliminate "single points of failure", etc.

A lot of those early methodologies are monday-morning quarterbacking: "We noticed one time we had this one problem, so we are going to insert this new step in EVERY project to eliminate the risk of that problem."

Sean made a methaphor of a pothole methodology - We notice that we ran over some potholes and it gave us some car trouble, so we place gates around every pothole we see. Requirements Review, Code Review, Test Case Review, Requirements Signoff, Configuration Management, have a separate team move code into production ... this list goes on.

As the gates constantly propigate, we find that slowing down to drive around the gates becomes more of a hassle than we had before!

This makes complete sense to me. In "Quality Software Management" Jerry Weinberg makes the assertion that the "level 2 repeating" organization was a fantasy created by non-technical management, wheren they manage to wrestle control back from the developers. After all, at level 2, any individual developer is expendible; the process is king.

Sidebar: I've read a LOT of the stuff that came out of the academic/government sector about methodologies. One of the things I consistently notice is the use of big words to sound important and the lack of philisophical depth. This is a real problem if you're trying to develop software. On the other hand, if the REAL goal is to remove fear from executives and give them a feeling of control ...

Eventually, people begin to realize that dealing with fear is not good; instead we need to be adults, taking calculated risks and living with the consequences. We need to drive out fear in the organization (think Deming) and instead live with uncertainty. This brings us to what we called (again, lack of a better term) "second generation" methodologies that are a backlash to the first. XP is a great example - the whole point is simplest process that could possible work, combined with just enough safety nets that you can live with a little risk. Stop living in fear that the developers won't hit some meaningless deadline for a huge piece of work, and instead have a simple working system up in weeks and add features as you go. Duh.

As I said before, these second-generation methodologies are, for the most part, just a backlash to the first. They are saying "well, heck, too much process didn't work. Let's take away and take away and take away process untill we have something workable."

So, second generation languages are still caught up in fear - that is, driving it out. That's half the sales pitch. If we just take those gates down, maybe pave the road, we will get home faster.

The next logical step is how to stick a turbo-booster on the car: To find ways to keep developers focused on work and improving the pace of delivery of software. (Hey, I'm giving a talk on that on Oct 7th in Indiana, but it's not a methodology yet.)

Test-Driven Development is pretty good example of this - it transforms testing from a boring, manual task into a coding task. It transforms API design (function signatures) from a "design" task into a coding task; exercising the API to run the tests. Developers like to code; it makes testing a coding a task they can then automate, so they can do more coding.

What other 'tasks' of a methodology actually force developers to do a better job, or keep them focused on the job at hand? Pair Programming could keep them from surfing the web, and I'm sure there are more. Every XP book says that local adaptors will 'customize' XP to fit. Sean's theory is that those customizations contain the secret sauce to improvement. If the theory above holds true, we just have to find the cutting edge shops that are allready doing some of these practices, interview them, and we'll be defining the leading edge of this 3rd generation methodology movement.

I'm willing to give it a shot; in fact, I'll be talking to folks about it tomorrow in the office, next week at the Better Software Conference in San Francisco, then next month at the Indiana QA Conference.

The whole idea needs more work, but I wanted to jot something down before I forget. I'm curious as to comments ...
08:31 PM

Andy Lester in West Michigan

Andys Lester will be speak to the Grand Rapids Perl Mongers and the local Extreme Programming User's Group on Oct 25th.

At Lunch, he'll be presenting a guide to authoring CPAN modules to GR.PM - at the Priority Health Conference Center.

That evening he'll be at XP West Michigan, speaking on agile project estimation techniques; it's same talk he gave at the Open Source Conference this year.

Andy is the co-author of Pro Perl Debugging and sole author of MAc OS Tiger in a nutshell.

I'm geeked.
Friday September 02, 2005
02:59 PM


It's been - well over a year since I've posted. Checking to see if it still works, and trying to keep my account active. :-)
Thursday January 29, 2004
08:43 AM

Software Development _is_ writing

    Every now and again, I'll read an article about how in the 1980's and 1990's, Japan tried to create "software factories" that were supposed to kill american business the way Japan's industrial sector had killed american manufacturing.

    Except that it never happened.

    Why? In "Agile Software Development With Scrum", Ken Schwaber argues that the manufacturing analogy is inappropriate, even harmful to software development. In his words:

    "For a defined control process to work, these methodologies must define each process with enough accuracy that the resultant noise does not interfere with its repeatability, or the predictability of the outcome. I can watch engineers define a class numerious times and write down a definition of what I saw happening. This process definition is only useful if it can be repeated over and over to generate solid class descriptions. If my obersations are general or loose because many variations are employed to derive a class, the process definition is useless. The process definition will be so weakly defined that, when it is employed, it does not generate repeatable results. When an activity is so complex or complicated that a different defition is required each time it is executed, the activity cannot be abstrated into a process definition."

    That is my problem with heavy-weight methodologies: They take what is essentially creative work and try to boil it down into a manufacturing process. It doesn't work. Software is different each time, just like writing.

    Imagine telling a writer how to write! Oh, you can give them guidlines and heuristics. You can talk about transitions and prose and style. You can even set up a working environment for them or give them requirements for the output of the piece.

    The thing is, the implementation of the piece can be completely different between two people, and yet both articles can satisfy the requirements completely. Unless you are doing cut-and-paste script-kiddie work, software development is not Manufacturing -- it is writing.

    I once read somewhere (And I was certain it was the intro of Effective Perl Programming about Randal Schwartz, but now I can't find it) that through the process of writing, the author realized that he was not a programmer who knew how to write, but he was actually a writer who knew how to program.

    I do believe that is one of the mose congruent statements about programming that I have ever read.
Tuesday January 27, 2004
12:57 PM


A few weeks back, I wrote some potential articles to the editors of Software Quality Engineering. After some back and forth discussions, they decided to print one of them.
Friday January 23, 2004
07:37 AM

Professional Recognition of Testers

I just posted this to Danny Faught's SWTest-Discuss Email List:

I think I've hinted at this before:

IMHO, pure software functionality testers are likely to lack professional status, lack authority, lack respect, be likely to be laid off, etc, etc.

By "pure" I mean "People who don't do anything else." In nursing terms, all a pure tester can do is operate equipment to take readings.

To gain professional credibility, we need to grow the field to be more of a nurse-practioner who is involved from the beginning. The "Uber-Tester" would then test the requirements, be able to understand design issues, perform usability and GUI (Interaction Design) assistance on the prototype before the real code is developed, help the customer write acceptance tests, set up and assist with code review, as well as set up and run system tests. The Uber-Tester could also own the bug tracking system.

Johanna Rothman wrote an article on "First Class Testers" in this month's Better Software that covers the general idea.

IMHO, Software Quality Engineering is a discipline of Software Engineering. (Notice what Cem Kaner is a professor _OF_.) Testing is a subset of that discipline. We will never have have professional recognition among testers until we admit that justification by testing alone is insufficient.