I Want to Be Graceful

I don’t want to be someone who never breaks. I want to be someone who still has room to maneuver after things break.

The takeaway

I thought about the wish to “be graceful” alongside Graceful Degradation in software design. Graceful Degradation is the idea of preserving essential functionality even when some parts become unavailable, so users can still achieve their goals.

• Grace isn’t defined by perfect manners, but by the options you still have after the unexpected happens
• Decide in advance what matters and what can be sacrificed
• Don’t just recover on your own—let the people around you know what’s happening and what to do next

“Implementing this in life” is a metaphor. Humans can’t be run on TypeScript. But the perspective of designing how things fail can also be useful when thinking about how people behave.

Grace is designed room to maneuver. It’s not just the ability to keep things on schedule. It’s the ability to protect what matters when things go off course and give the people around you enough information to make their own decisions.

This article expands on the content of my five-minute lightning talk, “I Want to Be Graceful,” with a definition of Graceful Degradation and some additional design context. It’s written to be accessible to both engineers and people unfamiliar with technical terminology.

1. I wanted to be graceful

Lately, I’ve been listening to classical music. When you listen to music every day, it can start to seem as though not only the sound, but also the posture and gestures of the people listening, are becoming more refined.

That made me think, “I want to be graceful too.” Someone who doesn’t flinch when they spill tea, responds calmly to an unexpected message, and doesn’t let anything that happens disrupt the mood of the room.

I’m not trying to claim that classical music makes people graceful. It’s just where this talk began. When I thought about my ideal person, the first image that came to mind was “someone who doesn’t fall apart, no matter what happens.”

2. You can’t measure grace on the happy path

It’s not that hard to behave thoughtfully when things are calm. You have time, things are going according to plan, and the other person is relaxed too.

The hard part is when unexpected things pile up. Plans change. The connection drops. Your presentation slides break right before you’re due to present. If you raise your voice, stop making decisions, and spread anxiety to everyone around you, your usual thoughtfulness can disappear in an instant.

What you need then isn’t the performance of keeping a straight face. It’s enough room to choose your next move.

You can break grace down into three parts:

• Composure: keeping one more option open
• Judgment: deciding what to protect and what to let go
• Consideration: letting the people around you know what’s happening and what comes next

3. What is Graceful Degradation?

MDN describes Graceful Degradation as a design philosophy that creates the best experience in modern browsers while still providing essential content and functionality in older browsers.

For example, instead of leaving the entire screen blank when a new API isn’t available, you can preserve the main operation using another method. The experience may be less polished, but users can still achieve their goal. That’s graceful degradation.

Microsoft’s reliability guidance also describes the idea of providing a degraded mode that preserves critical operations when a component is unavailable. Detect the failure, switch to an alternative path, and let users know what has changed. That’s all part of the design.

flowchart LR
    A[想定外の障害] --> B{重要な経路か}
    B -->|いいえ| C[非本質的な機能を縮退]
    B -->|はい| D[代替経路へ切り替え]
    C --> E[本質的な機能を継続]
    D --> E
    E --> F[状況と次の手を伝える]

The important thing is not to try to preserve everything. Decide what to cut. Decide what to keep. Azure’s Throttling Pattern, for example, describes stopping or degrading nonessential features to preserve resources for critical ones. It’s a design that gives up a complete response in favor of availability.

If you distinguish between primary operations, tasks that can be retried later, and displays that don’t directly affect users when they fail during the design stage, you won’t have to panic during an outage and choose between “stop everything” and “let everything through.”

For example, an ordering service might keep product browsing and saving items to a cart available, defer inventory recalculation and product recommendations, and hold off on payment until it can be verified safely. The priority of each operation is decided based on its purpose.

4. Don’t leave exceptions as exceptions

When writing code, it’s tempting to build the happy path first.

Unexpected Event → Panic → Crash

With this flow, the system’s job is over the moment something unexpected happens. For a person, it’s like ending a conversation as soon as plans change.

Graceful Degradation leaves a path open even after something unexpected happens.

Unexpected Event → Understand → Adapt → Respond

First, understand what happened. Next, decide what to protect. Decide. Keep. Keep only what’s essential to that goal, and switch to a different response.

You can’t do everything. Keep. Cut. Communicate.

This doesn’t mean “accept anything.” Graceful design has conditions for switching paths. For example, if the database goes down, stop writes and switch to read-only mode; if an external API is slow, return cached data.

5. Let’s write ElegantPerson.ts

In my talk, I represented human behavior in TypeScript.

interface ElegantPerson {
  composure: boolean
  consideration: boolean
  adaptability: boolean
}

function handle(event: UnexpectedEvent) {
  try {
    return respondElegantly(event)
  } catch {
    return respondWithDignity()
  }
}

This isn’t an executable implementation. Since neither UnexpectedEvent nor respondElegantly is defined, it won’t build as-is.

Even so, it makes the design questions visible. Do you have composure? Are you considerate of others? Can you change your response to fit the situation? And if your first response fails, do you have an alternative that preserves your dignity?

Unfortunately, human code can’t be type-checked before it goes into production. Inputs like lack of sleep, stress, and running out of time can arrive without warning. That’s why it’s worth thinking not about an implementation that never fails, but about what you can preserve when it does.

6. You can share grace with others

When a system degrades, notifying users is important. If the functionality changes without an explanation, users can’t tell whether something is broken or they did something wrong.

It’s the same for people. When you’re running out of room to maneuver, silently trying to handle everything on your own takes options away from the people around you.

Don’t stop. Don’t hide it.

“I can’t share the slides right now. I’ll continue verbally.”

That one sentence explains the situation and offers an alternative path. It’s not perfect. But the event can continue.

A graceful person isn’t someone who never lets anything happen. They’re someone who doesn’t hide what happened and can offer what’s possible next. They don’t just protect their own composure—they can share a little of it with the people around them, too.

7. Conclusion

We can’t eliminate the unexpected. Differences between browsers, outages of external services, and oversleeping aren’t going away.

So design ahead of time. What’s essential? How much can be degraded? Under what conditions should you switch to an alternative path? And what should you tell the other person?

Graceful Degradation is a technical term for making systems more resilient. If we use it to think about human behavior, we might put it this way:

Grace isn’t about never breaking. It’s about still having room to maneuver after things break.

I’ll start by learning how to make tea.

Stay Graceful.

References

• MDN: Graceful degradation — Definition of a design philosophy that preserves essential functionality
• W3C: HTML Design Principles — Fallbacks for older or less capable user agents
• Microsoft: Architecture strategies for self-healing and self-preservation — Degraded modes, alternative paths, and user notifications
• Microsoft: Throttling Pattern — The idea of protecting critical features by dropping nonessential ones