28 March 2011

Development Principles

OK, I've been poking at the still-sidelined F-22 a bit lately. Let's step back a bit and look at some of the principles involved.

For starters, I very much believe in planning ahead.  I think it's a good idea to start cooking dinner before you get hungry. It's a good idea to save up some money before your car breaks down. And yes, we need to build weapon systems before the conflict arises. As my SOCOM friends often point out, "Competent Special Operations Forces cannot be created after emergencies occur."

I also believe the future is going to be surprising. We don't know what demands will arise, what seemingly eternal threats will go away and what new ones will emerge. We can't anticipate Black Swans. The only thing we can do is maximize our flexibility and our ability to respond to the unexpected. Read Taleb's book for more on that.

I'm also quite convinced we cannot build an effective fighter jet in 20 years, but we can do it in 3-5 years (the same holds true for all sorts of other technology genres). If we spend 20 years building something, we're going to end up with something that's technologically obsolete, operationally irrelevant or both. The  basic principle here is it's important to minimize the time between stating the need and addressing the need. Our 1980's era predictions about the 21st century didn't quite pan out. And our current predictions about what we'll need 10 years from now aren't going to be correct either. There are many reasons I don't think we'll have an air war with China... and one of the reasons is that people keep predicting it as a likely future.

I think we need to take a closer look at the stuff Chuck Spinney wrote, about how less expensive systems tend to outperform more expensive systems, and simpler systems tend to out perform complex systems. I believe thrift and speed are not merely fiscal or political values. They are desirable technical attributes for a system. You want to build a really fantastic capability? Do it quickly & inexpensively (and keep it simple). And please keep in mind that the cost, delay and complexity associated with systems like the Raptor are not inevitable. We could rapidly deliver inexpensive air superiority jets if we wanted to, but only if we try. Speed, thrift and simplicity were never objectives on the Raptor.

So let me be really clear: if we want to ensure air superiority (or any other technical advantage), spending billions and decades is the wrong way to go about it.

Finally, I believe our development efforts should be guided by a prioritized set of requirements (as our Agile development friends do). Deliver the most important capabilities first. Deal with less important capabilities later. So, for example, if you're in the middle of two or three wars where air superiority jets aren't relevant, maybe bump that particular capability to a lower position on the stack.

I'm just sayin'...


Anonymous said...


You've reminded me of this little passage from the Hagakure (it's also in the Jarmusch film Ghost Dog).

"In the words of the ancients, one should make his decisions within the space of seven breaths. Lord Takanobu said, “If discrimination is long, it will spoil. ” Lord Naoshige said, “When matters are done leisurely, seven out of ten will turn out badly. A warrior is a person who does things quickly.” When your mind is going hither and thither, discrimination will never be brought to a conclusion. With an intense, fresh and undelaying spirit, one will make his judgments within the space of seven breaths. It is a matter of being determined and having the spirit to break right through to the other side."

It seems FIST is a timeless principle. I hope it doesn't take a 'black swan' to make the bureaucrats understand that.


Glen B. Alleman said...

One core failure mode for the agilest is the missing "capabilities" for the system. Starting with requirements is a sure fire way for failure in IT projects and well as JSF.

The US DoD has adopted Capabilities Based Planning, from other - more advanced Defense Orgs. With a defined set of capabilities, the requirements now have a "Raison d'ĂȘtre" for each requirements.

Using the picture on your link, the prioritized list of requirements is just that - a list. No architecture - business or technical, no value stream map showing how these were prioritized, no Integrated Master Plan showing how increasing maturity is assessed and similar missing pieces.

The Dan Ward said...

Thanks for the comments - I'm not familiar with Hagakure but I'll look it up.

@Glen - Good insight on failure modes. Important stuff to be aware of. I'm not sure the distinction between requirements and capabilities is necessarily inevitable (i.e. capability based requirements). The picture on the link of course is just one piece of the puzzle...

Anonymous said...

The ATF/F-22 followed many of these tenets - then Rephases and "Lightening Bolts" and peace divideds dragged it out far beyond the original rapid timeline. Always found it ironic that the architect of major "reform" was the one later caught cheating and went to jail for it.