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

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!

MacBook Air and Iterative Development

There’s been a lot of whining about the MacBook Air that loses sight of it’s real purpose—and no, I’m not talking about the road warrior audience.

As you probably heard, Apple announced a new super-skinny laptop at this year’s MacWorld expo. Named the MacBook Air, it’s impressively skinny and light-weight, and a few features that move in interesting and new directions:

• No wired internet, wireless only
• Multi-touch trackpad
• Optional 64GB solid state hard drive

The “wireless only” is a natural evolution; with initiatives such as Sprint’s upcoming Xohm service the age of ubiquitous WiFi is just about here. Wired is so 90’s.

The multi-touch ability is a clear progression from the interface on the existing iPhone and iPod Touch devices, but with a twist. Instead of the direct manipulation touch interface you experience on the pocket devices, you’re confined to using the traditional trackpad. It’s not part of the screen.

Then there’s the allure of the solid-state drive. No mechanical wear-and-tear (great for a portable), better battery life (no motors to spin up), and I’m guessing pretty blindingly fast speed. But that’s a hefty $999USD option.

So why did Apple bother to make this Air laptop? It’s an iteration. A middle step from the existing product line to the next.

What we really want is a tablet. Full screen multi-touch, with a large and affordable solid state drive, always connected at broadband speeds, with hassle-free backup over the air. We’re not there yet.

But there are enough road warriors who will probably buy the Air to help drive down production costs for the new bits: the new smaller die Intel chip, perhaps, as well as the solid state drive and whatever other new-fangled goodies they’ve got inside. So you make an interim product such as the Air: it will have it’s audience, and that will pave (and pay) the way for the next iteration. Gives you a chance to work out the bugs, spot new opportunities, see how people use it. That’s what an iteration is all about.

We expect our software customers to embrace iterative development, with increasing features and incremental improvement from one release to the next. Yet I hear a lot of whining about the Air that it’s not perfect, that it’s not what people want, that you’re better off with a MacBook Pro, etc.

It’s an iteration. As with any product, take the pragmatic approach: if it meets your needs now, buy it. If you’re looking at possible future needs, then wait.

And maybe think about what an iteration is all about: feedback.

99.9999999 uptime (nine nines)

Concurrency, scalability, uptime. As internet-based computing and the internet grow in ubiquity, these characteristics become much more than buzzwords or sales points—they become vital to the life of your company, whether you are hosting or using web services, selling or buying.

Uptime is often stated in terms of a percentage of availability, something like 99.99% (one hour downtime a year) is desirable, or perhaps even the fabled "five nines", 99.999%, which comes out to something around 5 minutes downtime a year. Hardly worth monitoring :-).

But how would you like "nine nines" reliability? That's 99.9999999% uptime, which pretty much means that if you blink sometime over the next year, you'd miss the downtime completely. It can be done, and apparently has been done, in Erlang.

Steve Vinoski mentions this in his article in IEEE Internet Computing, where he talks about his own introduction to Erlang:

Unfortunately, the more I learned about Erlang, the more I also had that sinking feeling about how much time I’d spent over the years trying to (re)invent the wheels that *Erlang/OTP already provides*.

Historically I think many project teams have ended up with a pile of re-invented wheels over in the corner. Most folks have wised up over the years, and no longer embark on disastrous errands such as re-inventing their own object-relational database mapping layer, etc. But these core problems of high concurrency, fault tolerance, and reliability really cry out for a new approach. These are particularly hard wheels to manage, especially in standard environments such as Java or C++, and re-inventing them is less appealing than ever.

And of course, as with all languages and technologies, just seeing what's possible—and how others have solved these problems—can help you directly, even if you never use the technology itself. Steve sums it up nicely at the end of the article:

Meanwhile, do yourself a favor and get a copy of Programming Erlang. Even if you never write a single line of production Erlang code, reading and understanding this excellent book and the language it describes will make you a better developer.

The coming multi-core crunch?

According to this article in the Arizona Daily Star, the new generation of multi-core CPU's poses a daunting challenge.

Experts, quoted in the article, predict dire consequences if software for more complicated applications doesn't arrive soon. One even saw the need for some Manhattan Project style efforts to help solve this pressing problem.

Well, for the here and now there's always Erlang. It was designed from the ground up to address exactly this sort of problem, and it handles concurrency naturally and effectively.

Sounds like a good start to me; no bunker required.

Erlang creator interviewed on Dr. Dobb's Journal

Dr. Dobb's Journal has a nice interview with Joe Armstrong, creator of Erlang. Check it out!

"Release It!" gets a Perfect 10.

This JavaRanch review gives Michael Nygard's Release It! a perfect score—10 out of 10 horseshoes, in this case.

Congratulations to Michael! (who can usually be found on the XP mailing list and other haunts, if you've got a question).

In the space between tests

Mike Nygard has a nice article up on InfoQ.com, where it talks about the limits of unit testing and functional testing, among other things:

"Functional testing falls short, however, when you want to build software to survive the real world. Functional testing can only tell you what happens when all parts of the system are behaving within specification. True, you can coerce a system or subsystem into returning an error response, but that error will still be within the protocol! If you're calling a method on a remote EJB that either returns "true" or "false" or it throws an exception, that's all it will do. No amount of functional testing will make that method return "purple". Nor will any functional test case force that method to hang forever, or return one byte per second.

One of my recurring themes in Release It is that every call to another system, without exception, will someday try to kill your application. It usually comes from behavior outside the specification. When that happens, you must be able to peel back the layers of abstraction, tear apart the constructed fictions of "concurrent users", "sessions", and even "connections", and get at what's really happening."