Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

POST: The shift-left fallacy

オープン
  • 何か問題がありますか？
#10 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
25/100
issue の種類
ドキュメント
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
markdown
領域
content

調査の方向性

この issue には記事の本文が提示されていますが、対象ファイル、エントリーポイント、テストのいずれも指定されていません。まずリポジトリの Docusaurus のコンテンツ構成とコントリビューションガイドを確認し、その後、この投稿をどこに配置すべきか、また求められている結果が公開、編集、その他のどれなのかを確認してください。

索引モデルが issue の本文から書いたものです。

説明

blog ready-to-post

The Shift-Left Fallacy: When "Earlier" Becomes the Enemy of Innovation

In software development, “shifting-left” has become one of those buzzwords that sounds undeniably smart and has been everywhere for a few years. The basic idea is this: move key activities like extensive design, testing, security, and compliance much earlier in the development cycle, i.e., shift left. That way, problems are caught sooner or supposedly eliminated, costs are reduced, and delivery becomes more efficient because you have eliminated problem at the root. Kinda like: measure twice, but cut once.

But here is the uncomfortable truth: when taken too far, shifting-left is an anti-agility trap. Instead of helping dev teams move faster and adapt, it can slow them down and stifle the creativity that grows from iteration and experimentation.

Technical debt is a free loan

A common fear pushing to promote shifting-left is that we are accumulating a so-called "technical debt", where technical debt would be the future cost of choosing an easy or fast solution now instead of a better one that would take longer to do now, creating work that must be done later, aka. a debt of future refactoring, redesign or debugging. But the twist is that in earnest, technical debt is a free loan. It lets you move faster, learn quickly, and prove value before you spend time perfecting things that might change later and void all your initial assumptions. Not getting everything right the first time is not a failure, rather it is a source of leverage! The trick is knowing when to repay that debt, not avoiding it at all costs. Premature optimization often costs more than the debt ever would to repay and in most cases, YAGNI (You Ain't Gonna Need It) anyway!

More problems with pushing everything left

Let’s say you are trying to build a new software product. Before writing a single line of code, you are now expected to draft a design, to specify all test cases, to complete a bunch of security reviews, to fill out architecture diagrams, to meet with multiple stakeholders and collect all their requirements, and to draft comprehensive documentation. You are not building anything yet, you are barely preparing to build.

Soon, that thing that was supposed to make you faster is making you crawl to a halt. Experimentation becomes risky. Iteration slows. Innovation stalls under the weight of early-stage processes, that have all been moved left.

This is what I call the shift-left fallacy: the belief that moving all tasks earlier in the timeline always leads to better results. It overlooks the critical fact that I cannot optimize and plan for something that has not taken shape yet. Unless you are a first order genius, or unless you are willing to bear all costs of such an approach upfront (which may be needed in a few cases, like when sending a rocket to Mars)... but this is not your everyday use case!

For instance, CI is not your TODO list

A common symptom of over-shifting left in the dev cycle is bloated CI pipelines (and I have built my fair share of them). In theory, running every check on every commit sounds like a wonderful idea, after all extra compute is mostly "free". But, in practice, it can be a total drag or a total waste. When each small code change triggers dozens of tests, linters, scans, and audits, and the corresponding dozen of small failures, feedback and review loops stretch out and devs wait... and wait. What should take only a few minutes now starts taking hours. Worse, I would start gaming the system by avoiding small commits entirely or delaying pushing code. That CI pipeline becomes less about confidence and much more about red tape and overhead. Not every commit needs to be a compliance or feedback event. We should use se CI to enable faster and more efficient code to flow, not to block it!

In the end, innovation comes iteration and slack

Yes, we should catch bugs early. Yes, security matters. Yes, we need documentation. (we really need that yesterday). But these things should support innovation, not slow it down.

The key is to find some balance. Shift left when you can automate and not demand extra early work, where it adds real value by removing busywork, but do not turn your dev process into a compliance checklist before the idea has not even be validated. Let you and your teams explore. Let them build. Then bring in structure at the right time to refine and protect what is worth keeping (Hint: I like to bring in structure only when this starts to be a little painful, not before ;) )

Because in the end, building awesome software is not just about moving faster. It is about moving smart, and sometimes, that means not doing everything too early. So do not fall for the sirens of shifting left for the sake of it: there could be nothing left when you've shifted it all left :)

主要言語
JavaScript
スター
9
フォーク
17
平均マージ
7時間 55分
マージ済み PR（30日）
2

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

aboutcode-org/www.aboutcode.org のほかの issue

aboutcode-org/www.aboutcode.org の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。