Everyone likes a challenge from time to time. However, some challenges should be avoided. Overly complex systems that stretch the limits of possibility can easily exceed those limits. Even when they can be achieved, the better question is can they be achieved in a satisfactory manner (stable, peformant, secure, etc.). The more important question is not “Can it be done?” but “Should it be done?”.
In his essay “Requirements vs Architecture”, Charlie Alfred relates a quote from German aircraft designer Willy Messerschmitt: “The Air Ministry can have whichever features it wishes, as long as the resulting airplane is not also required to fly.” Messerschmitt’s point, of course, was that regardless of what someone specified (even regardless of who that someone was), the laws of physics would rule. The client’s understanding of those laws, much less agreement, was completely orthogonal to the applicability of those laws.
Seventy years later, that lesson has yet to be learned. Ironically, one of the latest examples involves the design of military aircraft. At $400 billion, the grab-bag of features that is the F-35 is described by Time as “The Most Expensive Weapon Ever Built”:
The single-engine, single-seat f-35 is a real-life example of the adage that a camel is a horse designed by a committee. Think of it as a flying Swiss Army knife, able to engage in dogfights, drop bombs and spy. Tweaking the plane’s hardware makes the F-35A stealthy enough for the Air Force, the F-35B’s vertical-landing capability lets it operate from the Marines’ amphibious ships, and the Navy F-35C’s design is beefy enough to endure punishing carrier operations.
“We’ve put all our eggs in the F-35 basket,” said Texas Republican Senator John Cornyn. Given that, one might think the military would have approached the aircraft’s development conservatively. In fact, the Pentagon did just the opposite. It opted to build three versions of a single plane averaging $160 million each (challenge No. 1), agreed that the planes should be able to perform multiple missions (challenge No. 2), then started rolling them off the assembly line while the blueprints were still in flux–more than a decade before critical developmental testing was finished (challenge No. 3). The military has already spent $373 million to fix planes already bought; the ultimate repair bill for imperfect planes has been estimated at close to $8 billion.
As I’ve said before, you have to ask “why?” and you have to pay attention to the answer. If the answer is “because it’s a challenge”, then that’s as ethically suspect as “I wanted to try out the technology”. Focus and discipline isn’t very sexy, but going hundreds of billions over budget isn’t a resume highlight.
Some might consider this type of soul-searching as unnecessary. Neil deGrasse Tyson sparked a minor controversy when he suggested students should avoid taking philosophy because asking too many questions “can really mess you up”. The rebuttal to that, however is:
Ideas to show the world how the Humanities are COOL and essential to the world? #DigitalHumanities pic.twitter.com/0YTuvjZ9up
— Emily (@EmilyFranzini) December 18, 2013
Another way of falling prey to this particular anti-pattern is via inadequate analysis. Tom Graves’ “”Please don’t touch the touchscreen””, he tells the story of just such a debacle. His doctor’s office upgraded to a new touchscreen-based check-in system. Soon there was a bottle of hand sanitizer and a sign asking patients to clean up after using it (infection control). Cleaning up beforehand wouldn’t work because the touchscreen would get smeared with sanitizer:
So maybe the touchscreen was not such a good idea? Or, maybe, not even the auto-check-in at all – rather than an in-person check-in, allowing the reception-staff to build up a better in-person knowledge of the clinic’s clientele? Hmm…
Sometimes thinking things through (and paying attention to what can go wrong) can save a lot of time and money.
Weeks of hacking can save hours of research.
— Torbjörn Gyllebring (@drunkcod) December 30, 2013
[Tightrope Walker Image by Adi Holzer via Wikimedia Commons.]
Form Follows Function 
As always – great post.
While there is no doubt in anyone’s mind that JSF is troubled program, using Time magazine may be a bit sporty as the primary source. http://goo.gl/E0DhkC and http://goo.gl/UWWZbM may provide better insight into the Root Cause of it’s problems with cost, schedule, and techncial performance.
One issue in our complex systems world outside DOD, NASA, and DOE, is the notion of Root Cause Analysis is often missing. The IDA work on other aspects (full disclosure, I work part time through IDA in “essential views” of program performance to construct “leading indicators of shortfalls), are focused on the Systems Engineering aspects that contribute to outcomes like JSF, http://goo.gl/bE6uRa
In the absence of the Root Cause, we keep treating the symptoms, especially in enterprise IT, which rarely has a Systems Engineering paradigm, but skips straight to requirements and sometimes comes back to architectural frameworks in whcih to “hang” those requirements.
Our DoDAF framework requires “capabilities based planning,” through the Defense Acquisition Guide, so there at least is an intended approach – though not always applied properly.
LikeLike
Thanks Glen, very glad you liked it.
I considered the Time piece to be adequate to get the point across on a high-level. That being said, I really appreciate the links to the in-depth analyses – they might be a bit much for a general audience, but they definitely appeal to my inner Clancy fan. They also validate my (admittedly) amateur’s opinion that they tried to combine too many contradictory requirements in one design.
No argument re: the shortcomings of enterprise IT. As in most things, the pendulum swung from one extreme (trying to micromanage to the tiniest level of detail) to another (no design whatsoever). In design as well as management, I tend to favor a mission command(auftragstaktik) approach. There needs to be coordination to ensure that all the components (both teams and systems) are moving in the same direction, but balanced by a realization that as you move beyond your level of granularity it becomes riskier to try to manage details you may lack the information to manage.
LikeLike
Pingback: Design Follies – Architect Knows Best | Form Follows Function
Pingback: Fixing IT – Credible or Cassandra? | Form Follows Function
Pingback: Problem Space, Solution Space, and Tunnel Vision | Form Follows Function
Pingback: Institutional Amnesia, Cargo Cults and Software Development | Form Follows Function
Pingback: A Meaningful Manifesto for IT | Form Follows Function
Pingback: Abuse Cases – What Could Go Wrong? | Form Follows Function