親愛なる友人へ、
いかがお過ごしですか？
全てはトレードオフであるとは言え、私には判断を躊躇してしまう要素・特性があります。1つはセキュリティです。セキュリティの重要性を適切に判断したり認識したりすることは実際に攻撃されるまでは難しく、セキュリティという特性は軽視される傾向にあり、そのため判断には慎重にならざるを得ません。過剰とも言えるような量の材料や証拠を集めてからトレードオフを分析し判断する必要があることは、あなたもご存知でしょうし、実際に体験したことがあるかもしれません。そして、もう1つの躊躇してしまう要素が、
重厚なフレームワークを使うこと
です。
RailsもSpring Bootも重厚なフレームワークで、これがWeb開発で支配的だった時期があり、そして、未だに支配的である領域や企業もあります。もちろん、重厚なフレームワークは多くのことを考えずに済んでMVP開発に有利だったり、ジュニアなエンジニアでも比較的素早く開発することができたり、と、いろいろな利点があります。しかし、それでも私は躊躇います。技術的な観点から見て、脆弱性の混入の容易さや、ビルド時間の長さ、バージョンアップへの追従の困難さ、といった技術的な理由がたくさんあり、そして取り上げ続けることは簡単です。しかし、何よりも重要で、そして、今挙げた技術的な要素を含むものが、耐時間性です。
この世のありとあらゆるものは、時間に対して無力です。あらゆる物もサービスも、そして貨幣すらも、時間に対しては無力です。というのも、この世のすべてのものは、
時が経つにつれて、価値が下がる
からです。貨幣は発行すればするほど、その一単位あたりの価値は下がります。サービスも、市場やユーザーの変化によって機能のフィット具合は減少し、それによって価値は下がります。ソフトウェアにおいても、コードベースの増大に伴って、リリースサイクルの時間は伸び、価値が下がります。時間への耐性が完全にある、というものはこの世には存在しないと言えるでしょう。あくまでも耐時間性が強いか弱いか、ということを語れるのみです(唯一、耐時間性が完全にあるのは「壊れないセンテンス」でしょう)。ここでは、「時が経つにつれて、価値が下がるスピードの遅さ」というのを「耐時間性」と私は呼ぶことにします。
重厚なフレームワークというのは、その重厚さ故に、耐時間性が著しく弱く、つまり、価値の減少スピードが速いです。だから、重厚なフレームワークの選択を私は躊躇します。もし選択の候補に上がっても、撤退ラインの設定をし、その撤退ラインに達するまでに価値を提供できるか、といったトレードオフの分析を要求します。しかし、この時の判断が、その撤退ラインに達するまでの間に、忘却されたり、判断が覆されたり、守られ続けなかったり、ということは生じます。実際、三層スキーマが支配的だった時に、Java の Object 全てにシリアライゼーションが導入されましたが、その時の判断はどうであって、その後はどうなったのでしょうか？ 良かれと思って導入したものが有効でなくなった後、何年間にも渡り、もうデファクトではなくなったにも関わらず三層スキーマのために、開発者を苦しめ続けています。重厚なものの導入による長期的な影響は未知数であり、判断した時に設定されていたであろう撤退ラインは守られないことがしばしばあります。
重厚なフレームワークは、その重厚さ故に、扱うのはEasyではありますが、上述の事例からも分かるように、その実、経済的にはHardと言わざるを得ません。私がこう語っている間に、あなたも次のフレーズを思い出してきたでしょう。"Simple is not Easy"というフレーズを。
重厚なフレームワークと違って、Simpleな薄いフレームワークを扱うのはEasyではありません。熟達を要求し続け、時としては歯ぎしりすることも要求します。しかし、Simpleなもの故に、余計なものは入っておらず、Buildも手軽で、キャッチアップも容易です。そして、Simpleさを維持すれば(これがまた難しいですが)、そのフレームワークの変化に限らず、市場やユーザーの変化にも対応しやすいです。つまり、
Simpleであるならば、耐時間性がある
ということです。重厚なフレームワークの採用に伴う判断および撤退ラインが守られないのがほとんどですから、その価値の減少スピードに対して無自覚な状況下では、その価値の減少スピードを遅くしやすい、耐時間性の強いものを選ぶべきです。
"Simple is not Easy"というフレーズは単純ではありますが、理解するためには一定の経験や修練が求められます。今回私が語ったこと、つまり、Simpleならば耐時間性が強い(時間の変化に伴う価値の減少スピードが遅い)ということが真であるならば、その選択に耐時間性がないならばその選択はSimpleではない、ということになります。このことは"Simple is not Easy"とは何かを理解する助けになる可能性があります。もし、Simpleとは何かで悩んでいる人や、説明することに悩んでいる人が近くにいたら、このことを問いかけてみてください。
アーキテクチャに正解も間違いもなく、全てはトレードオフです。耐時間性もトレードオフの対象です。しかし、時間というのは残酷で、その耐時間性についての判断についての価値すらも減じます。そうであるなら、耐時間性の強い、時が経つにつれても価値の減少具合の少ない選択をするべきです。そして、Simpleなものは耐時間性があります。だから、薄いもの、Simpleなものを選ぶ傾向性が私にはあり、そして、それを勧めてしまいます。
しかし、SimpleなものはEasyではありません。しかし、その見返りは大きいです。
もし、Simpleなものか、not Simpleなものか、薄いものか、重厚なものかで選ぶのを悩んだ時は、耐時間性がどうかを考えてみてください。そして、いずれを選んだにせよ、その選んだ理由を書き留め、忘れないようにしてください。そして、理解が進んだり変わったりしたならば、私を含む、他の人に共有してください。
それでは、
青を心に。
Stephen S. Hanada
"Gentleman Philosopher"
---
Dear Friend,
How have you been?
While everything in life is a trade-off, there are certain elements and characteristics that make me hesitate when it comes to making a judgment. One is Security. It is difficult to appropriately judge or recognize the importance of security until an actual attack occurs. As a result, this characteristic tends to be undervalued, forcing me to be exceptionally cautious in my decisions. As you likely know or have experienced yourself, one must often gather what seems like an excessive amount of data and evidence before analyzing the trade-offs and reaching a conclusion.
And there is another element that makes me hesitate:
The use of heavy, "weighty" frameworks.
Frameworks like Rails and Spring Boot are heavy frameworks that once dominated web development—and in certain domains or enterprises, they still do. Of course, they offer many advantages: they allow you to build without worrying about the underlying complexity, which is beneficial for MVP development, and they enable junior engineers to develop relatively quickly. Yet, I still hesitate. From a technical standpoint, it is easy to list reasons: the ease with which vulnerabilities can be introduced, long build times, and the difficulty of keeping up with version updates.
However, what is more important than any of these—and indeed encompasses all these technical factors—is Time-Resistance.
Everything in this world is powerless against time. Every object, every service, and even currency itself is helpless in the face of time. This is because everything in existence
loses value as time passes
. The more currency is issued, the less value a single unit holds. Services lose their "fit" as markets and users change, causing their value to decline. In software, as the codebase grows, release cycles lengthen and value drops. It can be said that nothing in this world possesses absolute resistance to time. We can only speak of whether something has "strong" or "weak" time-resistance. (Perhaps the only thing with perfect time-resistance is a "sentence that never breaks.") Here, I define "Time-Resistance" as "the slowness of the speed at which value decreases over time."
Heavy frameworks, by virtue of their weightiness, have remarkably weak time-resistance; in other words, their value diminishes rapidly. This is why I hesitate to choose them. Even if they are considered as candidates, I demand a trade-off analysis that includes an "exit strategy" (a withdrawal line) and whether value can be delivered before that line is reached. However, the reality is that the judgments made at that moment are often forgotten, overturned, or simply not upheld by the time that exit strategy becomes relevant.
Consider what happened when the three-schema architecture was dominant and serialization was introduced to every Java Object. What was the reasoning then, and what happened afterward? Something introduced with good intentions continued to torment developers for years because of that three-schema architecture, long after the approach had ceased to be the de facto standard. The long-term impact of introducing something "heavy" is an unknown quantity, and the exit strategies set at the time of the decision are often ignored.
Heavy frameworks are "Easy" to handle precisely because of their weight, but as the examples above illustrate, they are economically "Hard." As I say this, you likely recall the phrase: "Simple is not Easy."
Unlike heavy frameworks, handling a "Simple," thin framework is not Easy. It demands constant mastery and, at times, requires you to grit your teeth. However, because it is Simple, it contains no fluff; builds are lightweight, and catching up is straightforward. Furthermore, if you maintain that Simplicity (which is a challenge in itself), you can adapt more easily not only to changes in the framework but to changes in the market and your users.In short:
If it is Simple, it possesses Time-Resistance.
Since the judgments and exit strategies associated with adopting heavy frameworks are almost never upheld, in an environment where people are unconscious of the speed of value depreciation, one should choose something with strong Time-Resistance—something that makes it easier to slow down that loss of value.
The phrase "Simple is not Easy" is straightforward, but understanding it requires a certain level of experience and discipline. If what I have said today is true—that being Simple means having strong Time-Resistance (a slow speed of value depreciation over time)—then it follows that if a choice lacks Time-Resistance, it is not Simple. This realization may help in understanding what "Simple is not Easy" truly means. If there is someone near you struggling with what "Simple" is, or how to explain it, please try asking them this.
In architecture, there are no right or wrong answers; everything is a trade-off. Time-Resistance is also subject to trade-offs. However, time is cruel, and it even diminishes the value of the judgments we make regarding Time-Resistance itself. If that is the case, we should make choices that have strong Time-Resistance—choices whose value decreases as little as possible as time passes. Simple things have Time-Resistance. This is why I tend to favor thin, simple things, and why I find myself recommending them.
Simple is not Easy. But the rewards are great.
When you are torn between something Simple or something not Simple, something thin or something heavy, think about its Time-Resistance. And whatever you choose, write down your reasons so you do not forget them. Then, as your understanding grows or changes, please share it with others—including me.
Best Regards,
Think Blue
Stephen S. Hanada
"Gentleman Philosopher"