/\ndy

No Place for Bugs to Hide

We talk about “bugs” in software as if they were caused by some unavoidable, blood-thirsty third-party that invades our pristine code, much as ants might attack a sweet picnic basket or mosquitoes an exposed neck.

But while bugs seems to be both unavoidable and blood-thirsty, they of course aren’t coming from anywhere but our own hands. We make them, and then they sit there, hidden in plain sight, right in front of us. Waiting for just the right moment (the demo in front of the vice-president?) to spring out from hiding and mock our calm expertise.

Do you know why we advocate the practices that we do in modern programming? Sometimes the reasons get lost in the drive to full buzzword-compliance; or perhaps you’re doing a programming practice because everyone else is doing it, or because some author recommended it. So let’s talk about why.

If you can cut down the number of places for bugs to hide, then when you do create a bug, you’ll find out about it right away. Not a month or six from now, once the app has been approved or the startup has launched or whatever. Get rid of the hiding places and you can fix the bugs now, while they remain small (bugs that hide, of course, snack on leftover code and grow stronger and larger with each passing day).

So here are but a handful of popular practices that help eliminate hiding places:

Unit tests

Why do a unit test at all? For only one really compelling reason: to prove that the code you just wrote does what you think it does. The tests pass, and know you know with some certainty what the code is really doing. That still might not be the right thing for it to do, but at least you’ve removed one breeding area for bugs.

End-to-end Tracer Bullet Development

The first iteration of a system should go from end-to-end, even if it’s as simple as “Hello, World!” That is to say, you’ve got all the major parts hooked up as it will be in the final system: from database through browser via some middleware, that sort of thing. No single part has to do much at all, but it needs to be there—to shine a light and remove a dark hole where bugs can hide.

Buddy up to Prevent Bug-Blindness

We are all particularly blind to the bugs we create, but fortunately a second pair of eyes (someone else’s, preferably) can usually spot them when we can’t. So practices such as Pair-Programming, or Code Reviews (be they nice and informal or excruciatingly formal) can really help identify our own blind spots. Have someone else check all your code before you check it in.

Frequent Delivery / Demo

And of course, nothing brings bugs out into the spotlight as effectively as an audience. Bugs just love the spotlight in front of a live audience, it’s a great chance for them to show off. And get caught. So give them the opportunity often: deliver working software every week or two, and demonstrate it to someone who cares. The bugs can’t resist the urge to show off, and then you’ve got them nailed.

Share Your Status

You need to know what the rest of your team is working on. You need to know when they’re stuck, or when a subtle change in direction or design starts to gain traction. By the same token, you want your buddies to know when you’re stuck or have come up with a new direction. The classic Stand Up Meeting from Scrum is a great way to do this: it’s a quick meeting, you do not go into problem-solving mode, you simply answer three questions:

1. What did I accomplish yesterday? That is, what concrete thing works now that didn’t work or exist before? Never answer with an abstract form of “I’m working on xyzzy.” That’s a dark hiding place. Be concrete.
2. What am I going to accomplish today? What’s your goal to get working today? Same criteria apply as to the first question.
3. What is in my way? This can be a big one. Do you need help? More resources? An answer from a reluctant source? The list of these blockers is your manager’s TODO list.

There are all sorts of other ways to reduce hiding places for bugs: information radiators, continuous build machines, code-level techniques including refactoring, and many others. None of these techniques will stop you from enbugging in the first place, but they will help you find them and squash them more quickly.

Code can be a dangerous place. Keep it well lit, and do go in there alone ;)

Directions for Safe Use

What a great time for open source. Thanks to these marvelous tubes that we call The Internet, there are now uncountable tons of great libraries, frameworks, gems, answers on stackoverflow and more that you can use to add features and functionality to your project quickly and easily.

Unfortunately, a lot of these bits of code and approaches come with their own problems as well. That’s only fair, and to be expected. But the real problem is that most times the author does not disclose these problems. You’re left to discover them—painfully—on your own, or gripe about them in a forum along with other users.

So I put forth a modest proposal. All code you use (be it open source or other) should be subject to similar truth in labeling as we see on pharmaceutical products. You know, the ones where the possible side effects for a headache tablet include headaches, dizziness, and sudden death. That sort of thing.

I won’t name names, but thinking of some technologies I’ve used lately, a few common warnings come to mind:

• Warning, may cause code bloat and gas.
• Use only in iterative environments.
• Do not use if you have a history of procedural programming.
• When used with dual-MVC, may cause confusion, blindness, and death.
• Must be used in the presence of an actual architecture.
• Use on Microsoft operating systems may cause nausea and headaches.

Got any others? Comment below or on twitter (I’m @PragmaticAndy).

/\ndy

Announcing Garnet, A Pure Non-Functional Language

April 1, 2013

There’s nothing as thrilling as announcing a new programming language: a new hammer for all the professional nails you might encounter. And this is possibly the most efficient, most effective programming language ever designed: Garnet.

Garnet is the first Pure Non-Functional language. According to Andy Hunt, the secret to it’s breathtaking efficiency is that “it doesn’t do a damn thing.”

Forecasts are optimistic that this new technology will save corporations billions of dollars that would otherwise have been waster on floundering projects using conventional technologies such as Ruby on Rails, PHP, and the abacus.

“To develop this, we looked at the really hard sciences—seriously hard problems from cryptozoology, astrology, numerology and that head bump thing,” reports Mr. Hunt.

Why “Garnet” as the name? “We wanted a name for something that was harder than Ruby, because, you know, that’s impressive.” When it was pointed out that ruby is actually harder than garnet on the Mohs mineral hardness scale, Mr. Hunt replied “Whatever. The point is, this is the perfect evolution of declarative style programming.”

“To program a system in Garnet, you simply declare what you want, and it will fail to deliver. It’s a lot like Prolog, but with less logic to go wrong.”

User reaction has been uniformly positive. “It’s a huge time saver,” said Fred. “Usually, we have to spend months and months writing code that fails to deliver. Garnet gets us there right away. It’s perfect.”

Andy Hunt
The Pragmatic Programmers
PragProg.com

Resistance is Natural

Resistance is Natural.

Resistance is the enemy. You’ve probably encountered resistance in at least popular form: we call it procrastination. But envision resistance as a much more powerful, more universal and pervasive force. Something like a meta-gravity, weighing down any of your significant endeavors.

That’s how writer Steven Pressfield views it in his book, The War of Art. Resistance as a mindless, destructive force, acting against all your better interests.

Whether it’s a creative endeavor in some art, an entrepreneurial venture or enterprise, diet or health initiative, education or project of any kind, resistance is there to be met as an opposite and equal force.

Resistance is sneaky and subtle. Procrastination is an obvious and easy manifestation, but that doesn’t make it any less potent. Some procrastination is easy to spot, especially if it involves cat memes or Reddit. But what about more subtle forms of procrastination, such as hiding behind estimates, or avoiding pair-programming, or not writing unit tests, waiting until you know before you try, or the pinnacle of group procrastination: the big meeting?

Then there’s the subtle expressions of resistance: some buried, niggling fear. Fear of failure, however small or large. Fear of being exposed as a fraud. Fear of loss. The perceived lack of support from your boss, or folks who work for you, your family, spouse, kids, and the rest of the infinitely uncaring universe. The unforeseen setbacks that send a stab of panic through your viscera.

The amateur takes these all personally, and resistance wins as you waste kilowatts of psychic energy trying to relive, rehash, revisit and reframe these events. The professional sits down, shuts up, and moves the ball forward.

I hate sports metaphors in general, but in this case it’s particularly apt. If the action you’re taking right now isn’t “moving the ball forward” (i.e., not advancing you to your goal), then resistance has won this round. It’s all about moving the ball forward, even if it’s just moving a few inches for now.

Think about that a moment. If your current activity, whatever it is, is not advancing you toward your goal, then it’s pulling you away from it. And no, it’s not letting you idle or stand still. If you’re standing still, your goal is still is motion—away from you. You’re losing ground.

King Leonidas of Sparta once said that the supreme virtue was “contempt for death.” Pressfield equates that in our modern times with “contempt for failure.” No matter what, move the ball forward. Ship the software. Write the chapter. Paint the picture, shoot the scene, post it, commit the code, whatever. Get it out there. Now.

And tomorrow the battle begins anew. New adversaries, new tactics. Resistance is clever, and will go for your soft spots. But resistance’s fatal flaw is its single-minded goal of stopping you from doing what you must. There’s one sure fire to win against resistance in all it’s forms:

Do it anyway.

How to Avoid Agility

There are many great ways to avoid being “agile.” Some are obvious, such as a sticking to a design or schedule long past it’s expiration date. Plans tend to be like milk on a hot summer’s day in that regard. They go sour quicker than you expect. But hey, it’s the plan, it’s already coded, so we chug the chunky milk anyway.

Maybe you’ve even realized that you can successfully hide from agile development in the agile practices themselves. Ron Jeffries points out one way you can avoid reality by hiding in the relative comfort of OCD estimating in his article in PragPub magazine, Estimation is Evil. Ron exhorts us to skip estimating entirely, and start shipping something now.

And that’s exactly the point. Estimation, Test-Driven Development, Pair Programming, Iterations, all the other agile practices are merely tools. As I’ve said (until I’m hoarse) doing the practices doesn’t make you agile. They are helpful, they are useful, but they do not define agility or, by themselves, take you to the next level.

What is the next level? Improv. That is, instead of planning and then executing, you want to execute, evaluate, and repeat. Picture yourself as a geeky jazz soloist: get out a couple of bars of a solo, see how the audience reacts, and change it up as needed, including trying things you’ve never done before.

What is agile development?

“Agile Development uses feedback to make constant adjustments in a
highly collaborative environment.” (from Practices of an Agile Developer)

The reason Ron insists we ship is simple: to be agile, you need feedback, and you need to adapt quickly to that feedback. You need to be able to change your designs, your code, your process, your team — whatever needs changing to reflect the new reality that feedback has reveled. To get feedback on your project, it needs to be in front of the intended users. Often. Every day, every week, surely no longer than once a month.

Note that this doesn’t necessarily mean all your users; you may only roll out to the entire user base much less frequently, say every 6 months or yearly. Or maybe you do it every hour, that’s up to you. But you need feedback from real (albeit maybe a subset) users constantly.

That’s why “Real Artists Ship” as Steve Jobs told us. You have to stop procrastinating and put it all on the line, with real risk in front of real users, all the time.

And that’s where we try and hide from agility. I think it’s a form of procrastination, a form of psychological resistance. The code isn’t ready yet, it just needs…

Don’t wait for the super-elegant object-relational mapping layer you’re going to design from scratch. Don’t wait for that time when you know that new language and environment better. Don’t wait for the committee meeting. Don’t wait to get it right: getting it out there is part of the process of getting it right. You don’t need to get it right the first time, you need to get it right the last time (/ht Jim Highsmith). But on your own, you’re just guessing. Maybe you’re a great guesser, or maybe you’re like me and you guess wrong a lot too. In front of real users, you’re don’t have to guess. You know.

And now you can change what needs changing.

The Marine Corps Way

Agile development is improvisation. It’s making changes to the project based on continuous feedback in near-real time. The U.S. Marine Corps has a common and oft-cited slogan: “Improvise, Adapt, Overcome.” That’s what modern software development needs to be like.

But it seems all too often we’re not improvising, or adapting. We’re just banging out the same old memorized riffs and calling it “agile.”

Ask yourself what you’ve adapted lately. Have you changed the code all around because of some insight from real world use? Great! Have you changed your process because of an insight from a retrospective? Have you changed your team? Your tools? Anything else? At all?

Are you actually adapting? Or just complacently doing TDD, Pairing, stand-up meetings, et al?

Don’t wait: Improvise. Adapt. Overcome. Today.

What's this about Outsourcing?

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.

/\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...