Gabe's Axiom

This is a reprint from my own blog, but I think it's applicable to the audience here.

I devised a new platitude that I’ve dubbed Gabe’s Axiom:

Engineers make stuff work. Designers make stuff useful.

I did so in response to my overall experience as an engineer to date. This thought coalesced recently while reading the book The Design of Everyday Things. Engineers love making and using gizmos and gadgetry and they love figuring out how to use a new widget. Therefore they find it frustrating when Joe user isn’t as passionate about learning all 15 ways to shut down a Windows based computer. I’ve often seen this frustration manifest as rebuke when a layman has trouble using equipment in the shared workspace (office copier, coffee pot). I’m guilty of it myself. I’d posit that a great many engineers don’t design with elegance or ease of use in mind. Making stuff work is their MO. However, the gizmos that are most useful are ones that are intuitive. It’s not the users fault if a gadgets operation isn’t readily apparent. True engineering involves synthesis and distillation with an eye toward elegance, not tech savvy alone. It’s the simplicity on the other side of complexity. It’s more challenging, but definitely more fun. After all, if it isn’t useful then what’s the point?

Briefing Charts Redux

I keep coming back to this topic of presentations. I really think that if we could just have the guts, imagination and will to improve the way we give presentations, we'd find that we could fix all sorts of other problems. If we would spend the time necessary to communicate clearly & accurately, and if we valued telling the truth over making sure the charts are consistent with everyone else's format, not only would a lot of problems be easier to solve - I think many wouldn't even occur in the first place.

But it's tricky, isn't it? If your charts don't look as dense, complex and convoluted as everyone else's, it'll look like you didn't really do any work, 'cause everyone knows complexity is a sign of effort, right? Actually, a simple, clear message takes more understanding, more time and more skill than the jumbled messes we call "finished products."

So, to help get things started, here are a few thoughts and guidelines, in case you haven't picked up Garr Reynolds' Presentation Zen yet:

1) You don't need your logo on every chart. Honest!

2) You don't need a redundant title on each chart either. Really, you don't!

3) Use hand-outs to present details. Use PowerPoint charts to present main topics

4) Limit yourself to somewhere between 1/2 an idea and 1 full idea per chart.

5) Time is always (always always always) the limiting factor (the only limiting factor). It's not about how many charts you use.

Catching Up With BRITE

One of the first projects I really had an impact on was a little imagery dissemination project for the National Geospatial-Intelligence Agency called BRITE (originally Broadcast-Request Imagery Technology Experiment... I think they changed the E to something else later). It was a small system designed to provide overhead imagery to forward deployed SpecOps guys who had very limited bandwidth and were highly mobile.

The BRITE project was one of the keys to developing my FIST approach to technology development. We had a very small team - in fact, I was the only government guy working on the project (and I was a junior Captain). On the contractor side, we just had a handful of people, and most of them were only assigned to the project part time, as I recall. The budget was quite small, the deployment schedule was short (this was 2001 - 2002). The system was designed to operate in austere conditions and it worked like magic.

That experience had an enormous impact on my thinking and my perspective on what can be done with small teams of talented people, working on tight budgets and tight schedules. It also hammered home the importance of simplicity - organizationally, technically and procedurally.

So, just for fun I googled it and came up with a great story about using BRITE to support the Hurricane Katrina disaster relief effort. It's nice to see that my little project still had legs after I'd moved on to other things.

It's Not Inevitable

OK, let me summarize the whole FIST thing as concisely as possible. It really comes down to this:

"There is nothing inherent in military technology that requries it to cost so much, take so long, or be so complex."

There, I wrote it down for everybody on the Interwebs to see, and it feels good.

The more I read, the more I do, the more I hear people's stories, the more convinced I am that complexity is not inevitable. We do it to ourselves, technologically and organizationally and procedurally... but we dont' have to. Similarly, these huge cost overruns and schedule delays are not inevitable. Until we believe that - I mean REALLY believe it - we're going to keep getting the results we've been getting.

Incidentally, this applies to NASA's space projects as much as the DoD's systems... and no doubt to commercial & industrial projects as well.

Simplifying UAV Controls

Over at MIT, a small group of grad students recently figured out how to control UAV’s using an iPhone, instead of the “complex, suitcase-sized controller that soldiers must haul around to control hand-thrown Raven (UAV’s).”

As reported at Wired’s DangerRoom blog, “In six weeks, we went from the idea to a real flight test,” using MIT’s indoor robot range... The total cost? $5,000 for a new, commercially available, quad-rotor robot — plus the cost of iPhones for her crew… It relies on only the iPhone’s existing gear, and the phone can still be used for regular calls, web-browsing, texting, etc.”

Hmmmmm– a small team of talented people, working on a shoestring budget ($5K? Really?) and a cannonball schedule (6 weeks!), successfully use existing, familiar, mature technology as a way to simplify the operations of a previously complex endeavor. Now, where have I heard that formula before? All in favor of launching a 10 year, $2.7B project to confirm their findings, say “Kick me!”

Interestingly, the MIT crew touts the iPhone “Drone Control App” as having some cool real-world uses. “Not only would a iPhone-like controller make soldiers’ jobs much easier, it also opens up UAVs to a whole new, non-military market. If robot control is cheap and intuitive, people might find all kinds of new uses. Cummings’ own favorite: “Being able to launch one out of the window and fly it down to the Starbucks, to tell me how many people are in line, so I know when to get coffee.””

Sure, it’d be cool to send out a pocket-sized UAV, controlled by an iPhone, to scout whether the line at Starbucks is long. But a website with a Line Cam would do jus as well. What would be really cool is if the little drone could handle ordering, paying and hauling a cup of java back to home base. Now THAT’s a killer app. Moving atoms around is something the internet just can't do for us (yet?).

Second thought - I probably got that backwards. The killer app is for Starbucks to field a swarm of UAVs that can fly around the city and deliver coffee, which you ordered via your location-aware iPhone. The UAV swoops in and brings you coffee (or pizza, chinese food, etc) to your precise GPS coordinates. UAV delivery is coming, I tell you, it's coming...

Contracting Fail

I recently came across this post from Cliff at the Sunlight Labs blog, talking about their failed attempt to bid for a government contract (thanks to Dick for the link!). I say "their failed bid," but in fact I think it's more like the government's failure to get their bid. The current government environment is so insular, jargon-heavy and complex that a new company ends up facing all sorts of unnecessary barriers. Sunlight Labs ended up not even submitting their proposal.

But that's a discussion for another day.

What I want to comment on is their attitude to the whole thing. They looked at it as a learning and growing opportunity. They looked at it as a failure, yes, but a head-held-high kind of failure. Something to reflect on, learn from, and discuss with a wider community. They even acknowledged that, as it turns out, the project they'd planned to bid on was probably too big for their organization to effectively achieve. Now that is clearheaded humility and insightful self-awareness.

Their experience definitely gave me something to think about. I love their story, and I love the way Cliff tells it. And so we award Sunlight Labs the coveted Rogue Medal of Awesomeness.

F-22 RIP (?)

With the Senate's recent decision to not fund additional F-22's, I'd like to take a moment to say, with as much respect and propriety as possible, WOO-HOO!

Ahem.

And I was also thinking that now might be a good time to highlight some of the reasons it's a good idea to not spend more money on the Raptor.

1) The SECDEF, SECAF and CSAF don't want more. In fact, the Secretary and Chief wrote an OpEd in which they said it's "time to move on."

2) Despite going operational in Dec 2005, the F-22 has yet to fly a single combat mission in either Iraq or Afghanistan. Where is it flying? Alaska - where it (ironically) performs the mission that was envisioned for it back in 1981: keeping the Russians away. Yes, I suppose that's important, but hardly the top priority for today's DoD... or tomorrow's... or the day after that...

3) It's too expensive and has all sorts of maintenance problems (both of which probably contribute to #2).

Ultimately, I think the problem with the F-22 is that we've spent too much time and money on it. We made it too complicated (both operationally & technically). The end result is technically obsolete and operationally irrelevant (for example, it can't share data). Did you know we started the F-22 Upgrade program BEFORE it went operational? Um, shouldn't we at least start flying it before we upgrade it? [note: I can't put my hands on the link to support that statement at the moment, but lemme know if you want it & I'll track it down.]

If we'd focused on simplicity and insisted on budget & schedule restraints, we might have ended up with a system that was Affordable, Available when needed and Effective when used.

Instead, we ended up with one that's hugely expensive, not available on time and not suited to the military's needs. And did I mention it can't share the intel it collects (except with other F-22's)?

The lesson for the rest of the world is pretty clear. A lack of restraint, an infatuation with complexity and a dependence on political support to keep the project alive leads down a dark and ugly road.

Rogue Project Leaders take note. Rogue projects are generally quick, inexpensive, simple and unloved and/or ignored by the Powers That Be... and that's a good thing.