/\ndy

Vote Agile

Tomorrow is election day here in the US, and if you haven’t already, I urge you to get out and vote.

Here in North Carolina, many of us have already voted—42% of all Democrats, 35% of all Republicans, and 30% of all independents have already voted. I voted last week, and the lines were running a half-hour to an hour even then.

In any race, from the presidential level to the local, I endorse the more Agile candidate. Agility is all about collaboration and adaptability, and taking a pragmatic attitude towards decision-making. Working with other people—even people you don’t particularly like—changing your approach to fit the problem at hand, and avoiding rigid dogma are all hallmarks of agility.

Does your candidate seem the thoughtful, collaborative type? Or more of a shoot-from-the-hip, impulsive sort?

Adaptability means changing your approach according to the situation; some derisively call that “flip flopping.” Frankly, that’s the stupidest charge I’ve ever heard. I want elected officials who will change their minds as needed. A stubborn resistance to accept and manage change is a proven recipe for disaster.

Following a narrow ideology is a dogmatic approach; it doesn’t work in business and I dare say it doesn’t work well in government either. The challenges facing us today require a flexible, adaptable, collaborative approach. A pragmatic and agile leader, not one steeped in repeating the same old dogma.

So please vote, and vote agile.

Thank you,

/\ndy

Always an exception...

For every rule, no matter how iron-clad it may seem, there’s always an exception.

Here’s an odd one that just came up, from a friend of a friend.

This is an era of Heightened Security and tightened border crossings. You must have your passport, you can’t carry a medium-sized tube of toothpaste into the US, and even soldiers carrying their M16 assault rifles on airplanes are relieved of their fingernail clippers, just in case things a crazed manicurist gets out of hand.

So true or false: if you are not a citizen of the US, you must have a passport to enter the US.

False. And here’s at least one intriguing exception.

The Micmac Indian tribe signed a treaty in 1796 which, among other things, declared the rights of indigenous peoples to travel—and trade—between the US and what is now Canada (it was a British territory at the time). That right became codified into law in the US in 1952, as part of the Immigration and Naturalization act.

The upshot is that today, Micmac indians may pass freely between the US and Canada, and can carry anything they please, including items that would normally be subject to taxation, etc., and do not have to carry a passport.

Now granted you usually don’t have to consider the ramifications of 200-year-old treaties when developing an application or gathering requirements.

But then again, there’s always an exception.

/\ndy

Test-driven Learning

While working on my new book, I came across an interesting idea that extends the popular agile notion of “test-driven development” to learning a new language or a new technology.

As it turns out, just studying something new over and over again doesn’t actually help you remember the material very well. However, if you keep testing yourself by trying to recall the material over and over, you’ll strengthen those connections in your brain.

Try to write a program in that new language you’re studying—-you’ll need to retrieve the key information to do so. Try to explain key parts of that new methodology to a colleague. Keep at the retrieval—-the testing of your knowledge. It’s kind of like “test-driven learning,” but in a good way, not like those horrible social studies quizzes in eighth grade. The idea is to practice retrieval, not input.

You can also take advantage of the spacing effect to make this all more effective.

Cramming, or studying a lot of information in a short amount of time, doesn’t work very well. We tend to forget things along an exponential curve, so spacing out your quizzing reinforces material much more effectively. For example, you might plan on retesting yourself along a 2-2-2-6 schedule: retest after two hours, two days, two weeks, and six months.

But that’s not the most efficient use of your time, especially with a large amount of material. Some facts and ideas will get memorized more easily, and others will need more work. Trying to keep track of an individual memory-decay curve for each fact you’re trying to memorize is too hard to do manually. But, hey, we’ve got this nifty computer that we can use.

Piotr Wozniak developed an algorithm to take advantage of the spacing effect, implemented in the commercial product SuperMemo (there’s an open source implementation available as well). It’s basically a souped-up flashcard program that keeps track of your performance and schedules retests according to an individual decay curve for each item.

It’s a great way to take advantage of the brain’s caching and archiving algorithms.

/\ndy

iPhone NDA lifted, we're back in!

Thanks to everyone who wrote me today--and I do mean every one :-)

With the lifting of the Apple NDA, we've gone ahead and released the iPhone SDK book and will be adding the missing iPhone chapter to the Core Animation book as well.

Thanks to Apple for realizing the impact this had on the developer community and finding a solution.

/\ndy

Speaking in Raleigh 9/15

I'll be presenting material from my new book at the next Java User's Group meeting in Raleigh NC on September 15.

If you're in the area, I'll see you there!

/\ndy

FOO Camp, last chapter of Wetware book done

It’s that time of year again, time for the annual get-together in California known as FOO Camp. This is a bit of a milestone for me; two years ago at Foo camp I gave one of the first of my Refactoring your Wetware talks in an informal setting.

Today, I just released the last full chapter of the book (Pragmatic Thinking and Learning: Refactor Your Wetware) as beta. I still have a summary chapter to write, and lots of cleanup of course, but it’s an important milestone nonetheless.

I’ll be talking more about Wetware at FOO, who knows what else. Always an interesting crowd. With luck, I might even blog about it ;-)

Dreyfus Model interview

Folks often ask me for more information about the Dreyfus model of skills acquisition. I’ve got a whole chapter on that in my new book, but for all you auditory learners in the crowd, or if you want to watch me wave my hands while I talk, you’re in luck:

Rich Sharpe interviewed me about the Dreyfus Model at a recent conference, and posted the 15 minute video on his softwareintegrity blog. Drop by and have a look.

Stage 0: Not Ready For Agile

This last week, I was out speaking at the Better Software Conference and Expo in Las Vegas. While I was in the area, a large, well-known company contacted me and asked if I could pop in and given them a talk about transitioning to an agile software development method—my Pragmatic Agility talk. I had an available spot in my schedule, so I agreed. The manager who contacted me was very excited, and announced my presentation which was scheduled for the next day.

But the Powers That Be heard a speaker was coming in, and immediately cancelled the event.

It seems they felt that the manager “hadn’t gone through proper channels” in setting this up. The manager pointed out that no proper channels existed; they’d never had an invited speaker before. Since there was no existing procedure in place to follow to invite a speaker into the organization, they cancelled the whole thing—permanently.

For an organization trying to transition to an agile approach, I dare say they face more than a few challenges.

Agility is all about flexibility and adaptation. If your organization is inherently inflexible, you’re just not ready for agility. You can read the books, hire the consultants, try the practices, but it’s probably not going to work out. Your organization just isn’t ready yet. In fact, it seems to me there are at least a couple of these contra-indications.

You’re not ready for agile if you:

• behave territorially. You mark your territory like an aggressive dog, refusing to share power or information, and let everyone know if you weren’t included in the decision. When something new comes up, avoid it or kill it.
• are inflexible. You’ve got a policy for everything. If it’s not in the book, it doesn’t exist. This is the way we’ve always done it.
• grow uncomfortable with uncertainty. In an agile project, you will not know the project end date or even what features will be delivered in the next iteration. You cannot stand this, and will insist on fixed dates and costs right up front.
• treat developers as a commodity; a uniform, fungible resource. They are all alike. You can’t trust them to think for themselves, you’ve got to make the important decisions for them.
• believe development is a linear process. You ignore unpleasant feedback. Rather than acting on it, you always stick to the plan, just like a politician in an ill-advised military quagmire.

If any of these descriptions are true for your organization—or for yourself—then you’re not ready. It’s not time to start transitioning to agility just yet.

Agility is not about practices. Some practices facilitate an agile approach, and some practices make it nearly impossible. But the practices themselves aren’t that important: Agility is a mindset. It’s a flexible, adaptive approach to software development. The first step in transitioning to agility is to realize that:

Agility is a mindset

Once you and your organization are okay with that, and you’re ready to drop a lot of preconceived notions and established procedures and try a flexible, adaptable approach, then we can talk about transitioning to agility.

Next up: Step 1.

More on photosensitivity and web design

Author Jeremy Sydik has posted some additional information about photosensitivity and web design—not only how to avoid causing seizures in your readers. He also covers how to prevent greifers from using your site to launch attacks on others, and offers some suggestions for those with photosensitive concerns on how to configure your browsing environment to better protect yourself.

You can read more from Jeremy here.

How not to assault your users

As if life wasn't hard enough, some lowlife, scumbag griefers have taken to deliberate assaults on people who suffer from both photosensitive and pattern-sensitive epilepsy.

Wired magazine reported last month: "Internet griefers descended on an epilepsy support message board last weekend and used JavaScript code and flashing computer animation to trigger migraine headaches and seizures in some users"

"The incident, possibly the first computer attack to inflict physical harm on the victims, began Saturday, March 22, when attackers used a script to post hundreds of messages embedded with flashing animated gifs."

Hopefully these dirtbags will be found and prosecuted somehow, but in the meantime their heinous actions have raised awareness of a potential problem with websites: your nifty new website effect could cause seizures in people, and you can be held accountable for it.

So as a public service, we've released a relevant tip from Jeremy Sydik's book, Design Accessible Web Sites 36 Keys to Creating Content for All Audiences and Platforms The tip It's Not Polite to Flash The Audience is now available for free for your reading pleasure. Please take a look.

Suing your best customers, as the RIAA is so fond of, is bad enough. But physically assaulting them is even worse!