Zappini

Date: Mon, 29 Aug 2005
From: Jason Aaron Osgood
To: New York Times (letters@nytimes.com)
Subject: Free Judy Miller


Editors-


See, the thing is, I don't believe you. Judy Miller is exercising her Fifth Amendment rights, not her First Amendment rights. And, as far as I'm concerned, anyone supporting, covering, or apologizing for Judy Miller is complicit in her crime.

Who knows? Maybe the next time you cry "wolf!", someone will believe you. Try and see.


Cheers, Jason Aaron Osgood / Seattle WA

Slashdot is all aflutter anticipating The End of the Bar Code. Yea, another silver bullet to solve all of our problems.

Last yearish, I was curious about RFID tags and all. Knowing of my interest, lifelong friend and all around nice guy, Steve P. suggested we attend a seminar he discovered at the local university. The organizers were a local chapter of the IEEE or some such. At the time, WalMart's stated intention to completely transistion to RFID was the hot topic.

What I learned is that RFID isn't a single thing. There's quite a few different types of devices (tags) and matching sensors with all sorts of configurations (powered, passive, or both), frequencies, protocols, and features (security, self-destruct triggers, storage capacity, etc.). The entire domain is a real mess.

I was most surprised to learn that implementing RFID isn't some sort of easy, off the shelf, slam dunk. Far from it. There's all sorts of technical, supply, cost, and procedural challenges. Like with most silver bullet thinking, the supposed panacea will be realized when tags cost just a nickel a peice.

What I can't figure out is how, exactly, RFIDs are superior to bar codes. For instance, RFIDs fail silently. When a bar code is defective, it's visually obvious. Also, bar codes are far more robust than anything electronics based. Seamingly low-tech, barcodes are quite sophisticated. My favorite variation is Xerox PARC's DataGlyphs. (Kind of like those microdots from the Cold War spy novels!)

The only conceiveable benefit to bar codes is the as yet undemonstrated ability to scan the entire inventory of a warehouse all at once. But that's not ever likely to be a common acheivement. There's radio interference from motors, lights, cell phone towers, etc. The frequencies used also have trouble with metal frames, racks, containers, etc. And there's bandwidth issues trying to scan that many items simultaneously. Lastly, most implementations will require sensor portals for the RFID tags to pass thru. Ahhh, which is just like bar codes, right?

So what could motivate WalMart to so enthusiastically embrace RFIDs? Easy. WalMart's entire profit model and business strategy is based on theft (from suppliers, employees, and governments). Adopting RFIDs, which are very likely to be worse overall than the current solutions, could easily prove to be a colossal mistake. But that's okay for WalMart. RFID is just the hammer to beat up their suppliers with. The intent is to stick the poor bastards with all the costs, risks, and heartache, taking the lion's share either way. If it wasn't RFID, it'd be something else.

Same as it ever was.

If the U.S. government doesn't plan to occupy Iraq for any longer than necessary, why is it spending billions of dollars to build "enduring" bases?


-- Joshua Hammer

Exactly.

This has been on my mind since before the start of Bush's Folly in Iraq. During the run up (toady stampede) towards the war, I parroted the wisdom that if we go into Iraq, we're there forever. (Or until we're bankrupt, which ever comes first.) We're still in Japan, South Korea, Germany, the Phillipines, all places that we've "liberated". And no signs to date that we're leaving.

I likened Team Shrub's stated "in and out" strategy to Clinton's statements about Serbia. Clinton swore up and down "One years, tops. Then we're out." I knew he was lying. The hypocritical Republicans who challenged his policies knew he was lying. Even the Europeans, who were supposed to take over the policing duties, knew they wouldn't ever be able to replace the Americans.

Knowing about the ongoing, large-scale construction of permanent bases, I've never really gave much thought to all the shifting, demented rationalizations for Bush's Folly. Until I hear the bases are being abandoned, I just assume we're there for good. In other words, I've always taken the neo-con(artist)s public enthusiasm for American empire at face value.

I just finished the book "Empire" by Niall Ferguson, on loan from my buddy Eric Scharf. It's a good read.

It's too bad the dimwit neo-con(vict)s hadn't studied the example of the British Empire. One amazing attribute of their empire was that they did it all on the cheap. The first wave were often chartered corporations. Only later would the British Government push aside the corporations, subsume the colonies, and formalize everything.

In contrast, our patriotic war profiteers, war criminals, and habitual incompetents seek maximum personal gain while sticking the American taxpayers with the bill. It all seems to be an elaborate Ponzy Scheme to bankrupt our treasury, alienate the entire world, humiliate our nation, and leave our grandchildren paupers. Pretty clever, I admit.

Via Digby's Winning and Losing.

For a while, at least, I was captivated by the notion organizational change. You've heard the lingo: learning organizations, continuous process improvements, total quality management, kaizen, object-oriented design and analysis methodologies, extreme programming (XP) and agile development. Yadda, yadda, yadda. I was even regularly picking up Harvard Business Review to gleen the latest insights.

I think it started by reading Peter Drucker. I served a brief stint at Starbucks. An utter, depressing, soul robbing failure. Having never failed like that before, I wanted to understand why my best efforts were for naught.

Now, years of experience and many books later, I'm cynical about organizational change. I've labeled each new variation (retread) "pop-business-psychology" and liken the ideas to Kiplings' "Just So Stories". It's even tainted my social interactions.

One of the Pauls at our Wing Ding study group mentioned a recent interview with an XP team. I undiplmatically asked "Does anyone know of a successful XP project?" Paul replied that this particular team has been doing XP for 4 years.

Reiterating this topic with Stan the next day, he asked "It depends on what you define as success." Yup. And that the whole rub right there, isn't it?

So I thought it over some more. Had to refine some of my thinking. And have now decided that successful organization change has two attributes. The effort had a positive return on investment. Secondly, the change persisted after the champion moved on.

Framed thusly, that gets to the nugget of why I asked about XP projects. I think many, if not most, of the XP ideas are pretty nifty. Worthy of consideration and criticism, which is high praise coming from me.

Regardless of XP's virtues, it's very important to acknowledge that change is not simply free. Organizational change is an investment. And there's no guarantee of success.

Like everyone else, I've suffered through my share of utter failures. I've even had the joy of actually forging a high performance, high functioning team, embracing many exciting ideas, only to have it all swept away by change of leadership, layoffs, and acquistion.

So given the givens, in this day of Free Agent Nation, with high job mobility, outsourcing and offshoring, businesses, products, projects, and strategies flashing in and out of existence like particle traces in a bubble chamber, I question if the whole enterprise is even worth it.

Maybe I'm just depressed because I recently, yet again, had the make the case for automated nightly builds. Times like these, it's hard to feel like our profession has made any progress.

Date: Fri, 26 Aug 2005
From: Jason Aaron Osgood
Subject: Natalee Holloway
To: Greta Van Susteren (ontherecord@foxnews.com)

Hi Greta Van Susteren-


Your blog was cited by Ed Cone, which was cited by Daou Report.

Your industry sensationalizes human interest stories because you're
all ghouls who feed off of human misery for fame and profit.

Please, feel free to contact me if you need any of this explained to
you using small words and picture diagrams.


Cheers, Jason Aaron Osgood / Seattle WA

I recently had morning coffee with Paul, a friend, long-time Wing Ding participant, and former co-worker. He related a recent experience that is all too familiar to us in the software development business.

Paul was told to make some new stuff. Paul, being the experienced, thoughtful professional that he is, suggested that this new stuff be testable. You know, unit tests, test scripts, stubs for testing... the usual best practice stuff.

Of course, his suggestions were met with derision. Specifically "This isn't academia. We do things differently here."

My recent experiences aren't so different. One of my current projects has a lot of stored procedures. (Not my decision.) Of course, none of this stuff is in source control. So I learn SQL Server well enough to export all this stuff, write some build scipts (start server, create database, create stored procedures, smoke tests, etc.), and stuff it all into our Subversion repository. The original programmer of this stuff is less than enthusiastic about the new discipline.

So I mention to my otherwise fairly well intented manager "Hey, you know, I'll need part of one of the spare boxes lying around for the nightly builds." What!? Nightly builds? Oh no, I don't want you wasting your time on that stuff.

I am so done having this conversation. It's not like I'm Moses coming down from the mountain. Or just making this shit up for kicks. As far as I'm concerned, this isn't a debatable topic. If the goal is to succeed, you have testing regimes, use source control, and setup automated nightly builds, etc.

I (mostly) get the ignorance thing. Ditto the nickel-wise, dollar foolish thing. And I grudgely admit there's that reluctance to change thing.

But what I don't get is the anti-rational strategies so many of my contemporaries employ. This isn't the struggle for progress as described in The Diffusion of Innovations.

It feels more like the so-called debates about evolution, anthropogenic global warming, and supply-side economics. One side is using facts, figures, and reality. The other side is using ideology, rhetoric, and willful ignorance.

I've never understood the anti-intellectual undercurrent of American society. It's anti-progress and therefore anti-human. It floors me that anti-intellectualism has such a strong grip on persons whose very wage earning potential depends on their ability to absorb, intepret, and use knowledge.

This article, like Cem Kaner's insufferable Testing Computer Software (2nd ed), assumes an adversarial relationship between testers and programmers. It's true that in most software organizations, test and QA are valued a great deal less than engineers, which is too bad.

I once managed a software team. My (apparently unique) solution to the QA dilemma was to empower the QA team. The QA team owned the release. That's right. We didn't ship until they said we shipped.

I got the idea by riffing on a bunch of different ideas. I was deeply impressed by Peter Drucker's description of quality circles, where reps from marketing, design, manufacturing, and QA made decisions jointly. I also want people to feel like they own their work. When QA is merely an advisory role, too often they (rightly) feel victimized and ignored. Lastly, for the most part, programmers are awful about testing and QA in general, so I knew not to trust them with QA decisions.

Of course, merely having QA own the release wasn't the whole story. We divided primary responsibilities up. Marketing was in charge of scope and price. Engineering was in charge of schedule and how things got done. In this way, every party feels they have a place within the whole.

Note that I used the term primary responsibility vs sole responsibility. As much as possible, I had everyone on the team do every task at least once. QA people were writing automation scripts. Engineers were writing specs and answering support calls. Marketing was helping with testing. When you were doing a task, you faithly wore that hat.

This type of job hopping was great of team building. One positive outcome was engineers developing empathy for QA (like appreciating the negative impact of not checking one's own work). The cross-disciplinary approach helped generate ideas and concensus building during group decision making and problem solving activities. Lasty, it allowed people to dabble in other areas, which is important for job growth and personal development.

The decision making processes we used were swiped from Joint Application Development and risk management strategies. For an example, I'll explain our Go/NoGo process, which was loosely based on the Roman evalution method.

When QA determined a product was all but ready to release (passed acceptance testing), we'd go into the Go/NoGo phase. Each morning, QA distributed a candidate release. Everyone would hammer on it. Around 3:00pm, we had a 15 minute meeting for everyone involved with the product, including sales, tech supp, docs, translators, etc. We'd go around the room, asking "Go or No go?" If anyone said "No Go", their issues were added to the list. After the meeting, those issues would be fixed immediately. Then we'd do it all again the next day. If everyone said "Go", we'd forward the CD to production and call it good.

Our team got into a rhythm of about 6 month cycle for a major releases. Of that, the Go/NoGo process would take about a week.