yesterday i spent a couple hours at the national museum of the air force in dayton ohio. military design and engineering is always a fascinating topic because of the varied constraints they deal with which are much less important for civilian designs.
websites are obese and getting heavier and there’s a fascinating trend which piques my interest called brutalism – inspired from brutalist architecture which itself was a response to more optimistic and opulent styles of previous designs.
in many ways the goals of brutalist web design follow those of military aviation – herein are scattered lessons i learned while touring the museum as they relate to software.
motivation
the reactionist view to intricate, hand-crafted, artisanal web experiences can be summarized by a user goal listed on uxbrutalism.com:
as a user
i want to visit the website
so that i can see it
for good reason many of us in the industry labor over how best to present our websites in order to help our customers accomplish their goals. sometimes we forget that a common and legitimate goal is simply to read the things on the web page.
if you’ve never seen inside a military vehicle you may not realize how similar their goals are:
as a pilot
i want to reach the target or objective point
press a button of some kind
and return home safely
these are quite basic requirements and are entirely focus-driven. we don’t particularly look to our bank websites to create visually stunning and unforgettable journeys; although the wonders of the sea are indeed remarkable, they can get in the way of just writing and reading a check.
in the same way we don’t expect a full bar and inflight-entertainment on board our strategic bombers because those things don’t help the pilots accomplish their main purpose – in fact they distract from those goals.
there is a place for a bach, though, or a renoit. what’s different about brutal interfaces? as i was roaming around and inspecting the planes i drew a few key similarities between the kind of software design i work on and military aviation which underly a reasonable jump to brutality brutalism.
- laser-focus on completing the goals of the “customers” – the website and the vehicles are tools to that end and are themselves a failure if the “customer” fails to accomplish the mission.
- “business” requirements are rapidly changing and so more important than building a product is building a design which we can quickly iterate. we have to quickly respond to changing environmental needs and so building a lean or “bare-essentials” product has value just the same as “beautiful” designs do.
- we must be particularly attentive to costs because we often have to throw away our previous designs and builds. military aircraft crash or are shot down, missiles blow up, and web technologies and expectation change, rendering obsolete our previous work. if we don’t need it then it doesn’t belong.
the lessons
sometimes we get really excited about really bad ideas
this was an early bomber built by gianni caproni, immortalized in the wind rises. the aviators are resting their backs against massive fuel tanks and this plane is being designed to fly over enemy battle lines. i don’t know if any ever blew up, but later aircraft designs did more to separate the pilots from the combustibles
you ain’t gonna need it – yagni
plastic panels over the walls of the helicopter add little value while at the same time getting in the way of the technicians who need to repair and inspect the wiring and systems embedded in the sides. in fact, the decorative panels can hide damage and put a mission in jeapardy. there’s no electronic handle that magically pops out as you get near because a single mechanical swing is enough. these details aren’t important; spend your time figuring out the important things and let “good enough” be good enough.
you don’t know what you don’t measure
the sensor in the picture above was dropped from a plane, dug into the ground, looked like a tree sapling, and listened for troop movement in enemy territory; tens of thousands were deployed.
if we want to make wise choices we have to be informed about the what’s happening “on the ground.” experience is valuable, anecdotes are almost worthless, but real information is gold. our sensors and metrics though have to be small and unintrusive. we cannot make accurate observations on subjects aware that they are being observed.
information makes us aware of obstacles and provides feedback on whether our decisions were effective or not for our purposes.
don’t hide important stuff
in a number of situations the single most important thing is getting a pilot out of the plane – we don’t need cute exit signs – we need something ugly and boring and obvious and easy to find and hard to mistake.
one major and frequently reported frustration the web has done is standardize light-gray text over a white background – it’s hard to read and yet reading that text is the reason someone visited the page.
accounting is quite valuable
this nuclear bomb has serial number 30000 and is painted on the bomb itself. crews need to be able to account for what is there and what is missing. if the bomb doesn’t blow up we need to diagnose why.
we don’t want to have to run to figure out what version of our code blew up when it inevitable does blow up. quickly responding to events depends on quickly understand what those events were – code deploys, network changes, and performed tests should all be instantly available to us when fixing problem or doing routine audits of our systems.
having bombs or code in “production” that shouldn’t be is just as bad as not having bombs or code that should be.
operational maintainability is king
a few rivets and a sheet of aluminum taken away and every important system on this jet is accessible for inspection, repair, and replacement. it’s a complicated piece of machinery and there are air conditioning systems, radio systems, engine control systems, radar systems, and many other systems. each system is separate, isolated from each other, and has some form of serviceable control area in a specific location.
can we pull back a sheet of aluminum and address a single component system in our software applications? can we pull out the fuel pump without having to also pull out a mile of wiring that also happens to wrap inextricably around the ejection seat?
really simple is rarely really easy
the jet engine is stupid simple in concept: compress incoming air so that it heats up; when it’s hot enough spray in some gasoline which will spontaneously ignite due to the heat; let the air (now much hotter) rapidly expand through a turbine to both push the jet forward and also power the compressor/propellers.
yet, jet engines went through failure after failure before the first one could sustain operation. they are extremely difficult to design and build and depend on heavy mathematic calculation and simulation. our modern jet engines aren’t all that different from the first one – mostly just better materials and better control.
often the most valuable designs end up very simple but it takes focus and effort to find that simplicity and a way to make it happen. we can keep adding propellers and V16s to a point, but eventually we need a simpler engine with fewer moving parts.
code is this way – all engineering is this way.
the specific details of our code may be intricate and complicated, but we should at least be able to summarize how our designs work in a sentence or two. someone will have to figure it out later and they need a high-level view of what it’s supposed to do and how.
similarly a simple experience on the web may take considerable investment to discover. tradition and expectation can so heavily bias our assumptions about what should be that it can interfere with our ability to consider alternative ideas.
our modern web is so full of complicated JavaScript-based applications that it’s easy to forget that we can just send content directly to the browser.
basic instructions prevent basic catastrophe
another nuclear bomb (we like having these – we have many of them) and another simple marking – bad things might happen if this gets tipped.
destructive actions should be clearly marked. there are actually thousands of things to be aware of when dealing with nuclear weapons, but the most important thing for people to know when they are wheeling one from the hangar to the bomber is to not tip it.
terms of use, privacy concerns (or violations), destruction account actions and purchases, should all have basic and clear indications where customers will see them. it does not count if you hide in a ten thousand page document that people give up all their rights by continuing on your website.
consequences for failure in specific contexts should then have terse and appropriate and obvious warnings to prevent catastrophe. warnings matter: it’s why they are everywhere in daily life.
“achievement” can be a shameful thing
we have overcome the impossible in the name of obliterating life on earth and have done so in the name of immature power plays. there is no escape from the consequences of launching a missile around the earth and vaporizing entire cities. nobody is going to want to be the one to actually use these products as they are designed. they are incredible accomplishments of engineering and science and they belong in a museum.
software can be written for no valid reason and we can get caught up in making some bigger, longer, and more gaudy than what the person next to us built. we may not get any acclaim for saying “no,” but history will separate the sane from the madmen in the long run.
technical achievement isn’t enough
sanity sometimes does win in the end. despite the incredible technology in the peacekeeper missiles they were cancelled for non-technical reasons. in fact, technology is rarely the answer. this missile carried ten nuclear missiles that attack from space with ferocious speed – a “small” payload of only about two hundred times the explosive power of the little boy dropped on hiroshima.
we decided as a nation to not use our powerful toy weapons just as we have agreed to not use chemical weapons in battle. human factors and sanity can be more important than being able to be the most violent and destructive force around.
software projects can be technically great and practically useless. we have to think first about people and the impact our designs have on them and let proportionality guide our decisions. we have to be ready to let go of something when outside forces signal its end.
the greatest projects may evade recognition for decades
the sr71 may be the most fascinating and successful story of aviation design in history, yet it was a secret until after it was obsolete. the design team did a remarkable job doing the impossible with this jet but nobody knew and they couldn’t tell people about it. military planners were aware of the jet, but ultimately they cared about getting accurate and timely information about the enemy’s movements and installations.
the greatest software is software people don’t realize they are using and it probably won’t get much public praise. we can consider tcp a success because people aren’t even aware that it exists (for the most part).
a teacher once shared with my class that if you want people to remember you, ask them about themselves instead of telling them about yourself – they will remember that someone listened. similarly, if we want people to remember our software we will make it transparent to them – it’s so un-intrusive in their lives that they remember only that they accomplished their own goals without even having to think about the tools they were using.
ideas aren’t bad just because they are old
the flying wing was a concept being worked on since the early 1900s and the b2 stealth bomber first flew almost a century later. this is an insanely incredible aircraft. during the iraqi bombings it flew continuously for over forty four hours from missouri to drop its bombs on its targets and then fly back.
software goes in cycles: mainframes, personal computers, “the cloud,” “personal cloud,” etc… technologies shift and we iterate on old ideas: render on the server, render on the client, render on the server, etc…
since engineering is about tradeoffs we find that as related technologies and requirements change different tradeoffs will come in and out of style with time. web development was stunted for a long time because we didn’t have reliable and safe ways to run code in the browser at usable speeds. browsers today are fast and we’re jumping back to old ideas.
just because something is old or has been done before does not mean we shouldn’t use it or try to use it again.
brute-forcing has a role too
at 16% of the total aircraft weight, the a10 has one stinkin’ big gun – brrrrrp! it’s not particularly elegant and it’s somewhat wasteful, but for some missions it can be exactly what’s needed – a reign of big bullets firing down on a specific area. it’s so big and powerful that its recoil has the power to veer the aircraft off its heading and the exhaust gasses from the gun can shut down the jet engines. this is no precision-guided ordinance.
sometimes we’re in a rush and we have alerts blaring all around us and we just need to jump in and fix a broken software project. when time is critical it’s the results that matter. normally we don’t want to just blast our code out of the water though.
it takes care, consideration, and wisdom to know when to apply which techniques to our problems – there are very few clear and unbendable rules in software or in life.
everything, especially brute forcing, requires support
this machine was purpose-built to reload the massive cannon on the a10. it’s a remarkable piece of engineering in its own right.
everything we do maintains its own operational cost. the b2 bomber requires 119 hours of maintenance for every hour in flight; the a10 gun takes thirteen minutes to reload even with a motorized, computerized, robotic, engineered reloader. simpler systems tend to require less maintenance burden because there are fewer things to go wrong and fewer tightly-wound interconnects with other systems.
we therefore cannot think that our efforts as developers and designers ends when we ship our products. if we do then they will collapse. even the military, with its brutal designs, spends massive amounts of time and energy maintaining the systems they use because it’s still considerably cheaper to keep existing systems running than to throw them away and start over.
reuse things in new contexts
somebody managed to install a howitzer artillery cannon inside of an aircraft. the world is a scary place.
on the other hand, very little time was needed to install this gun in a place it wasn’t intended to be used.
well-designed systems are contained systems and because of their limited scope and self-reliance they can be applied in new and innovating ways.
emotion tends to cloud and lead reason
and on the same plane with the artillery-in-the-sky we have an indication that the crew got so caught up in the passion of what they were doing that they forgot why they were doing it. this is one of the most terrifying ways war can go wrong.
if we pause for a moment and think about an armored weaponized cargo plane getting nicknamed the “angel of death” then we should be horrified. it’s reasonable to expect getting such a name from an enemy, but our goal shouldn’t be to eliminate life – it should be to preserve it. sometimes people reason that loss of one life is justified in order to save the lives of others, but that doesn’t warrant a wanton disregard for any.
people get carried away though.
the cloudy fog we get in leads us to make terrible decisions, risk our own success, and ruin reputations.
software serves a purpose. it’s easy to get too caught up in the coolness of what we are doing that we invest in the shininess factor and forget why we’re building it in the first place.
there are almost infinitely many ways we can piece together different technologies and animations and interactions but we’re going to get lost if we stop looking towards the goal, of building a tool which lets our customers quickly accomplish the goals they are wanting.
excellent engineering is often way cool
brutal, basic, and thorough engineering doesn’t have to be boring though. oftentimes it’s wicked cool to look at.
some websites are extremely utilitarian and extremely cool at the same time. as people we find value in beautiful things and we find value in innovative things. we’re generally easily fascinated.
iteration speed is dependent on design
military aircraft are extremely high-capital projects in contrast to software with almost zero capital needs. yet, in both fields we have to iterate quickly and respond to changing requirements. the ability to keep on improving a design comes from a thorough understanding of the operating environment and the operating tolerances of the product.
if we cannot say when and how our software will fail then we’ll be surprised to learn that it fails. if we cannot say when and how our software will perform then we cannot say that it will perform at all. we must be able to verify our designs and assumptions.
simulations and testing takes up previous resources but they pay off by preventing waste and embarrassment.
resilient systems are built from layers of reliability and defense
the b17 did not need its massive tail to be so large but many aviators made it back home because of its extra bulk – the bomber could still fly even after half of the vertical stabilizer had been shot off or destroyed.
waste is an enemy of frugal and lean design but it still serves an important role at times. a little more memory or processing power can prevent a service outage in those rare times we need them and they are simple ways to provide a little better service.
complex systems fail when multiple levels of non-catostrophic failures simultaneously occur at different levels of severity. there is rarely a “single point of failure;” usually our systems fail because of a number of violations all building up until everything is running at its max capacity and lowest tolerance.
it’s not enough therefore to guard against failure in one or two places, but instead reliable systems are built from reliable systems where tolerance and risk mitigation is built-in to the design of each piece.
war is about destroying life and giving your enemy your resources
bombs like the v2 devastated london (and many other cities) raining down fire and horror and killing indiscriminately. fire bombing in japan destroyed far more than the nuclear weapons did. the end result was a lot of killing and grief, plus a resource transfer – every bomb, every missile is built from metals and chemicals and other materials. like the old adage, it’s still quite true, “he who slings mud generally loses ground.”
the more time we spend responding to what other people are doing and try to match what they offer and try to wipe them out the less time we’ll have to focus on making our customers successful.
how many bombs would it take to consume the same amount of steel which could be used to build a bridge?
component reuse is about building other things
many of the planes in the museum had different engines in different variants or at different times. the fact that one can simply replace an engine in an aircraft should be quite startling, as an aircraft is little more than a cockpit and wings attached to an engine – the engine is the engine of the aircraft. yet, this merlin engine was repurposed into an american fighter plane we we were able to produce one of the most successful wwii-era fighters with almost no design time spent on the engine.
reusable parts and composable pieces mean that someone can pick and choose how to integrate different systems and rely on the reported operational characters of those things without having to design the entire system as one big interrelated whole. we have an array of levels of reuse.
we shouldn’t have to write new software code to do things that are already solved, yet we perennially rebuild what has already been built. the more specific and custom our designs the less we are able to reuse old code. well-defined interfaces and abstractions enable reuse. an engine turns a shaft and consumes fuel – the internal workings are largely unimportant when designing a plane. occasionally the internals matter, but usually only in extreme cases. if we had enough battery available we could replace old gas engines in propeller aircraft with an electric motor and the plane would continue to operate as normal.
technology evolves before it revolutionizes
homing missiles fundamentally changed aerial combat, yet the germans had been building missiles in wwii. this one is a piece of art in many ways but was limited in deployment because the factory which produced them was destroyed. “perfecting” a technology takes time and iteration, but oftentimes when it does become ripe, it can wipe out existing assumptions and wisdom and usher in new epochs of design.
the original iphone was such a revolution built upon evolving ideas of the smart phone concept. it had effects far beyond telephony and we had to reimagine how people use software to interact with the world because it meant that nearly everyone would be carrying around this electronic gateway to the internet.
a concept is not invalid because it failed to launch. sometimes the time simply isn’t right or the right elements are still lacking the finesse they need to revolutionize. in some ways the iphone was truly revolutionary but in ways nothing about it was actually new. a revolution requires the right mix of opportunity and excellence to take off.
revolutions are built upon boring work
some people fly epic and romanticized battles when they join the air force. some people shovel rocks over flat metal pieces to build a temporary airfield. yet these airfields made it possible to project aerial power in places otherwise unreachable.
someone has to do “the dirty work” in our software systems and those people probably won’t get much credit, but the exciting bits usually depend on massive and reliable operational systems.
sometimes fear and destruction is quite artistic
this is a replica of the bomb dropped on nagasaki and also the actual plane which dropped it. it’s elegant, it’s shiny, it’s simple, it’s patterned, it’s truly an angel of death. there is often a strong lure to building systems that cause great harm.
it takes a strong will to chose the worthwhile over the alluring. it’s worth it. we should be careful about making weapons of destruction look beautiful.
ridiculous sounding ideas often aren’t
in name it seems quite ironic to build a suicide bomber trainer, but the idea is sensible from a certain perspective – japan didn’t want to waste their pilots and their bombs, so it was important to be able to train the pilots so they would hit their targets. this too was absurdity, but war is generally absurd.
if you follow online forums around software development you will find an abundant supply of people trolling how ridiculous something is that someone else built and oftentimes that claim is based on a misunderstanding or lack of understanding the purpose of the thing.
ridiculous software ideas aren’t always appropriate, but they sometimes are and when we encounter them we will do well to assume they serve a purpose and work backwards from that instead of judge them from a position of superficial understanding. in other words, something isn’t without purpose just because we fail too see its purpose.
and finally…
distance from a victim makes it easier to harm them
the unmanned reaper hangs above the setup for a gala which was taking place last night at the museum. a control operator pilots the aircraft like a video game (when it’s not running in autonomous mode) from a computer screen on the other side of the world. a twitch of the finger someone the operator has never seen or heard will die. a little girl will lose her parents.
soldiers aimed away from their enemies until they were trained to overcome their aversion to killing. as we remove the humanity of the enemy it becomes significantly easier to end their life or impose great suffering and grief on them.
software developers need to know the domains of business for the people for whom they are building software. we must understand the grievances our products impart and sympathize with that pain. engineering is first and foremost about people and our software should make peoples’ lives better. it doesn’t matter how elaborate, how beautiful, how developed, or how cool it is if it doesn’t make it easier for people to achieve their goals. it fails if it mounts frustration to peoples’ already stressful lives.
conclusion
these are random thoughts which apply to many domains, not just software, but that was on my mind so that’s how i wrote this.
there’s a recurring theme behind so much of this and that is the role that maintenance plays in design. flexible, frugal, and fast product development depends on our ability to reliably operate and change our systems in deployment.
further, and maybe more important, is that the kind of affordable excellence demanded by military applications and tech startups needs a consistent laser-focus on the goal being solved. we must guard our focus and evaluate our progress at every step to see if we have actually come closer to solving the problem that needs solving. we have to be unquestionably aware of what that goal is and distance ourselves from the emotions and passions which can keep us on wayward paths.
finally, i hope that we can agree that not all purposes are as good as others. what we do and what we build impacts the world and our fellow humans. it matters when we spend our abilities and interests to help, in ethical and humane ways, to solve real problems people suffer.
we adapt quite well to ugly and awkward systems if they serve our higher purposes.
the afterburner 