Shorter summary

Abhor technical debt.

Short summary

To do the whole thing right and fast, do important bits of it right, right now.

Summary

In a large, complex designed system that is developing, many elements will play key roles in the system's current and future functioning. In the short term, overhauling such a key element will require a lot of work and have little benefit. In the long term, delaying overhauling a key element causes massive cascading delays, gridlocks, and waste. Therefore to maximize longterm developmental progress, prioritize overhauling key elements.

What is OKEA?

What are key elements?

Key elements (aka "loadbearing" elements) are elements that have some combination of

1. relating to many other elements in the system; and
2. mattering a lot for the developmental process of, and/or final functioning of, the system.

Examples: Architecture. Basic building blocks. Vision of what the system should be like. Core engines.

Non-examples:

• Anything that's noncentral to the system's purpose (misses criterion 2). E.g.:
  • The specific data format of the logging files of a program. It relates to many elements in the system (getting criterion 1): any of the elements might be logged, so in principle the logging could demand that some other element be refactored to be logged more efficiently and cleanly. But logging can often be pretty rough-and-ready while doing its job, so the specific format doesn't matter much.
  • The specific axiomatization of some mathematical idea that's mainly for illustrating a more central philosophical idea.
• Anything that's already well-factored out from the system (misses criterion 1). E.g.:
  • Which font and color you use in your text editor. (It may affect your work somewhat and therefore be worth prioritizing, getting criterion 2, but it's not a key element.)
  • Some glue code. (The presence of glue code might indicate problems in the elements being glued. Some other glue code might be applied in a lot of contexts or have quirks that radiate out through applications to affect a lot of elements, and therefore is not well-factored from the system. But some glue code just relates to the few elements it glues; it might not be pretty or easily modified, but it isn't key and often doesn't need to be prioritized for overhauling.)

What is overhauling?

Majorly redesigning/replacing, refactoring, resituating (rearranging relations with other elements). In general, resolving provisionality.

Okeaing

OKEA (overhauling key elements ASA) is pronounced /oʊˈkiːə/, oh-KEY-uh. In addition to being a slogan or suggestion, it also can be a transitive verb. To okea something is to overhaul it (where it is a key element, and the overhauling is given urgency/priority). E.g. "Oh I misunderstood what you meant, in that case we should okea our visions for this project because we weren't on the same page.".

Okeaing looks like:

• Question basic assumptions. Analyze loadbearing concepts and their relations.
• If there are key forces pulling on a key element in opposite directions, refactor that element (or the forces).
• If there's a major defeater for some current configuration of the system being good, prioritize dealing with that defeater. Treat the disease, not the symptom; don't make a patch for the major defeater, start figuring out how to cure it.

Why OKEA?

Why prioritize overhauling some key element K?

• Avoid wasting time on optimizing other elements in a way that's tailored to the current version of K, since that version is wrong.
• Other elements can start coadapting sooner to the correct version of K.
• Get more data about what possible versions of K there are, and what are the implications for realizing a given possible version of K.
  • See what other key elements tend to break, even if they were fine given specifically the current configuration of the key element in question. You might not even have been aware that some E was importantly related to K.
  • See what demands are being made of K, that a replacement for K should meet.
  • See what doesn't break about K and its context--this might be more stable, more likely to be in future versions of K.
  • See how K and its context fail to work, no matter what you try. This points at what is potentially another key element--whatever it is that makes K and its context always fail--which is even more urgently in need of overhauling lest key relations with already-salient elements be swept under the rug.
• There's a bias toward not okeaing. Out of cognitive miserliness, or wanting to feel productive, or lost purposes, or whatever, we tend to want to stay within the background context of whatever activities we currently do day-to-day. For ambitious purposes, people seem to usually correct for this bias too slowly.

Why not OKEA?

It's hard and complicated, takes work, requires foresight into unknown territory, and can cause infectious questioning.