We recently released the beta of a new title, Outsource It! A No-Holds-Barred Look at the Good, the Bad, and the Ugly of Offshoring Tech. Now that’s not so unusual, we release a lot of books on specific technologies, but also books on agile methods, project management, software testing, and so on.
Outsourcing isn’t easy, and it’s not for the faint of heart. It’s difficult to do well, and we’re fortunate to have an experienced author with solid, concrete suggestions to help you succeed.
But some folks wrote in that they were upset at this title, that we shouldn’t be suggesting outsourcing as an implementation strategy. I understand their point, however, complaining about outsourcing is a bit like complaining about an impending flood:
You can call the water good or evil, but the flood comes either way.
The flood is a fact, and you have to deal with it. You can pile up sandbags and barricade yourself in, you can head to the roof and try and escape it, or you can build a waterwheel and harness the forces for your own purposes.
We have no “position” on outsourcing. It’s a tool. You can use it effectively, it could also be used against you. Either way, we feel that the more you know about it, the better you’ll be able to deal with it.
If you want to keep your job, and not become a victim of outsourcing, you need to make yourself more valuable. Chad Fowler describes this approach to bolstering your career in detail in his popular book, The Passionate Programmer.
Projects and technology aren’t getting any simpler or smaller, and you may well find yourself requiring specialized expertise that you just can’t manage locally. So if you find yourself in a position to use outsourcing to your own advantage, then Outsource It! will help you do so effectively.
“We are called to be architects of the future, not its victims.”
—R. Buckminster Fuller,
No matter what the future holds, we aim to help you navigate it. That’s why we are in business: to make developer’s lives easier.
Thanks for your continued support.
Posted on September 28, 2012 in Current Affairs | Permalink | Comments (1)
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…
Posted on November 09, 2011 | Permalink | Comments (0)
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
Posted on August 03, 2011 | Permalink | Comments (0)
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 pragprog.com/magazines/2011-06/guru-meditation
Posted on June 01, 2011 in SoftwareDevelopment | Permalink | Comments (0)
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...
Posted on May 04, 2011 in SoftwareDevelopment | Permalink | Comments (0)
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:
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.
Posted on March 01, 2011 in Music | Permalink | Comments (1)
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...
Posted on January 10, 2011 | Permalink | Comments (1)
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 :-)
Posted on January 04, 2011 | Permalink | Comments (2)
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...
Posted on December 13, 2010 | Permalink | Comments (0)
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 www.pragprog.com/magazines/2010-11/guru-meditation
Posted on November 16, 2010 | Permalink | Comments (0)
See my home page.
•The Pragmatic Programmer
The original classic.
•Refactor Your Wetware: Pragmatic Thinking and Learning
NEW for 2008!
•Practices of An Agile Developer
Winner of 2006 Jolt Productivity award
•Pragmatic Unit Testing in C# with NUnit
New Second edition of this award-winning book