/\ndy

Halloween 2011

We tend to go a little overboard for Halloween here at the Hunt household. This year, we added to our fog-machine/laser/Arduino-fueled festival with a few solenoid-driven pneumatic props. We also moved into the garage, which allowed us to hang black plastic walls and create a proper walk-through, instead of just having displays in the yard.

Here’s what we rigged up:

First, the main Arduino board:

The Arduino microcontroller board is wired over thin-gauge speaker wire to motion sensors (Passive Infrared, or “PIR”) and to solenoids. Each solenoid is connected to a pneumatic cylinder, which drives the prop when activated. The Arduino is hooked up with a WaveShield, which is a daughterboard that plays .wav files from an SD card. The code is simple: when one of the PIRs fires, it activates a relay for the solenoid, and fires off a shrieking audio sample.

Here’s one of the smaller props that we call “Sheila.” Sheila is a simple jumper that pops up from behind her tombstone and shrieks. Loudly.

Along the way there are some simple static props, like this zombie floating in midair over the cauldron.

Next, visitors encounter ghostly, green, glowing footsteps on the floor:

Simple, but effective: an LCD projector mounted to the top of a tall step ladder, projecting a video loop on the floor. The crunchy sound effects really helped — I synched those up with the animated feet using Logic.

Next up, the Cabinet of Doom. This is an old cabinet frame, fitted with a one-way mirror on the back. At first, you see just your own reflection in the back of the cabinet.

But when the prop fires, a flood light illuminates the horror within…

On our way to the graveyard, we have to file past Fred, a large-scale jumper built out of 2×4′s and a PVC frame. Early versions of Fred had a bit of a stability problem, such that it became more of a skeleton trebuchet than a scare prop. We had to keep retrieving skeletal pieces from across the room. Some cable ties and Gorilla Glue helped keep Fred a little more together.

In the graveyard, we have some standard props, including a “Bucky” skeleton that’s been modified with heat-gun shrink wrap plastic, colored with some furniture stain. And of course, some luminescent skulls (a little Woolite and blacklight works wonders).

But the best part of the graveyard is Madame Leota. I took a plain foam mannequin head ($4 from Amazon) and sanded off the nose and lips to give a smoother projection surface. Then I layered on some drywall plaster to smooth out the uneven styrofoam.

Then using one of those small micro-projectors, got a loop of the real Madame Leota from Disneyland and voila, an animated, ghostly disembodied head:

She just sits in the graveyard and recites her spiel over and over.

Exiting the garage, there’s a hallway with strobe lights and a giant prop head over the doorway, which also features two large mirrors, making an endless tunnel to your right and left.

To see it in all its dimly lit glory, check out the video here.

 

 

Only 355 days or so until next year…

The End of Agile

As of 2011, the codification of the principles that comprise “agile” is now ten years old. Do you think it should survive unchanged another ten? Is this the end of agile?

A few years ago I was giving one of my Pragmatic Thinking & Learningworkshops, and we were talking about the value of a wide-ranging education that included the arts, not just the sciences. One of the participants made a revealing comment about how useful those non-technical courses were:

“The theater I did in college has helped me more in my programming career than half of my engineering courses.”—Grant Gainey, Senior Architect Developer

There are many reasons that a theater course would come in handy, not the least of which is learning how to work well with others under sometimes trying and unexpected circumstances. But there’s one aspect in particular that’s worth looking at in more detail.

In her autobiography, comedian Tina Fey (Bossypants, Reagan Arthur Books; 1st edition 2011) explains one crucial part of a theatrical education: improv. That is, improvisational theater. You’re stuck out on stage with one or more other actors, with no script, no goal, no pre-arranged dialog at all. The “plot” and dialog emerge spontaneously as you and the other actors interact. According to Fey, there are two rules to improv:

Read the full article in the August 2011 issue of PragPub magazine

Getting Past Agile Advanced Beginner

Again and again folks tell me that they’re stuck. They embarked on the journey to become agile practitioners, but despite the best intentions, they can’t seem to break through to function as a true, self-directed, self-correcting agile machine.

Instead, they are stuck. Stuck following published “best practices” that someone else came up with for a magazine article. Stuck following a plan that was handed down to them, due on a deadline negotiated by lawyers they’ve never met or spoken with.

The team is practicing some agile methods, but they aren’t agile. Left to their own devices, nothing will change that. They’ve reached the Advanced Beginner stage, and it’s going to take some care and attention to move past this to become a competent practitioner...

Read the rest at http://pragprog.com/magazines/2011-06/guru-meditation

Uncomfortable with Agile?

It’s been ten years since we coined the term agile. Are you finally comfortable with being agile? If you are comfortable, then that’s too bad, because it means you’re doing it wrong.

Read the rest in this month's Guru Meditation article in PragPub magazine...

 

Timebox: Perfect, Good, and Done.

I'm a big fan of timeboxing.  Setting a deadline, and committing to meeting it with something in hand, is a very powerful tool.

I've always enjoyed writing songs, but trying to get any sort of coherent effort together and in a "releasable" state has always been a problem.  There's always one more rough edge to the recording, one more lyric to fix, one more vocal to re-record (hopefully better this time), one more different way to try the mix, and so on.

Sound familiar?  It's a lot like a software project.  In either case, left to our own devices, we'd just noodle around forever and probably never release anything, because it's not yet perfect.

So along comes the RPMChallenge — an invitation to record and release a full album (ten songs or 35 minutes worth) in a month. And they chose the shortest month, February, damn them.  I figured I'd give it a shot.  Why not?

It was a really great experience.  I felt the power of emergence, as ideas came together with no preconceptions.  I got better at quickly loading up templates in various pieces of software, and using them together.  

I got better at doing it by doing it, which is the only way, after all.

It felt good to be done.  And no, it's not perfect.  I could easily go back and tweak the music, lyrics, and production, with diminishing returns, forever.

But I won't.

Perfection is an asymptote; you can steadily approach it, but never quite reach it. At some point, you've just got to cut the cord and proclaim it "good enough" for the context at hand. Perfect is the enemy of the good.  And done kinda trumps them all in the end.

So I proclaim my 28-day timebox experiment done.  It's a little pop, rock, jazz, and even a somber beer bottle solo. You can give a listen over at:

http://independentmemes.bandcamp.com/album/twenty-eight-turns 

You can listen online for free, or download it all if you provide your email address (don't worry, I won't spam you or sell it, just want to let you know about my next project).

If you enjoy it, or despise it, please email me and let me know.

And if you've got something you really want or need to get done, just get out the calendar.  Mark the deadline.  And work a little, each chance you get, towards it.

Enjoy!

/\ndy

Why Johnny Can't Be Agile

Your brain is not wired to work with agile methods.

Ten years ago in February, at Snowbird in Salt Lake City, Utah, I was hanging out with 16 notable folks who cared deeply about software development. We talked about many things, all around the general theme of what to that point had been called “light-weight processes.”

But “light-weight,” while perhaps technically correct, carried connotations of insufficiency. So after some discussion, we all agreed on coining the term agile. And thus the Agile Manifesto and the eponymous movement were born.

But agile techniques were a hard sell. Even simple, non-controversial practices such as version control weren’t yet universally adopted. I used to ask audiences at talks how many people did not use any version control on their project. Typically somewhere between 10% and 30% of the audience raised their hands. It wasn’t that folks were dead set against using version control on religious grounds, they either just didn’t know any better or just didn’t bother.

So surely this was just a matter of education; of spreading the word. Agile methods made sense. Agile ideas are grounded in reality, and even some actual science. Surely the world would see the logic in it? You’d expect some amount of resistance to any new way of developing software—especially one where continuing to Embrace Change was part and parcel of the new method. Folks don’t like change in general, and here we were advocating riding the wave of constant change. But somehow it seemed that resistance to agile ways went deeper than that.

We are not rational or logical creatures. We’d like to think we are, but the biological, psychological truth of the matter is that we’re predictably irrational. How irrational? Take a look at Wikipedia’s list of common cognitive biases for starters. This dauntingly long list begins to describe the many ways that we humans aren’t as logical or reliable as you might think. While you might encounter many of these in your daily life or work, a few stand out as significant barriers to agile adoption. These cognitive biases are why Johnny Can’t Be Agile.

Read the rest of the article...

The Pragmatic Programmer 26th printing

Boy ten years sure goes by fast. It was ten years ago this February that the agile software development movement picked up steam with the meeting in Snowbird, Utah, wherein a ragtag group of developers first coined the word "agile." Dave Thomas and I were there, having just written The Pragmatic Programmer about a year before.

The Pragmatic Programmer is now going into it's 26th printing. After that and the PickAxe book, Dave and I started the Pragmatic Bookshelf, where our 99th title is being released this week. My latest book, Pragmatic Thinking & Learning, was the 50th title. What will be the 100th title?  

Stay tuned at pragprog.com and you'll find out :-)

Happy Programming!

/\ndy

The Perfect Deadline

A hard deadline means no more excuses, no more options, no second chances. It’s literally now or never.

Of course, deadlines don’t usually work that way. That’s the part of the threat of a deadline, and after the deadline passes, threats usually escalate. The stakes get higher; consequences and punishments more severe. You’re not off the hook—the deadline just hangs around your neck like a millstone that keeps growing and getting heavier.

Hard deadlines, with their attendant fearsome consequences, can shut your brain down as the deadline looms, and leave you with reduced cognitive function for up to two days after the event.

What happens to your ability to observe, to problem-solve, even to think clearly when faced with time pressure? Read More...

Avoiding the Infinite Abyss

November's issue of the Pragmatic Programmer magazine, PragPub, has my latest article, Avoiding the Infinite Abyss:

Estimating is never easy. In agile projects we try and get a better feel for estimating over the course of a project as we get more familiar with the pace and capabilities of ourselves and this particular team and technology environment. On most projects we want individual team members to come up with estimates for their own tasks, the ones they’ve selected from the current project backlog. That puts the onus of estimating on the person who actually has to do the work, a nice touch of straightforward reality in an otherwise messed-up world.But for programmers new to this style of working, or new to the team or to the technology, trying to decide on how long a task might take is kinda like trying to pick a winning lottery number: billions of choices, only one right answer.
...Read the rest at http://www.pragprog.com/magazines/2010-11/guru-meditation

WindyCity Rails

WindyCity Rails is coming up soon, and I'm proud to say that Pragmatic Programmers is a sponsor.

They'll be giving away some of our popular screencasts, and two of our very own Pragmatic authors will be speaking:

• Noel Rappin of "Rails Test Prescriptions"

• Jeff Cohen of "Rails for .Net Developers"

If you're in the Chicago area, this is your chance to hang with some real experts, face to face.