Coder Legion - Recent posts tagged project_management

Planning for Plan Continuation Bias: How to Keep Building the Right Thing

Wed, 07 Oct 2026 17:08:45 +0000

Many of the software projects that go wrong go wrong through misalignment. They solve a need nobody had, accept tradeoffs nobody weighed, or carry risks nobody examined. PMI's 2014 survey of more than 2,000 practitioners put poor requirements management behind almost half of projects that missed their goals. Alignment isn't a phase that ends when the work starts. Every plan, discovery, commit, and test is a chance for the work to drift away from what it was meant to accomplish, and a chance to pull it back.

Pulling it back requires something most advice skips over. You have to stop. For years, I couldn't. When a better idea surfaced mid-implementation, my first instinct wasn't to evaluate it but to finish what I was doing. By the time I finished, the switching costs had mounted and the moment for cheap redirection had passed. It was rarely pride, just a pre-rational impulse to proceed, as though stopping mid-stride carried some cost that continuing didn't.

What changed it for me was learning to think about work in terms of business value and to treat my own direction as an assumption to test rather than a plan to complete. I stopped being a code cowboy. The impulse didn't disappear, though, and it isn't mine alone. It has a formal name, and it explains why realignment so often fails to happen.

Continuing Wins Because It Takes Less Thought

Pilots call it get-there-itis. Researchers call it plan continuation bias. Judith Orasanu and colleagues at NASA's Ames Research Center went through the tactical decision errors in the 37 accidents covered by the NTSB's 1994 review of flightcrew-involved major accidents. Of the 51 tactical decision errors in that corpus, 38 were decisions to continue the original plan despite cues suggesting a different course of action.

The ratio isn't a pure measure of bias. The sample counts only flights that ended in accidents, so nobody knows how often crews continued in similar conditions and landed safely. Crews also choose to continue far more often than to divert, so continuing has more chances to go wrong. What the cases do show is crews who had the cues calling for a change and carried on anyway.

Orasanu's team locates much of the cause in effort rather than stubbornness. Revising your understanding of a situation and working out a new course of action costs more cognitive work than continuing with a plan whose details are already settled. People tend to take the cheap operation when it's available. Workload, time pressure, and ambiguous signals all shrink the budget for the expensive operation at exactly the moment it's needed. The original plan doesn't win the argument. It wins by default, because it never has to have one.

The stakes and the minute-by-minute time pressure don't transfer to software, but the default does. Revising a plan still takes more thought than continuing it, and the budget for that thought still shrinks under deadlines and under commitments other people have built on. There is evidence for this at the scale of whole projects. Mark Keil's 1995 case study of a runaway software project found a failing course of action kept alive by project, psychological, social, and organizational factors together. Nobody has measured the single-task version. It rests on the same mechanism.

What software lacks is the warning. A pilot pressing into weather has minutes and no undo. A developer pressing on with the wrong approach has weeks, git can undo any of it, and the work ends the way good work does, reviewed and merged. The pilot who got away with it at least knows it was close. The developer rarely learns there was anything to get away with. When the cost does arrive, it arrives months later as slow delivery or a rewrite, blamed on tech debt rather than on the choice. So the software version of the bias seldom corrects itself.

Our own advice makes it worse. "Finish what you started" is plan continuation bias repackaged as a character virtue. It assumes that what you started should be finished, which is exactly the question the bias keeps you from asking. That isn't the Kanban rule of limiting work in progress, which stops new work from starting and says nothing about whether the current work is right. "Think before you act" assumes the thinking was sound, and once you've thought and decided, the decision has inertia. The problem was never acting without thinking. It's acting without reconsidering.

The Impulse Shows Up at Every Stage

Each stage of software work has its own version of the impulse, and each one lets the work drift a little further from the need before anyone looks up. Planning and discovery are the worst offenders, because the decisions made there shape everything built afterward, and their misalignment stays invisible the longest.

Planning: The First Workable Design Becomes the Plan

A plan is supposed to come from weighing options against the need, the tradeoffs, and the risk. Under the impulse, the plan is the first design that seemed workable, and the weighing never happens. Once that design is written into tickets, estimates, and a roadmap, it has momentum before a line of code exists. A team that sketches a synchronous integration in a kickoff meeting, estimates it, and schedules it rarely circles back to ask whether its behavior under failure fits the business's tolerance for delay. Questioning it now means reopening commitments other people rely on, so the plan proceeds unchallenged and its misalignment ships inside every task built from it.

Discovery: New Information Gets Filed as "Later"

Discovery is when the work learns something the plan didn't know: a requirement nobody mentioned, a constraint in a system you integrate with, users who behave differently than assumed. That is the moment realignment exists for, and it's the moment the impulse is strongest, because acting on the discovery means stopping work already in motion. So the discovery becomes a follow-up ticket, a tech-debt item, or a note for the retrospective. It's acknowledged without being acted on, and the work continues against a picture of the need that is now known to be wrong. Deferring is right when a discovery doesn't change the direction, and it's the bias when the discovery would have.

Coding: "Let Me Just Get This Working First"

This is the version I see most in newer developers, and they make it constantly. Finishing first and then reevaluating sounds like sequencing rather than avoidance. The plan is to weigh the other approach once this one works. Then you spend another hour building out the current approach. You write tests around it. Other code starts depending on it. A colleague reviews it and builds understanding of how it works. At that point, "considering the other approach" means throwing away not just your work but the organizational investment in reviewing, understanding, and integrating what you've built.

The impulse to finish manufactures the very sunk costs that now appear to justify not switching. That is what makes the bias self-sealing. Ordinary sunk-cost reasoning is a mistake about money you already spent. This one does the spending itself, then cites the receipt.

Barry Staw's 1976 study Knee-Deep in the Big Muddy found that people who feel personally responsible for an initial decision commit more resources to it when it starts failing, not fewer. Among participants who received the same news of failure, the ones who had made the original decision themselves invested more, so the escalation tracked authorship of the decision rather than evidence about it. In software, this looks like the developer who hits a warning sign, such as a test that only passes with a workaround. They spend two more days making the approach work rather than an hour checking whether a different one would be simpler.

Sometimes getting it working first is the right test, because some approaches can't be judged until something runs. A spike has a time box and an agreement to throw it away, so it tests the approach. "Let me just get this working" has neither, so it builds on the approach.

Testing: Proving Instead of Testing

Proving asks "can I make this work?" and the answer is almost always yes given enough effort. Testing asks "should I be making this work?" and that's the question alignment depends on. The impulse turns testing into proving.

Tests written after the approach is settled check that the code does what its author intended, and rarely whether what the author intended is what the need required. A green suite then reads as confirmation of the direction, when all it confirmed was the implementation. Tests that come from the need before the approach is chosen, such as a check against the business's tolerance for delay, are the ones built to fail a direction. Without them, the current assumption gets the full weight of implementation and verification, while the alternative gets a hypothetical conversation, maybe, later, if there's time.

A Team's Momentum Feels Like Validation

The group version is worse, and it doesn't work the way most people assume.

The familiar picture of groupthink is dissent being actively suppressed. That happens, but I'd argue a subtler and more passive version also exists, and it's harder to see. Nobody explicitly validated the direction. Nobody consciously suppressed alternatives. Everyone just assumed that someone else must have validated it, and the group's momentum itself became evidence that the direction is correct.

This shares something with the bystander effect, where responsibility diffuses until nobody acts, but it runs a step further. Diffused responsibility explains why nobody checked. Momentum read as confirmation explains why nobody felt the need to.

Questioning the direction doesn't just feel unproductive. It feels like you're slowing the team down, which in most team cultures marks you as the obstacle rather than the one asking the right question. From the inside, speed is indistinguishable from conviction.

Orasanu's team didn't isolate momentum, but their data does show social pressure feeding the bias. Alongside ambiguous conditions, they named organizational and socially-induced goal conflicts as the second context that contributes to plan-continuation errors. So the group is more than a second instance of the bias. It's one of the conditions that feed it.

Process Decides Which Direction Is Free

Most methods for keeping work aligned assume that when discovery arrives, someone will notice and act. None of them do the registering for you.

Fixed Intervals Put Correction at the Far End

Any cadence that commits a group to a fixed goal or set of work for a fixed window places the routine moment for changing direction at the end of that window. In a two-week sprint, the review is the official place to say the plan was wrong, and by the time it arrives two weeks of sunk cost have accumulated. The correction point sits exactly where the bias is strongest.

Scrum is not blind to this. The Scrum Guide fixes the Sprint Goal rather than the scope, and the Daily Scrum adapts the plan toward that goal every day. A Product Owner can cancel a sprint, and the sprint boundary itself is a replanning point. But daily adaptation serves the goal rather than questioning it, and cancellation is a lever someone has to decide to pull, which is the very decision the bias suppresses. The standup, as many teams run it, has each person report progress against work already committed, which quietly rewards continuation every morning. It is part of what the framework trades for predictability.

Some Processes Make Stopping the Default

Basecamp's Shape Up is organized around three moves that make a discovery cheaper to act on. A circuit breaker means unfinished work expires by default instead of receiving an extension, so stopping requires no argument from anyone. An appetite fixes the time and varies the scope, which makes dropping part of a plan an ordinary decision rather than an admission of failure. Shaping before committing means less has been invested at the moment the "this isn't right" signal arrives, giving the signal a chance to compete with momentum.

What matters about a process is which direction it makes free, and a sprint and a circuit breaker pull in opposite directions. The Scrum Guide returns unfinished work to the backlog, but nothing stops the next planning session from pulling it straight back in, and the work already done argues for exactly that. Under a sprint, stopping has to be argued for. Under a circuit breaker, expiry is the default, so continuing has to be argued for. Shape Up's six-week window is longer than a sprint, so its advantage comes from the default, not from stopping sooner.

Circuit breakers trip only at defined boundaries, so they miss the smaller discoveries between them, like the "this approach isn't quite right" signal on a Tuesday afternoon that the impulse to finish overrides.

What Helps When Awareness Isn't Enough

Knowing about the bias doesn't prevent it, because the impulse operates faster than reflection. What worked for me wasn't trying harder to notice. It was changing what I thought the work was. Once each task was a bet on delivering some business value, my approach to it became an assumption about how to deliver that value, and assumptions get tested. A plan you treat as a commitment pulls you toward finishing it. A plan you treat as an assumption pulls you toward checking it. Reframing changes what stopping feels like, but the impulse stays, so the moments to stop still have to come from structure.

Checking a Doubt Costs Less Than Building on It

For most people, stopping feels like failure or waste. You were making progress and now you're not. But once a doubt has surfaced, evaluating it is usually cheaper than building more on top of it, and seeing it that way changes the emotional calculus even when the impulse is still there.

Low Switching Costs Keep the Signal Audible

The impulse draws power from switching costs that accumulate with every hour of continued execution. Cheap experiments before commitment, small commits, well-defined interfaces, and feature flags all keep the cost of being wrong low for as long as possible.

A Fixed Rhythm Beats Waiting for Permission

The Pomodoro technique was designed for productivity, but it accidentally created the kind of permission structure this bias requires. Every 25 minutes, you stop. That forced pause is a moment where "am I still working on the right thing?" can be asked without the social or psychological cost that usually prevents reassessment. The technique puts nothing about direction into the break, though, so the pause needs a switch criterion, written in advance, to check against. Events can trigger the same check, like a test that needs a workaround or an estimate that overruns.

The natural objection is that these pauses cost working hours that would otherwise ship something. A check against a criterion written in advance is usually quick, though, and a doubt too big to check quickly deserves the time. Four hours of uninterrupted coding on a misunderstood problem doesn't produce the right solution, and the context-switching argument can't tell that case apart from the one where the four hours were well spent. Breaking focus on work you understood throws away context you had built. Breaking focus on work you hadn't examined throws away nothing you would want to keep.

The Stop Test

The pause only helps if something happens inside it. The person asking whether to switch is usually the one who made the original decision, and Staw's finding predicts they'll lean toward their own choice. Itamar Simonson and Barry Staw later tested ways to counter that, and one that worked was setting, in advance, a minimum target that triggers a change if it isn't met. So before starting, write down what result, cost, or discovery would make you switch, and which assumptions the plan depends on, so an unexpected discovery has something to contradict.

That puts the criterion before the sunk cost exists and gives every pause something to check against. It also guards against the opposite mistake, switching whenever a new idea merely feels better. The stop test is then three questions for the pause, answered against what you wrote down, ideally by someone who didn't make the original call:

Am I proving or testing? Can this be made to work, or should it be?
Is switching getting more expensive while I keep going? Compare what you would throw away by switching now with what you would have thrown away an hour ago. If that pile keeps growing while the doubt sits unresolved, you are building the sunk cost that will later argue against switching.
If I hadn't already started, would I choose this approach today? This is Peter Drucker's question from The Effective Executive, "If we did not already do this, would we go into it now?", scaled down from a program to a single task. A no here is the entire signal. Everything after it is negotiation with sunk cost.

Alignment Depends on the Ability to Stop

You can't realign after discovery if you can't stop long enough to receive the discovery. You can't weigh a tradeoff you never paused to see, or catch a risk while you're busy proving the approach works. Alignment isn't something you achieve at kickoff. You recover it at every plan, discovery, commit, and test, and each recovery starts with a stop.

So the work isn't only to try harder at noticing. The work is to arrange things so that stopping doesn't wait on noticing:

Rhythms that pause whether or not anything looks wrong, and check against criteria set before the work began
Boundaries that expire on their own
Commitments small enough that changing your mind costs less than defending it

Build those, and the moment you would otherwise have missed arrives on a schedule that isn't yours to override.

Best Link Management and Link Cloaking Plugins for Affiliate Marketers

Wed, 30 Sep 2026 17:16:40 +0000

Affiliate marketing can begin with only a few product links, but managing those links becomes considerably harder as a website grows. A publisher may eventually work with dozens of merchants, multiple affiliate networks, different tracking IDs, regional storefronts, and hundreds of articles. Editing every destination URL manually can become a major maintenance task.

Link management plugins address that problem by creating a central location for affiliate URLs. Instead of placing long affiliate addresses directly throughout website content, publishers can create manageable links on their own domain, organize them into categories, track clicks, replace destinations, and identify broken URLs.

Link cloaking is one part of this process. Depending on the tool and redirect method, cloaking can make an affiliate URL shorter and easier to recognize while keeping the underlying destination out of the visible link. However, affiliate marketers need to understand that cloaking is not automatically permitted by every merchant or affiliate program. Pretty Links, for example, specifically warns that some affiliate networks prohibit cloaking, masking, or iframe-based presentation.

For WordPress publishers, several plugins and platforms stand out because they combine link organization with features designed for affiliate marketing.

What Is Affiliate Link Management?
Affiliate link management is the process of storing, organizing, monitoring, and updating affiliate URLs from a central system.

A typical affiliate URL can contain tracking parameters, campaign identifiers, product IDs, or referral information. A direct URL might be difficult to remember and inconvenient to replace across dozens of articles.

A link management plugin allows the publisher to create a shorter internal URL such as:

yourwebsite.com/go/product

That internal address can then redirect visitors to the affiliate destination.

The major advantage is centralized control. If a merchant changes a product page, the publisher can update the destination in the link manager instead of searching through every article containing the old URL.

Modern affiliate link managers can also provide click tracking, link categorization, automatic link insertion, geographic redirects, broken-link monitoring, and other tools. ThirstyAffiliates, for example, provides centralized affiliate link management, click tracking, categories, geographic redirects, automatic 404 checking, and scheduled promotional links.

What Is Link Cloaking?
Link cloaking generally refers to presenting an affiliate URL through a shorter or branded URL rather than displaying the complete destination address.

There is an important distinction between simple link shortening and technical URL masking.

Pretty Links explains that shortened redirect URLs are commonly described as cloaked links because the original affiliate URL is hidden behind a shorter address. It also offers a separate cloaked redirect that uses an iframe to keep the destination URL out of the browser's address bar.

For most affiliate websites, the simpler redirect approach is easier to manage and less likely to create compatibility problems. Publishers should always check the rules of each affiliate program before cloaking its links.

Pretty Links
Pretty Links is one of the established WordPress tools for creating, managing, and tracking shortened URLs.

The plugin is useful for publishers who want to keep affiliate links under their own website domain. Instead of exposing a long merchant URL in an article, a publisher can create a cleaner internal address and use the plugin to control the destination.

Pretty Links supports several redirect approaches. Its documentation distinguishes between ordinary redirects and its dedicated Cloaked redirect. The dedicated Cloaked option loads the destination through an iframe, while 301, 302, and 307 redirects provide other ways to route visitors. Pretty Links itself recommends considering standard redirect methods rather than iframe cloaking for many affiliate marketing situations.

This makes Pretty Links particularly useful for publishers who want control over their site's outbound URLs rather than relying on a separate URL-shortening service.

It can also be useful beyond affiliate marketing. Publishers can use managed URLs for campaigns, downloadable resources, social media destinations, email campaigns, and other external resources.

Who should consider Pretty Links?
Pretty Links is suited to WordPress publishers who want branded short URLs and centralized control over redirects. It is especially relevant for websites that use affiliate links throughout a large archive of articles and need the ability to modify destinations without editing every individual post.

ThirstyAffiliates
ThirstyAffiliates is designed specifically around affiliate link management rather than general-purpose URL shortening.

Its current feature set includes link categorization, click tracking, automatic 404 checking, geographic redirects, automatic link insertion, and Amazon-specific tools. The platform also supports importing affiliate links from multiple programs into the WordPress dashboard.

One practical advantage is centralized organization. A publisher working with Amazon, CJ Affiliate, Impact, ShareASale, Awin, or individual merchant programs can keep links in one WordPress-based library rather than maintaining separate spreadsheets for every program.

The automatic 404 checker is also relevant to affiliate publishers. Broken affiliate URLs can remain unnoticed inside older articles, particularly on websites with large content archives. ThirstyAffiliates says its automatic checker identifies affiliate URLs returning 404 errors so publishers can replace them.

The platform also provides smart uncloaking for Amazon links, which is important because Amazon Associates has specific requirements governing how affiliate links are presented. ThirstyAffiliates says its Amazon tools can keep applicable Amazon links uncloaked while other affiliate URLs remain managed through the platform.

Who should consider ThirstyAffiliates?
It is particularly relevant to publishers operating large affiliate websites where organization, monitoring, automated linking, and program-specific requirements matter as much as simple URL shortening.

Lasso
Lasso takes a broader approach by combining affiliate link management with tools for identifying and maintaining monetization opportunities.

Lasso provides a centralized dashboard for importing, organizing, and managing affiliate links. Its platform also provides link health alerts for broken links, products that go out of stock, or pages that change.

The service can create short and branded links, including links using a publisher's own domain. Its WordPress integration allows publishers to insert managed affiliate links and displays directly into their content.

Another useful feature is the ability to change the primary destination URL without replacing the managed link throughout existing content. If a product becomes unavailable or a publisher changes its recommendation, the destination can be updated from the Lasso interface.

Lasso also supports importing existing affiliate links from other WordPress plugins, link cloakers, CSV files, and affiliate links already present on a website.

Who should consider Lasso?
Lasso is aimed at publishers who want more than basic link redirection. It is particularly relevant to affiliate sites with extensive product content where link health, product availability, content monetization, and centralized management are important.

Easy Affiliate Links
Easy Affiliate Links is a WordPress plugin that provides a simpler approach to affiliate link organization.

The plugin supports both cloaked and non-cloaked affiliate links and automatically tracks clicks. It works with the Classic Editor and Gutenberg, and it can also be used with Elementor's text widget.

Publishers can categorize links, import and export them through XML and CSV files, and track monthly and lifetime click counts. The plugin also supports sponsored and user-generated-content link attributes.

One particularly useful feature is the ability to leave selected links uncloaked for Amazon compatibility. That gives publishers greater control over how individual affiliate URLs are presented instead of applying one approach to every link.

Its premium add-on extends the feature set with tools such as broken-link checking, email notifications, conditional geographic or device targeting, replacement links, and Amazon Creators API integration.

Who should consider Easy Affiliate Links?
This plugin is worth considering for WordPress publishers who want a straightforward link library without necessarily adopting a larger affiliate management platform.

Key Features to Compare
Choosing a link management plugin should depend on how an affiliate website operates.

Feature

Why It Matters

Link cloaking

Can provide shorter, cleaner affiliate URLs where permitted

Redirect management

Allows destinations to be changed centrally

Click tracking

Helps publishers monitor link activity

Link categorization

Keeps large affiliate libraries organized

Broken-link monitoring

Helps identify URLs that may no longer work

Geographic redirects

Can route visitors to appropriate regional destinations

Automatic linking

Reduces repetitive manual insertion

Import and export

Makes migration and bulk management easier

Amazon-specific controls

Important for publishers participating in Amazon Associates

Custom domains

Allows links to use the publisher's own domain

Not every publisher needs every feature. A small niche website may only need short URLs and basic tracking, while a large affiliate operation may require link health monitoring, geographic routing, automatic insertion, and centralized reporting.

Link Cloaking Is Not a Substitute for Compliance
One of the most important considerations is affiliate-program compliance.

A cleaner URL does not override the rules of the merchant or affiliate network. Some programs have restrictions concerning redirects, cloaking, tracking parameters, disclosure, or how affiliate links are presented.

Pretty Links specifically notes that some affiliate networks prohibit cloaking, masking, or iframe-based presentation.

Amazon is another important example because its affiliate program has specific requirements. Tools such as ThirstyAffiliates and Easy Affiliate Links provide options for keeping applicable Amazon links uncloaked.

Publishers should therefore treat compliance as a requirement at the individual affiliate-program level. Before activating a cloaking feature, check the current terms of the relevant network or merchant.

Why Centralized Link Management Matters
The main advantage of these plugins is not simply making URLs shorter.

The bigger benefit is centralized control.

Consider a website containing 500 articles and dozens of affiliate recommendations. If a merchant changes a product URL, a direct-link approach may require searching the website for every occurrence. With centralized management, the publisher can update the destination from the link manager.

This becomes even more important when an affiliate website has multiple contributors. A standardized link library reduces the likelihood that writers will paste inconsistent affiliate URLs into different articles.

Centralized management can also make performance analysis more practical. Instead of treating every hyperlink as an isolated element, publishers can organize links by merchant, product category, campaign, or website section.

How to Choose the Right Plugin
The right choice depends on the website's size and monetization model.

A publisher primarily interested in branded redirects may prefer a general link management solution such as Pretty Links.

A publisher whose workflow revolves around affiliate URLs, categories, tracking, automatic insertion, and affiliate-specific tools may consider ThirstyAffiliates.

A larger affiliate operation focused on product content, link health, and broader monetization management may find Lasso more appropriate.

Publishers looking for a simpler WordPress-based option can consider Easy Affiliate Links, particularly if CSV import and export, link categorization, click tracking, and flexible cloaking controls are priorities.

The decision should also account for compatibility with the affiliate programs being used. A feature that works perfectly for one merchant may violate the requirements of another.

Final Considerations for Affiliate Marketers
Link management becomes increasingly important as an affiliate website grows. Long URLs scattered throughout hundreds of articles are difficult to maintain, while a centralized link system gives publishers greater control over destinations, tracking, organization, and maintenance.

Pretty Links, ThirstyAffiliates, Lasso, and Easy Affiliate Links approach the problem from somewhat different directions. Pretty Links emphasizes managed URLs and redirects, ThirstyAffiliates focuses heavily on affiliate-specific management, Lasso combines link management with broader monetization and product tools, while Easy Affiliate Links provides a more straightforward WordPress solution with both cloaked and non-cloaked options.

For affiliate marketers, the most important consideration is not simply whether a plugin can hide a long URL. The useful question is whether the system gives the publisher reliable control over affiliate destinations while supporting tracking, maintenance, organization, and the requirements of each affiliate program.

Before deploying any cloaking or redirect configuration, verify the current terms of every affiliate network and merchant involved. A clean link is useful, but maintaining valid tracking and program compliance is essential to protecting affiliate revenue.

Membangun Dashboard Monitoring Proyek Konstruksi dengan Python + FastAPI: Progress, RAB, dan Lapor

Tue, 24 Feb 2026 03:52:49 +0000

Dalam konstruksi modern, masalahnya jarang pada kurang data—yang sering terjadi adalah data terpencar: progres di lapangan ada di form harian, biaya ada di spreadsheet, material dan alat berat ada di catatan berbeda. Tren integrasi software konstruksi juga bergerak ke arah sistem yang saling “ngobrol” lewat API agar keputusan bisa diambil lebih cepat dan lebih akurat. Itulah kenapa gagasan dashboard monitoring proyek konstruksi makin relevan ketika kita ingin menyatukan progres, RAB, dan laporan harian ke satu sumber kebenaran (single source of truth), selaras dengan pembahasan tren integrasi pada artikel Construction Software Integration Trends for 2026.

Dari sisi ilmiah, pendekatan real-time tracking dan visualisasi data lintas komponen proyek juga terbukti krusial untuk mengurangi keterlambatan notifikasi dan keputusan berbasis “feeling”. Studi Real-Time tracking and analysis in construction projects membahas tantangan data multi-sumber (BIM, platform manajemen proyek, jadwal, dan data site) serta dampaknya pada analisis proyek. Karena itu, tema ini layak diangkat untuk pembaca CoderLegion: bukan sekadar “bikin dashboard”, tapi membangun fondasi API yang rapi—yang bisa dipakai ulang untuk otomasi laporan, integrasi ERP, sampai project intelligence berbasis data.

Kesimpulan cepat: Dashboard yang “bagus tampilannya” belum tentu berguna. Yang membuatnya benar-benar dipakai adalah data pipeline yang bersih, API yang konsisten, dan definisi metrik yang disepakati sejak awal—baru setelah itu visualisasi jadi senjata.

1. Dari Laporan Harian ke API: Kenapa FastAPI Cocok untuk Proyek?

Bayangkan setiap site punya cara masing-masing untuk melaporkan progres: foto, catatan WhatsApp, Excel, atau form manual. Ketika semua itu masuk ke satu backend berbasis API, Anda dapat memvalidasi, menyatukan format data, dan mengekspor ke dashboard dengan ritme yang konsisten. FastAPI cocok karena cepat, modern, dan punya automatic docs (OpenAPI/Swagger) yang memudahkan kolaborasi lintas tim.

Apa yang Dimaksud “Monitoring” di Proyek Konstruksi?

Monitoring yang sehat itu bukan sekadar “berapa persen selesai”. Praktiknya biasanya memadukan:

Progress fisik: volume pekerjaan (m³, m², meter lari), bobot item, earned value sederhana.
Biaya: realisasi vs RAB, komitmen PO, biaya alat berat.
Produktivitas: output per jam/shift, downtime.
Kualitas & HSE: temuan, near miss, checklist.

Prinsip Desain API yang Bikin Dashboard Tidak “Berantakan”

Sebelum menulis endpoint, biasakan satu prinsip: dashboard itu “makan” data yang konsisten.

Gunakan resource-oriented endpoint: /projects, /daily-reports, /cost-ledger.
Tentukan versi API sejak awal (/v1/...).
Standarisasi format tanggal, timezone, dan unit.

Bacaan internal yang relevan untuk memperkuat “cara berpikir API”:

2. Arsitektur Minimalis yang “Siap Dipakai”: Data, Layanan, dan Dashboard

Agar artikel ini tidak berakhir di level konsep, kita bikin arsitektur yang realistis untuk tim kecil: satu API, satu database, dan satu layer agregasi untuk dashboard. Targetnya sederhana: dashboard monitoring proyek konstruksi yang dapat menampilkan progres, ringkasan biaya, serta laporan harian.

Komponen Arsitektur

FastAPI: pintu masuk data (input) dan penyedia data (output).
PostgreSQL: sumber data terstruktur.
Worker (opsional): untuk sinkronisasi/ETL ringan (mis. impor spreadsheet, parsing foto metadata).
Frontend dashboard: bisa React/Vue/Metabase/Superset—bebas. Fokus artikel ini di API.

Tabel: Data yang Perlu Dikumpulkan (Versi Praktis)

Domain	Contoh data	Sumber umum	Update	Risiko jika tidak rapi
Progres	volume, bobot item, % capaian	laporan harian, checklist	harian	% “ngambang”, sulit audit
Biaya (RAB)	budget item, realisasi	RAB, invoice, PO	mingguan/harian	cost overrun terlambat ketahuan
Material	jenis, kuantitas, lokasi	delivery note, stok	harian	shortage mendadak
Alat berat	jam kerja, downtime	log operator/telemetri	harian	produktivitas turun tanpa sebab

3. Model Data: Skema yang Tidak Membuat Anda Menyesal

Kunci dashboard bukan hanya query, tetapi skema yang memudahkan agregasi. Anda ingin bisa bertanya: “proyek A minggu ini progresnya berapa, biaya lari berapa, dan top 3 item penyebab deviasi?”

Entitas Inti yang Disarankan

projects: metadata proyek.
work_items: item pekerjaan (berat/bobot).
daily_reports: catatan harian per proyek.
daily_progress: detail progres per item per hari.
budget_items: struktur RAB.
cost_ledger: transaksi biaya (aktual).

Tip Praktis

Simpan unit dan koefisien di work_items agar konversi tidak dilakukan di sisi frontend.
Pisahkan “header laporan” dan “detail progres” agar update parsial tidak menyiksa.

4. Implementasi FastAPI: Endpoint yang Ramah Dashboard

Di bab ini, kita turunkan konsep jadi endpoint yang bisa langsung dimakan UI. Setiap endpoint harus punya tujuan yang jelas: input data atau output agregasi.

Endpoint Minimum (MVP)

POST /v1/projects — membuat proyek.
POST /v1/daily-reports — input laporan harian.
GET /v1/projects/{id}/dashboard — agregasi untuk dashboard.
GET /v1/projects/{id}/progress?from=...&to=... — time series progres.
GET /v1/projects/{id}/cost-summary — ringkasan biaya vs RAB.

Pola Response untuk Agregasi Dashboard

Gunakan response yang “siap render”, contoh:

kpis: progres total, deviasi biaya, burn rate.
charts: series harian/mingguan.
alerts: item deviasi paling besar.

Pro tip: untuk endpoint agregasi, simpan query berat di layer service + caching. Dashboard yang lambat = dashboard yang ditinggal.

Catatan tentang Background Task

Kalau Anda punya proses impor (mis. upload Excel RAB), Anda bisa pakai background task. Untuk inspirasi visibility task, lihat fastapi-bgtasks-dashboard di CoderLegion.

5. How-To: Dari Nol ke Dashboard Data-Ready (Step-by-Step)

Bab ini dibuat sengaja “taktis”, supaya Anda bisa meniru alurnya lalu menyesuaikan ke real project.

Langkah 1 — Definisikan KPI yang Disepakati di Lapangan

Checklist KPI yang biasanya relevan:

Progress plan vs actual (harian/mingguan)
Cost actual vs budget (per item & total)
Produktivitas alat berat (jam operasi vs downtime)
Lead time material (PO → datang)

Langkah 2 — Normalisasi Input Laporan Harian

Buat form digital (mobile-friendly). Minimal:

tanggal, cuaca, shift
item pekerjaan + volume
tenaga kerja
alat berat (jenis + jam)
material masuk
catatan kendala

Langkah 3 — Bangun API Kontrak yang Stabil

Gunakan:

validasi ketat (Pydantic)
idempotency key untuk submit ulang
error format konsisten

Langkah 4 — Buat Endpoint Agregasi untuk UI

Hindari “frontend mengolah semua data mentah”. UI sebaiknya konsumsi:

KPI ringkas
data chart
daftar deviasi

Langkah 5 — Terapkan Audit Trail

Konstruksi itu dunia audit. Simpan:

created_by, created_at, source
histori revisi laporan

6. Praktik Lapangan: Data Material & Alat Berat Biar Tidak Cuma Jadi Angka

Di proyek nyata, suplai material alam (tanah, batu, basecourse) dan rental alat berat sering jadi titik kebocoran biaya jika pencatatan tidak disiplin. Dashboard monitoring proyek konstruksi yang bagus harus bisa menjawab pertanyaan sederhana: “berapa yang masuk, dipakai untuk apa, dan dampaknya ke progres?”

Material: Hindari “Masuk Banyak, Hilang Pelan-Pelan”

Wajibkan nomor dokumen (delivery note/DO)
Catat lokasi drop dan penerima
Cocokkan volume dengan progres work item terkait

Alat Berat: Jam Kerja yang Mengubah Narasi Biaya

Catat jam operasi, jam standby, downtime
Simpan alasan downtime (menunggu material, breakdown, cuaca)
Hubungkan ke produktivitas per work item

7. SEO-Friendly, Admin-Friendly: Cara Menulis Agar Artikel “Nempel” di CoderLegion

CoderLegion menyukai tulisan yang terasa hands-on, punya struktur jelas, dan tidak mengawang. Agar konten Anda tidak tenggelam:

Buka dengan problem nyata + solusi teknis.
Sisipkan tabel/diagram alur.
Tambahkan FAQ yang menjawab keberatan umum.
Sertakan HowTo (seperti di atas) agar pembaca cepat praktik.

Dan yang paling penting: ulangi istilah utama secukupnya. Di artikel ini, dashboard monitoring proyek konstruksi sengaja dipakai beberapa kali sebagai konteks, bukan sekadar pengulangan.

FAQ

1) Apakah dashboard harus dibuat dengan React?

Tidak. Anda bisa memakai BI tools (Metabase/Superset) selama API Anda rapi. Yang penting adalah kontrak data.

2) Bagaimana kalau RAB masih berupa Excel?

Mulai dari impor terstruktur: mapping kolom → budget_items, lalu simpan versi (v1, v2) agar revisi RAB tidak merusak histori.

3) Data di lapangan sering tidak lengkap. Apa yang dilakukan?

Mulai dari “minimum viable reporting”: 5–7 field wajib. Lalu tambahkan disiplin lewat validasi dan feedback loop (dashboard menampilkan data kosong sebagai alert).

4) Apakah butuh IoT untuk alat berat?

Tidak wajib. Tapi kalau ada telemetri, simpan sebagai event time series dan agregasikan per shift/hari.

5) Apa metrik paling cepat memberi dampak?

Progress vs biaya per item pekerjaan. Itu paling cepat memunculkan deviasi yang bisa ditindak.

Closing: Dashboard yang Bekerja untuk Keputusan, Bukan Sekadar Tampilan

Sebagai penutup, ada kutipan yang relevan untuk budaya engineering yang berujung pada kualitas sistem dan data: “You build it, you run it.” — sebuah prinsip yang sering dikaitkan dengan Werner Vogels, CTO Amazon yang dikenal luas di ranah distributed systems dan cloud architecture. Artinya dalam bahasa Indonesia: “Kamu yang membangun, kamu juga yang menjalankan.” Dalam konteks artikel ini, maknanya sederhana: kalau tim membangun API dan dashboard, tim yang sama harus peduli pada kualitas data, performa endpoint, dan dampaknya pada operasi proyek—karena di sanalah feedback loop yang membuat dashboard monitoring proyek konstruksi benar-benar dipakai.

Jika Anda ingin melihat bagaimana pendekatan ini dipakai di proyek nyata—mulai dari konstruksi sipil/struktur, MEP, suplai material alam, sampai rental alat berat—kami membuka ruang diskusi dan kolaborasi. Kunjungi profil perusahaan kami di PT Abi Darma Sejahtra untuk melihat layanan dan portofolio.

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Membangun Dashboard Monitoring Proyek Konstruksi dengan Python + FastAPI",
  "description": "Panduan membangun API berbasis FastAPI untuk menyuplai data progres, RAB, dan laporan harian ke dashboard monitoring proyek konstruksi.",
  "totalTime": "PT6H",
  "supply": [
    {"@type": "HowToSupply", "name": "Dataset laporan harian (CSV/Google Form/Spreadsheet)"},
    {"@type": "HowToSupply", "name": "Struktur RAB (Excel/CSV)"}
  ],
  "tool": [
    {"@type": "HowToTool", "name": "Python 3.10+"},
    {"@type": "HowToTool", "name": "FastAPI"},
    {"@type": "HowToTool", "name": "PostgreSQL"}
  ],
  "step": [
    {
      "@type": "HowToStep",
      "name": "Definisikan KPI proyek",
      "text": "Tetapkan KPI yang disepakati (progress plan vs actual, biaya vs RAB, produktivitas alat, lead time material) agar dashboard punya tujuan yang jelas.",
      "url": "https://www.abidarmasejahtra.co.id/"
    },
    {
      "@type": "HowToStep",
      "name": "Normalisasi format laporan harian",
      "text": "Buat format input minimal yang konsisten: tanggal, shift, item pekerjaan, volume, alat, material, dan kendala. Terapkan validasi agar data siap diproses.",
      "url": "https://coderlegion.com/11707/best-practices-for-restful-api-design-for-dev-tools"
    },
    {
      "@type": "HowToStep",
      "name": "Bangun kontrak API versi pertama",
      "text": "Rancang endpoint resource-oriented, gunakan versioning (/v1), format error konsisten, dan idempotency key untuk menghindari duplikasi submit.",
      "url": "https://coderlegion.com/4597/versioning-your-api-the-right-way-rest-best-practices"
    },
    {
      "@type": "HowToStep",
      "name": "Buat endpoint agregasi dashboard",
      "text": "Sediakan endpoint khusus agregasi KPI, time series chart, dan daftar deviasi agar frontend tidak mengolah data mentah secara berlebihan.",
      "url": "https://cmicglobal.com/resources/article/construction-software-integrations-trends"
    },
    {
      "@type": "HowToStep",
      "name": "Tambahkan audit trail dan kontrol kualitas data",
      "text": "Simpan created_by/created_at, histori revisi laporan, dan lakukan pemeriksaan silang volume material vs progres. Gunakan caching untuk respons dashboard yang cepat.",
      "url": "https://www.sciencedirect.com/science/article/pii/S1474034625004045"
    }
  ]
}

Why 'Tech Debt' Does Not Get Fixed

Tue, 20 Jan 2026 23:44:51 +0000

Most engineering teams have a backlog of work they call "tech debt." Developers understand how it can slow down feature development, increase support costs, and threaten system stability. Yet when they bring these concerns to stakeholders, the work often stays deprioritized indefinitely. So why is that? Why would something so obviously important be ignored? Delivery pressure plays a part, but a large share of the reason is that the term 'tech debt' positions engineering work as backward-looking cleanup rather than forward-looking value creation. It's defensive and ambiguous, and it lets a request arrive without a price or an owner, which sets the work up to be deprioritized again and again.

"Tech debt" is a self-fulfilling prophecy that perpetuates the communication gap that created it in the first place.

How the Term "Tech Debt" Invites Deprioritization

The metaphor creates the outcome everyone complains about by shaping how people think about and discuss the work.

The term is too ambiguous to be actionable. When someone says "tech debt," what do they actually mean? Intentional tradeoffs made under time constraints? Unanticipated consequences of reasonable decisions? Outright mistakes? Code that worked fine but is now outdated due to evolving requirements?

Ward Cunningham coined the metaphor in his 1992 OOPSLA experience report on the WyCash portfolio system, and he meant one specific thing. You ship first-time code before the design is fully understood, then pay it back promptly with a rewrite. The word has since stretched to cover every case in the list above. Martin Fowler's Technical Debt Quadrant defends the metaphor across all of them, but it takes two axes, deliberate versus inadvertent and reckless versus prudent, to sort what the word now covers. A stakeholder hearing the word gets none of that sorting. The term conflates deliberate strategy with failure, which makes it hard to have a productive conversation about what to do next.

The metaphor obscures actual costs and consequences. Real financial debt has clear terms: borrow $100K at 5% interest, pay it back over 5 years. Cunningham's original metaphor had terms too, since he counted every minute spent on not-quite-right code as interest, and the interest was the point. Everyday use drops them. Teams cite the debt and leave the interest unstated, so the word arrives without its business case.

What's the interest rate? When is it due? What happens if we don't pay it? The metaphor lets everyone avoid confronting actual costs and timelines. Without clear costs, there's no urgency, and without clear consequences, there's no accountability. Stakeholders hear "the code is messy" and think "so what?" They don't hear "we're losing $50K per month in support costs because this implementation is brittle, and we can't ship the feature roadmap because every change breaks three other things."

The debt metaphor implies inevitability. The verb that travels with the term is "accumulate," as in "we'll always accumulate some debt; that's just how software works." That makes debt sound like something that happens to a team rather than something it decided. Some of it is unavoidable, because requirements keep moving after code ships. But the framing stretches that truth over everything, so people accept poor decisions as unavoidable rather than asking "why did we decide without information we could have gathered?" Shipping under genuine uncertainty can be the right call, as Cunningham argued. Skipping the discovery that was available is not. The term normalizes dysfunction instead of demanding clarity.

The term frames it as engineering's problem. When you say "we have debt to pay down," stakeholders can easily hear "you made a mess, now clean it up." Put that next to the "accumulate" habit above, and engineering loses both ways. Engineers say "accumulate," which makes the decision look like no one's choice, so nobody outside engineering owns it. Stakeholders hear "debt" as blame, so the cleanup lands on engineering anyway. This doesn't invite collaborative problem-solving. It creates an adversarial dynamic where engineering owns the problem and stakeholders reluctantly allocate time to "let them fix their mistakes."

The label strips away the decision's context. "Debt" records that something is owed, not why it was borrowed. Without architectural decision records, the label fills that gap with blame, and future teams assume incompetence rather than recognizing intentional tradeoffs. The original context disappears: why this approach was chosen, what constraints existed at the time, what the intended evolution path was. Without that clarity, the current team either blindly perpetuates a bad pattern because they don't understand the original intent, or rewrites everything because they assume the previous team didn't know what they were doing. Both outcomes are expensive.

Consider how different this looks with context. If the architect had documented "We chose NoSQL here because we needed to ship in 3 months with the team we had. The long-term design uses relational storage. We've isolated this behind an interface so we can swap it later without touching business logic," the team has a roadmap instead of a mystery. That record is also what tells stakeholders what they traded for the 3-month ship date. When nobody writes it down, the business accepts a shortcut without knowing its price, and that gap is where the debt starts.

Whoever writes that record, usually the architect, becomes the translator between constraints, decisions, and evolution paths. Without that translation, each failure above feeds the next. Poor communication creates problems, vague language prevents fixes, and the gap widens.

An Alternative: Categories That Communicate Impact

Developers can keep using "tech debt" internally as shorthand within engineering teams, but when talking to product owners and stakeholders, retire the term entirely.

One approach is to categorize work by business impact: Corrections, Optimizations, and Re-Alignments.

Corrections: Problems Causing Harm or Exposure Now

What it is: Mistakes, tradeoffs, or outdated decisions actively harming the business right now, or exposing it to harm you can price.

Examples:

Security vulnerabilities exposing customer data
Unpatched or end-of-life dependencies whose next vulnerability will stay open
Bugs causing support escalations or customer churn
Reliability issues causing downtime or SLA violations

Why this works: Stakeholders already understand bugs and security problems as priorities because they're causing measurable harm today.

Language to use:

"We have a security vulnerability that exposes customer payment data. The fix takes 2 weeks."
"This bug is costing us $30K per month in support escalations. Fixing it unblocks the support team."
"The authentication service has 99.5% uptime. Our SLA guarantees 99.9%. The gap creates $100K annual credit exposure. Fixing the root cause takes 3 weeks and eliminates the SLA risk."

Corrections communicate urgency. The business is being hurt now, and addressing it stops the bleeding immediately.

Optimizations: Improving Efficiency and Cost

What it is: Mistakes, tradeoffs, or outdated decisions affecting cost, performance, or efficiency.

Examples:

Database queries causing slow page loads (affecting conversion rates)
Infrastructure configuration costing more than necessary (budget impact)
Manual deployment process taking hours per release (velocity impact)
Tightly coupled code where every change breaks something else (slower delivery across the roadmap)
Inefficient algorithms causing excessive cloud compute costs

Why this works: Stakeholders understand optimization as improving what exists. It's not "paying debt," it's "increasing margin" or "improving user experience."

Language to use:

"Our cloud costs are $50K per month. A 3-week optimization brings that to $20K per month, saving $360K annually."
"Checkout page loads in 8 seconds. Our funnel data projects that cutting it to 2 seconds lifts conversion by 15%. The work takes 4 weeks and projects to $500K additional annual revenue."
"Automating deployments cuts release time from 4 hours to 15 minutes, letting us ship features faster. The automation work takes 2 weeks and doubles deployment frequency."
"Changes to the billing module take three times longer than changes elsewhere and cause most of our rollbacks. Two weeks of decoupling brings it in line with the rest of the codebase."

Optimizations communicate efficiency gains with measurable ROI. The business improves margins, performance, or velocity.

Re-Alignments: Unlocking Future Capabilities

What it is: Mistakes, tradeoffs, or outdated decisions that, when fixed, unblock new features, integrations, or business capabilities.

Examples:

Monolithic architecture preventing independent team scaling
API design preventing mobile app development
Data model preventing real-time analytics feature
Vendor lock-in preventing multi-cloud strategy
Legacy authentication system preventing enterprise SSO integrations

Why this works: Stakeholders understand opportunity cost. If the current architecture blocks a $2M revenue opportunity, fixing it isn't "paying debt"; it's "unlocking growth."

Language to use:

"We can't build the mobile app until we redesign the API. The redesign takes 6 weeks and unblocks a $2M annual opportunity."
"Our current data model prevents real-time dashboards (top customer request). Re-aligning the schema takes 4 weeks and delivers the feature."
"The monolith prevents us from scaling the checkout team independently. Splitting it out takes 8 weeks and lets that team release on its own schedule."
"Adding OpenID Connect unblocks enterprise SSO integrations. The $500K deal waiting on this capability closes once we deliver it. The migration takes 5 weeks."

Re-Alignments communicate strategic value. The business unlocks capabilities that enable growth, close deals, or meet customer demands.

Each Category Demands a Price and Routes to an Owner

The new labels aren't magic, and stakeholders can tell a rebrand from a change in substance. They work because each one demands a specific follow-up. A Correction has to state the harm happening now. An Optimization has to state the cost or time it saves, and a Re-Alignment the capability it unblocks. "Tech debt" sounds like a complete request, so it gets made without the cost attached. It gets deferred, and the next request arrives in the same form.

Each new category points to an outcome that already has an owner and a queue. A Correction goes where incidents and escalations go. An Optimization goes to whoever owns the budget or the conversion target. A Re-Alignment rides with the roadmap item it unblocks. A categorized request states its value in the same terms as a feature and competes in the same queue, where the stakeholder makes a business trade they own instead of granting engineering time for repairs.

That routing, more than the numbers alone, is why the word matters. "Debt" points to no outcome, so when it gets a budget at all, the budget tends to be a separate cleanup allowance, such as a fixed slice of each sprint or a hardening quarter. Attaching a cost to the old label doesn't change that. A costed "debt" request still competes for leftover capacity instead of against the features it affects.

The categories also finish part of the translation the architect's record started. With a record like the NoSQL one above, calling the storage swap a Re-Alignment says the original choice fit its constraints and the constraints moved, which is the opposite of the incompetence story.

The routing has limits. It assumes those outcomes have owners outside engineering. Where engineering owns them too, attach the request to the product goal it protects. Small upkeep that no outcome owns still earns a protected allowance, but anything larger than that sprint slice needs a category to find a home. And framing won't move a stakeholder who understands the cost and still chooses features under delivery pressure. That can be a legitimate business call, and a costed request at least makes it a visible decision with an owner instead of a silent deferral.

The categories sort by the ask rather than by origin, because what a stakeholder needs to know is what happens if they say yes. When an item fits more than one category, file it under the impact you're asking the stakeholder to act on. Sorting by the ask also keeps a refusal on the record. Suppose a stakeholder funds a feature but cuts the Re-Alignment that would have unblocked it. Record the cost of the workaround as their decision, so the trade stays visible the next time the item comes up.

Putting a Number on Work That Has None Yet

The figures in the callout examples above are illustrations, and they have to come from your own data when you use them. Stakeholders discount projections they can't check, so lead with costs already measured and present any gain as an estimate with its basis stated.

Not every item arrives with a price. Risk that hasn't materialized yet still belongs with Corrections, stated as exposure: what an incident would cost and why it is likely. Where you can't price the impact, state what you can measure, such as hours lost per release, incidents per quarter, or the features waiting on the change. Diffuse drag, like weak test coverage or inconsistent patterns spread across a codebase, still shows up in those measures as longer cycle times and more rollbacks. Compare the affected area against the rest of the codebase, or the codebase against its own trend, and the drag becomes an Optimization with a number attached.

If an item shows no harm, cost, or blocked capability, not even in those trends, that tells you something too. It may still deserve a fix inside feature work, which is the cheapest place to stop early decay before it reaches the trends, but it hasn't yet earned a separate claim on the roadmap.

Breaking the Cycle Starts on the Engineering Side

The self-fulfilling prophecy persists because both sides perpetuate it. Developers tend to use vague language, stakeholders tend to defer those vague requests, and the cycle continues.

Break the cycle by being the solution:

Replace "tech debt" with Corrections, Optimizations, and Re-Alignments when talking to stakeholders
Communicate business value from the start in architectural proposals and decisions
Mentor developers on translating technical concerns into stakeholder priorities
Enforce quality standards at every increment through code reviews, architecture reviews, and quality gates, so fewer items need a request at all
Document decisions with ADRs so context doesn't disappear and future teams have roadmaps

These aren't debts to be paid; they're opportunities for value. If the term itself invites the problem, replace it.

The First Thing That Breaks When You Outsource a Mobile App (It’s Not “Code”)

Wed, 31 Dec 2025 13:08:09 +0000

Most teams don’t fail because the agency “can’t build.”
They fail because nobody agrees on what done means — and the cracks show up right after the first version ships.

Here’s what usually breaks first (in this order), based on what I’ve seen across early-stage product builds:

1) “Small changes” turn into surprise invoices

Not because anyone is evil — because the scope was never pinned down.
When you ask for “a tweak,” the team hears “a new flow.” Then you’re negotiating instead of building.

Fix: define “done” per feature before development starts:

acceptance criteria written (not implied)
edge cases listed (cancel, retry, offline, failed payment)
basic QA scenarios agreed (happy path + 3 failure paths)
release notes + handoff notes included

2) Post-launch becomes a ghost town

The app goes live… and the people who built it move on.
Now every crash feels urgent, and every fix feels slow.

Fix: ask this during hiring:

“Show me a launch you supported for 60–90 days. What did support look like week-by-week?”

If they can’t answer clearly, you’ll learn the hard way.

3) The repo + accounts aren’t truly yours

This one causes the most painful rebuilds.
If you don’t own the repo, CI/CD, analytics, crash reporting, app store accounts, and infra access — you’re renting your own product.

Fix: ownership checklist:

code repo under your org
app store accounts under your org
analytics + crash reporting under your org
a documented build/release process (not “ask our dev”)

4) Quality issues are invisible until users complain

A lot of teams “test” by clicking around once.
Then production becomes the test environment.

Fix: minimum instrumentation:

crash reporting (so you see issues before reviews do)
event tracking for the top 5 actions (so you know what’s working)
a weekly demo (so progress is visible, not assumed)

The simplest question:

If you’re talking to an agency/freelancer, ask:

“Walk me through your MVP plan in phases — what’s in phase 1, phase 2, and what’s explicitly NOT included?”

Good teams answer with trade-offs and boundaries.
Weak teams answer with “we’ll start building and iterate.”

If you’ve shipped an app before: what was the first thing that broke for you — scope, support, or ownership?

Optional resource (1 link): Full comparison + checklist: https://budventure.technology/blog/in-house-vs-agency-vs-freelancers-mobile-app-development

In-House vs Agency vs Freelancers: how startups should choose (mobile apps)

Wed, 24 Dec 2025 22:09:18 +0000

I just published a longer guide comparing in-house vs agency vs freelancers for startup mobile apps.
Instead of a link drop, here are the 5 takeaways that actually matter:

1) This is a risk decision (delivery, quality, runway), not just a cost decision.
2) If you don’t have a strong tech lead, agencies reduce failure modes (QA + delivery mgmt).
3) If the app is core IP, plan to bring core engineering in-house over time.
4) Regardless of model: own the repo + accounts, define “done,” and demo weekly.
5) Most early teams win with a small accountable pod + tight scope.

Curious: what model did you pick, and what broke first?

References:
[1] Deloitte — Global Outsourcing Survey: https://www.deloitte.com/us/en/services/consulting/articles/global-outsourcing-survey.html
[2] Full write-up: https://budventure.technology/blog/in-house-vs-agency-vs-freelancers-mobile-app-development

Rebuild Success Often Comes from Realignment, Not New Technology

Mon, 22 Dec 2025 17:06:40 +0000

Business and technically minded people both tend to credit new technology for the gains seen after a system or tool rebuild. They will also often blame the tech when a rebuild goes awry. But when you examine what actually changed, the technology often didn't drive the gains or cause the failure. The improvements (or their absence) came from alignment with business value and the application of operational discipline. Often the gains were available without the rebuild. Failed rebuilds get misjudged the same way, and when someone tracks one against what it promised, its problems often show long before more development is wasted.

The critical error is assuming the new runtime, framework, or platform created the success. Often ignorance was the actual constraint, and rebuilding forced tech and business teams to confront it.

This misattribution creates dangerous organizational patterns. Teams propose rebuilds when the underlying problem is dysfunction, not technical limitations. The rebuild becomes a moving target that allows leadership to avoid accountability, celebrate "innovation" while making things worse, and mask problems that were never technical to begin with.

Misattributed Success: The New Technology Gets Credit for the Realignment

The same confound shows up across technical domains:

Infrastructure migrations: Consider an organization that blames rising cloud costs on the provider's pricing model and migrates to on-premises infrastructure. Eighteen months later, leadership celebrates reduced hosting bills without mentioning the tripled operations team, degraded availability, and manual processes replacing what cloud automation previously managed.

If those savings trace to right-sizing and decommissioning, the root cause was never the cloud provider. It was absence of operational accountability. No one tracked which resources provided value, right-sized instances, or decommissioned abandoned experiments. The migration forced this discipline, but the same discipline applied to existing infrastructure would have achieved the savings without the rebuild. It would also have avoided the larger operations team and lost availability that came with it.

Not every repatriation is misattributed. David Heinemeier Hansson projected that 37signals would save about $7 million in server costs over five years by leaving AWS, "without changing the size of our ops team." That is what a genuine pricing case looks like: steady, predictable load, an operations team already in place, and savings counted after staffing.

Runtime rewrites: Teams celebrate performance gains after rewriting in a faster language. But was it the new runtime, or was it the rewrite that forced them to finally address inefficient database access patterns, redundant service calls, and missing caches?

High Scalability reported LinkedIn's move of its mobile server from Rails to Node.js as up to 20 times faster, with servers cut from 30 to 3. Ikai Lan, who had worked on the Rails version, answered that it made a cross data center call on single-threaded Mongrel servers "leaking memory like a sieve." He added that the comparison set "a lower level server" against "a full stack web framework."

Node's non-blocking I/O did fit the workload better, in his account, but he called it "not a performance panacea." He also said a port to JRuby could have bought "way more concurrency" without leaving the Ruby language.

He listed "the rewrite factor" among the causes. A rebuild from scratch by a team that knew the full requirements would have been "way better." He counted his own inexperience in that factor too, writing that the engineer he became years later would have done a far better job than he did in 2008. The headline credited Node with the whole gap, when part of it came from a team that finally understood the problem.

Framework modernizations: Teams credit the new frontend framework for improved responsiveness. But was it the framework's rendering model, or was it the rebuild that forced them to eliminate wasteful re-renders and implement proper state management?

The new runtime gets credit, the new provider gets credit, and the new framework gets credit. But the realignment did the work.

Credit Follows Visibility, Not Measurement

The misattribution has a mechanism. A rebuild changes the technology, the design, the scope, and the team's understanding of the problem all at once, so a before-and-after comparison can't separate their effects. The technology is the most visible of those changes and the one the proposal promised, so it collects the credit. Teams rarely trace each gain back to the change that produced it, so the credit gets assigned by visibility rather than measurement. That missing trace is also why nobody can say how often this happens.

Four Checks Trace Each Gain to Its Cause

The way to know is to trace each gain to the change that produced it and ask whether that change needed the new technology. Four checks do most of that work:

Backport the fixes. Apply the same fixes to the old system and measure how much of the gap closes. Before a rebuild, those fixes come from diagnosis, like profiling the slow path or auditing what each resource costs. A rewrite is an expensive way to run a profiler.
Price the fixes in place. Compare what those fixes would cost in the old system with the rebuild's estimate, since heavy coupling can make the in-place fix the more expensive path.
Count dropped scope. A gain from leaving features out of the new system isn't the technology's either. The old system can drop the same scope through incremental deprecation, even though retiring behavior in a live system is harder than leaving it out of a new one.
Ask whether the old stack could adopt the discipline. Some gains happen because the new technology made them cheap, like a framework whose state model makes wasteful re-renders hard to write. That gain belongs to the technology only if the old stack couldn't adopt the same discipline through a library or a convention.

When the gains trace to fixed queries, right-sized infrastructure, and optimized code, you could have achieved them on the existing system. In those cases the technology wasn't the constraint. Ignorance was. When a gain traces to something the old stack couldn't fix, like a garbage collector that really did cause the latency spikes, the technology earns the credit.

Shopify made this call in public. Kirsten Westeinde's "Deconstructing the Monolith" describes a Rails monolith whose missing boundaries meant an innocuous change could trigger a cascade of unrelated test failures. The team weighed microservices and rejected them for the network, deployment, and coordination costs they would add, then enforced component boundaries by business domain inside the existing application. The coupling was the problem, and they fixed it without a rebuild.

When Rebuilds Masquerade as Solutions to Organizational Problems

Rebuilds often hide deeper organizational failures, and a rebuild by itself changes none of them.

Missing Decision Records Make Tradeoffs Look Like Incompetence

When architectural decision records don't exist, future teams assume incompetence rather than recognizing intentional tradeoffs. Someone looks at the current architecture and declares "This is bad" when they really mean "I don't understand why it's designed this way." Without Architecture Decision Records documenting the constraints and reasoning behind key decisions, new technical leads tend to assume the previous team made poor choices rather than reasonable compromises.

Joel Spolsky made the code-level version of this argument in "Things You Should Never Do, Part I." Programmers judge old code a mess because it's harder to read code than to write it, and a rewrite throws away the bug fixes that years of production use put there. His cautionary case was Netscape's decision to rewrite its browser from scratch.

Stories Without a Shared Agreement Make the System Incoherent

User stories are slices of an agreement, not the agreement itself. They capture deliverable increments but provide no holistic understanding of what you're building or what you built. When organizations treat user stories as the entire agreement rather than fragments of it, coherence collapses.

Teams implement individual stories without understanding how they relate. Related capabilities get built across separate stories with no unifying vision. Each works in isolation, but together they create conflicting mental models. Flows spanning many stories across multiple sprints become impossible to explain end-to-end because no document describes them end-to-end. Each story made sense locally, but globally the system is incoherent.

Eventually someone proposes a rebuild to "clean up the mess." But the mess wasn't created by technical limitations. It was created by treating slices as the whole, by never establishing the agreement that user stories were supposed to slice.

Systems Drift When Nothing Retires Old Priorities

Systems drift from business needs when there's no mechanism to maintain alignment. Priorities change, but the system keeps implementing old priorities while never removing obsolete ones. New capabilities get added but old ones never get decommissioned. Integrations accumulate. Code paths multiply. Each addition made sense at the time, but no one maintains the whole.

Eventually the system does too much, costs too much, and serves unclear purposes. The rebuild proposal emerges naturally. "Let's start fresh with current priorities," someone suggests. But without changing the process that allowed the drift, the new system will accumulate the same cruft.

Shifting Priorities Let Rebuilds Escape Accountability

When leadership constantly shifts priorities without acknowledging past commitments, teams can never succeed or fail definitively. Every problem becomes "we were working on the wrong thing" rather than "we failed to deliver what we committed to." Rebuilds fit perfectly into this pattern because they're the ultimate moving target. By the time the rebuild completes, requirements have shifted again, and the cycle continues.

When nobody holds outcomes steady, only visible events get noticed, so leadership tends to reward visible heroics over invisible prevention. Nelson Repenning and John Sterman describe the same trap in process improvement, in a paper titled for it: "Nobody Ever Gets Credit for Fixing Problems that Never Happened." They studied firefighting in operations. Rebuilds fall into the same trap, because a rebuild is visible and the maintenance that would have prevented it is not.

The engineers who prevented the fire through good design, monitoring, and operational discipline get ignored. The engineers who led the visible rebuild get celebrated. This teaches the organization that creating problems and fixing them dramatically is more valuable than preventing problems quietly. Rebuilds become performative rather than necessary.

Breaking this trap around rebuilds takes both sides. Good developers and architects can identify these problems and push for accountability, but without leadership commitment their efforts fail. Leadership must ask hard questions when rebuilds are proposed, acknowledge failures when commitments aren't met, and maintain clarity on what matters. Technical teams must articulate problems clearly while leadership creates an environment where solving the right problem matters more than creating the appearance of progress.

The hidden cost is eroded organizational trust. When rebuilds fail to deliver on commitments but get celebrated anyway, teams learn that outcomes don't matter. This can produce learned helplessness, where engineers stop fighting for quality because leadership doesn't appear to care.

The Rebuild Adds Costs of Its Own

Escaping these failures through a rebuild also adds costs the old system never had. The old system still needs maintenance during migration, while the new system accumulates debt rapidly because you're learning as you build. You end up maintaining two systems at once, and when the rebuild wasn't justified, neither gets the investment in understanding that would have improved the old one. New systems have immature operational practices, rushed migrations skip security reviews, and unfamiliar platforms lead to misconfigurations.

The largest cost is opportunity. The months or years spent on a misguided rebuild could have been spent delivering actual business value. You're not just wasting the rebuild time. You're wasting all the value you could have created instead.

Without addressing these root causes, the new system tends to develop the same problems. The organization learns that rebuilds are how you "fix" things, entrenching a cycle of waste.

When Rebuilds Are Justified

Rebuilds aren't always wrong, and some situations demand them. When your runtime or infrastructure reaches end-of-support and security patches stop flowing, you must migrate. Staying on unsupported platforms creates unacceptable risk.

When the system's core architecture cannot support required characteristics, incremental refactoring may cost more than rebuilding. Every rebuild proposal claims this, so test it: state the target for the characteristic, then run a time-boxed spike on the existing system. If the spike can't reach the target, the limit is architectural. Some architectural shifts are fundamental enough that preserving the old system while transforming it creates more complexity than starting fresh.

New regulations sometimes demand capabilities the current system cannot provide. Compliance requirements may force architectural changes that touch every layer. When merging systems from acquired companies, rebuilding to a common platform may be necessary for operational efficiency and reducing long-term maintenance burden.

The difference between justified and unjustified rebuilds is honest assessment. Justified rebuilds have clear, measurable forcing functions. Unjustified rebuilds have vague dissatisfaction and organizational dysfunction masked as technical problems.

The AAA Discipline: How to Know If You Need a Rebuild

The AAA Cycle (Align, Agree, Apply) is a decision cycle that guards against rebuild disasters by forcing honest assessment before action.

Align: Understand Before You Prescribe

Before proposing a rebuild, align on reality. What actually provides value? Which features drive business outcomes versus exist because no one removed them? Why was the current architecture chosen? What problems was it designed to solve? What constraints existed? Which tradeoffs were intentional? Read the ADRs if they exist. Interview people who built the system.

Most importantly, determine whether the problem is technical or organizational. Are costs high because of the technology, or because no one is accountable for managing costs? Is the system slow because of architectural limitations, or because of fixable inefficiencies? Many problems that look technical turn out to be process failures.

Agree: Get Real Commitment, Not Permission

Once you understand reality, agree on what actually matters. State the actual problem, not the symptom. "The platform is expensive" is a symptom, while "We have no operational accountability for cost management" is the problem. Define measurable success criteria with explicit tradeoffs that acknowledge what you're willing to sacrifice and what you're not.

Evaluate alternatives. What could you do besides rebuild? What would those approaches cost? Acknowledge actual constraints: time, budget, team capacity, acceptable risk. Rebuilds hide behind "strategic investment" language to avoid honest resource conversations.

Assign specific ownership. Not "the team" but specific people accountable for specific metrics. If costs don't decrease, who failed? Without genuine agreement, rebuilds become exercises in diffused responsibility where no one can be held accountable.

Agreement also answers a harder case: the organization where only a rebuild can win the budget and attention that realignment needs. There the rebuild may be the only available path. But the organization then pays a rebuild's price for realignment work, and the dysfunction that refused to fund the quiet fix stays in place to cause the same drift again. Stating the actual problem instead of the symptom is what makes realignment fundable on its own terms.

Apply: Execute with Integrity or Stop

The Apply phase tests whether the agreement was genuine. Implement what you agreed to. If cost reduction was the priority, instrument cost tracking first. Track against the agreement continuously. When metrics diverge from commitments, pause and realign. Don't celebrate "completed migration" when you violated core commitments.

Recognize when agreements were wrong. If the rebuild isn't solving the actual problem, stop. Stopping is cheapest when the rebuild replaces the old system one slice at a time, so each slice is measured against the agreement before the next begins. "We committed to this" isn't a valid reason to continue when reality invalidates the premise.

Stopping a failed rebuild is success, not failure. Update ADRs and share learnings so the organization doesn't repeat the mistake.

The Apply phase makes accountability real. When rebuilds fail to deliver on commitments, AAA makes that failure visible instead of letting it hide behind "strategic transformation" language.

Realign Before You Rebuild

Rebuilds can solve the wrong problem. When they succeed, it is often not because of new technology, but because they force teams to understand what they're building, align with business value, and apply best practices. Much of that work could have happened without the rebuild, and the four checks show how much.

Before approving a rebuild, answer the AAA Cycle's questions:

Align: Have you traced the problem to the technology rather than to missing accountability or fixable inefficiencies, and run the four checks against the current system?
Agree: Can you state the forcing function, such as end of support, a required characteristic the architecture can't meet, a regulation, or a consolidation, and who owns the success metric?
Apply: What measured result would make you stop the rebuild partway?

Fix the organization, and the technical problems that remain are the ones a rebuild should solve. Rebuild without fixing the organization, and you'll be proposing another rebuild in a few years.

Before rebuilding, understand why you're considering it and be willing to be accountable for the outcome.

Project creation script (For multiple languages)

Sun, 26 Oct 2025 04:10:27 +0000

Hi all. Ever thought that creating projects for some languages are such as hassle (cough C cough).

Writing Makefiles/Justfiles until 3AM, getting it to work.

Well, I have made a script which automates this project creation , not just for C, but even for rust (using cargo), Python (uv) and golang.

Here is the script link

Below is the custom function in action

As you can see, it uses just (A command runner alternative to make) to run the compilation commands.

Link to just

Please do star it and let me know what you think.

Release Process (part 3/3)

Thu, 23 Oct 2025 23:34:02 +0000

After having followed the various conventions defined by our Git and GitHub processes, we should now be in a good place to take the code that has been produced, get it ready for QA, merge and release it. Every organisation will have their processes and workflows set around this, some good, some bad. I worked with my team to build a robust and practical release process which best suited our needs at the time, allowing for a quick development - QA - release lifecycle. We didn't quite achieve the continuous-release dream, but we got close.

Disclaimer: This is an evolving document which has been altered and tuned over the years. It may not apply to you and your situation but perhaps there is a nugget or two here that could improve your workflow and developer happiness.

QA / Testing

As anyone will know, the QA process of manually testing and sanity-checking code changes in a piece of work can often take 10 times the duration it took to make the changes in the first place, depending on the size of the changes requiring testing. No one wants to hand over some work for QA, and have the QA engineer spend a day testing it, only to find a silly bug or edge case which could have been caught by a code review or proper test harness, resulting in the PR being handed back to the developer to make the fixes, resetting any QA progress. QA time is limited and not to be wasted. Therefore, we do as much as we can before handing over to QA, ensuring to the best of our ability, that they have a bug-free, fully functional code change to test, limiting pushback.

1. Green CircleCI workflow

We were in a good place with our test coverage, with a minimum of 98% coverage. Our testing suite was split up over a parallelised CircleCI workflow allowing for relatively fast builds and giving us the chance to ensure our entire test suite went green before moving on to requesting developer reviews. 95% of the time, our test harness would catch any accidental bugs or code smells, enabling us to pass clean, "bug-free" code to the team to review.

For this post, I didn't bother waiting for the entire build process to go green before screenshotting, but you get the idea.*

2. Deploy to an integration environment

Thanks to our DevOps engineer, we had a flexible integration deployment system built right into CircleCI. On approval of integration deployment, a fresh new VM would be spun up, our code checked out, and all systems set up for manual testing. We would sanity check our changes on a "production" system because all too often, you hear the phrase "Well, it worked on my machine". Subtle differences between development and production environments can result in a working dev build failing in production. This also gives us a chance to properly document how QA should go about testing our changes for when it gets handed over. For much larger features, we would use these environments for demos and to demonstrate the new functionality to the rest of the team, assisting with their code reviews.

3. Developer code reviews

Once we were confident all tests and code quality checks were passing, and we have sanity checked our own work, we would then request two developer reviews. This gave other developers the chance to familiaralize themselves with the changes, and ensure the code was clean and well written, fully tested and optimised. Oftentimes, a fresh set of eyes might identify an edge case that was missed or realise that a query is N+1 and could be optimised. Be there required code changes or not, after all is resolved and the team is happy, they would provide their two green ticks on the PR. We would also ensure our branch commits are in a good state by having done an interactive rebase against master, squashing and/or renaming commits to follow our conventions.

4. Hand over to QA

Once we are confident that our code works, we have the approval of the team and we are happy that our manual testing and sanity checks have all passed, the PR finally gets flagged for QA. QA will then test our code on the integration environment we used for our testing (creating their bespoke test data) and be guided by our specified testing steps and notes. A QA intends to break the code, so it is at this point all the weird and missed edge case testing usually happens and bugs are discovered, if present. Regardless, once QA has taken their sledgehammer to the work, and finds it without fault, they will provide their final green tick on the PR, leaving the PR with a total of 3 green ticks. We are now in a state to merge the work into master.

Merging

Before we merge a branch to master, a couple of final steps are taken to ensure as smooth a process as possible.

1. Rebase and commit squashing

During the previous QA testing phase, there may have been various code changes required or bugs resolved. Before we commit to merging the branch after all the checks are green, we ensure our branch is up-to-date with the latest master by performing an interactive rebase against it, and squash any necessary commits, ensuring a clean, flat, and well-written git history is maintained (as per our Git Conventions). Ideally, there would have been no additional code modifications, so this step could be skipped as we do this before handing it over for dev review.

If there were merge conflicts that needed resolving, that means other work has made it in which may affect your code changes. In this instance, we would, based on the conflicts, possibly ask QA to go over the PR one more time before it gets merged, based off team decision.

2. Checking for migrations

Migrations can be tricky things. Testing a migration against a local database means nothing when run against a production database. Something as simple as changing a column name can bring an application to its knees if done incorrectly. Very often, one will see code-altering data in the database inside the migration (yes, this is a bad practice and shouldn't happen in a perfect world, but this is not a perfect world) which, when operating on millions of rows in a production database, can cause database locks and timeouts, failing the deployment process. Having been bitten too many times in the past by dodgy migrations requiring a release rollback, we opted to isolate any PRs that contained any database migration changes and deploy them as standalone. It is at this point that QA would flag the PR for isolated deployment to, in the worst case of a rollback, not have other PRs affected by the rollback.

3. Merging into `master`

Our master branch was protected against merging by everyone except our lead QA engineer, the most senior dev and the CTO. In 99.9% of instances, merging was done by our QA engineer, allowing for a controlled merge process. This also prevented untested code from sneaking into master under the guise of a "hotfix" or other such shenanigans.

Release

Our dream was to have rolling deploys - as soon as anything was merged into master, it would deploy. At the time of writing, however, we were working off manual releases, usually containing a handful of PRs.

Tag and generate release docs

GitHub made it easy to generate our release notes as it can do so automatically when creating a new release. Specify the new tag to be applied to master branch (major/minor/micro version bump), ask Github to generate the release notes and that's it. Thanks to our strict use of git commit conventions, the release notes description was clear without needing additional modification most of the time. For larger, more involved features, additional context would be supplied to better communicate the changes with our users.

Migration-induced isolated deployment

If a PR containing a database migration is flagged, a release will be created containing all previous PRs that have been merged since the last release, excluding the migration PR, and that will be deployed. The PR containing the migration would then get merged and a new release would be created straight away with only this PR. This was to ensure that there are no potential issues from compound migrations and also to allow quick and simple rollback should there be an issue. All this was made easier by having the master branch locked down to lead QA merging only, meaning nothing else could slip from elsewhere.

Press the button

Once the release tag has been created, the entire CircleCI build would run once more, running the entire test suite, including the slower integration test suite (not run by default) and once green, the release would be approved through CircleCI and off it goes. As we had a blue-green delivery process in place, a whole new cluster of pods would spin up with the new release, and only after all the various checks were completed ensuring all services were running without issue, we would have the load balancer switch over to the new pods and start killing off the old ones.

That's all folks

And that concludes part 3 of my documentation about the processes and workflows we built and fine-tuned over the years around the development lifecycle. It may not be perfect and there was a lot more we wanted to do (rolling deploys, etc) which we hadn't quite gotten to, but what we did have in place worked well for us. Sometimes the smallest change at the beginning of the process can produce significant wins at the end of the process. For instance, how our release note documentation was generated descriptively and concisely based on our git commit conventions, or how our GitHub documentation process helped us find where bugs were created years later due to easy searching.

All of these processes took some time, effort and accountability to become habits. There would be moans and groans when a PR was rejected because the branch name didn't match the pattern (look up Git move) or when an interactive rebase to squash that final "fix issue" commit tacked on during the review process was insisted upon, or blocking a PR until it had a decent enough description. Some might find these requests to be petty but looking back on the bubbling effect of them, the entire team would agree it was worth putting in that extra leg work at the end of the day.

Scrum Must Die ☠️

Tue, 19 Aug 2025 14:32:03 +0000

Scrum was born as the savior of development teams.
Now, in too many companies, it’s turned into a corporate religion with more sermons than miracles.
And like any bureaucratic religion... it either reforms, or it dies.

Scrum: from agile revolution to organizational theater

Years ago, when someone said "we're agile," people smiled.
Today, it means: "brace yourself for more meetings, more metrics, and more PowerPoints."

Once, companies hired Scrum Masters and Agile Coaches like rare Pokémon.
Now? They're laying them off, merging their roles, or keeping them as ceremony police.

The slow death of technical excellence ⚰️

Scrum doesn't ship technical practices out of the box.
Without a strong engineering commitment — tests, CI/CD, TDD, living architecture — the framework becomes a conveyor belt of broken features.

The result:

Code that ages worse than a banana forgotten in a drawer.
Deadlines that dictate more than quality.
Developers stuck in chronic burnout.

The mutant Scrum Master

In too many organizations, the Scrum Master is gone.
Instead, we have the Scrum-PM-Dev-Tester-CoffeeMaker: a hybrid creature that doesn't lead or serve, just survives.

A role meant to protect agility now spends the day filling spreadsheets and chasing tickets instead of empowering teams.

Management overload and the cost of ignorance

There's a growing management overload in many "agile" organizations: too many decision-makers with too little technical background.

This creates a dangerous loop:

Decisions are made without understanding the engineering impact.
Expensive mistakes are repeated in the name of "delivery".
Teams feel they're being managed, not led.

When non-technical managers dictate technical priorities, the result is often waste, rework, and long-term pain disguised as "progress".

The Agile Industrial Complex

Agility has been packaged into certifications, workshops, and consulting packages that promise transformation but deliver empty mechanics.

Scrum becomes a theater where everything is done "by the book" but without soul, values, or real continuous improvement.

Reform it or throw it overboard?

If you still want to rescue Scrum, here's the recipe:

How Scrum could improve:

Less ceremony, more value: if the daily stand-up lasts 20 minutes, something's broken.
Integrate technical practices: TDD, CI/CD, Pair Programming… without this, forget about quality.
Clear roles: a Scrum Master is not your Project Manager, boss, or on-call developer.
Real autonomy: the team decides, not the hierarchy.
Technical literacy in management: decision-makers must understand the cost and complexity of engineering work.

Alternatives that might shine brighter:

Kanban: flows like water, no forced iterations.
Extreme Programming (XP): hardcore engineering, quality above all.
Lean: less waste, more focus on what matters.
Mix & Match: take what works, drop what doesn't — like a good buffet.

Conclusion: Scrum isn't the enemy... but your implementation might be

Scrum doesn't have to die, but the zombie, bureaucratic, tech-agnostic Scrum we see in too many companies... that one should be buried.
Preferably with one last retrospective... and no sticky notes.

A guide to deciding what ,why and when To Pivot or to Persevere?

Sat, 26 Jul 2025 07:58:17 +0000

#The Founder's Dilemma: To Pivot or to Persevere?

When you're building something new, whether it's a startup or a project, you'll face a big question over and over: should you stick with your original plan, or is it time for a change? This is the classic choice between pivoting and persevering, a key idea in modern product development that comes from popular methods like the Lean Startup and Agile.

What Does it Mean to Pivot or Persevere?

Persevering is all about sticking to your guns. It means you believe in your current plan and are committed to seeing it through, even when things get tough. You have faith that your idea is the right one, and you're willing to put in the time and effort to make it work.

A pivot, on the other hand, is a major change in direction. It's not just a small adjustment; it's a deliberate decision to try a new approach because the old one isn't working. You're essentially admitting that your initial idea needs a rethink to find a path to success.

The main difference is the size of the change. Persevering is about improving your current path, while pivoting is about finding a new one.

Making the Call: Why, When, and What to Do?

Deciding whether to pivot or persevere is one of the most important decisions a team can make. The wrong choice can cost you time, money, and even the entire project.

Why is this decision so important?

This choice affects everything. It shapes how you use your resources, keeps your team focused, and determines if your product will ever be a hit with customers. A smart pivot can rescue a failing company, and determined perseverance can turn a good idea into a great one.

When should you consider a pivot?

Knowing when to pivot is tricky, but here are some signs to look for:

Stagnant Metrics: If your key performance indicators (KPIs) are flat or declining despite your best efforts, it might be time to reconsider your strategy.
Negative Customer Feedback: If your target audience is consistently telling you that your product doesn't solve their problem or that they wouldn't pay for it, you need to listen.
The "Get Out of the Building" Test: As advocated by the Lean Startup methodology, if your interactions with real customers reveal that your initial assumptions were wrong, a pivot is likely necessary.
A better opportunity appears: Sometimes, you'll discover a bigger and better idea while working on your original one. It might be worth pivoting to chase it.

How to decide which path to take?

Data-Driven Decisions: Rely on metrics and qualitative feedback, not just gut feelings. Use agile feedback loops to gather data continuously.
Set "Pivot or Persevere" Meetings: Hold regular, dedicated meetings to evaluate progress against goals and openly discuss the possibility of a pivot. This makes the decision a part of the process, rather than a reaction to a crisis.
Know what you're testing: Be clear about the assumptions you're making. This will help you know if your ideas are being proven right or wrong.

Real-World Scenarios

The Pivot Hall of Fame

Slack: Originally a gaming company called Tiny Speck working on a game called Glitch, the team built an internal communication tool to collaborate. When the game failed to gain traction, they realized their communication tool was the more valuable product. They pivoted to focus on it, and Slack was born.
YouTube: Started as a video dating site called "Tune In Hook Up." When that idea failed to take off, the founders noticed that users were uploading all kinds of videos, not just dating profiles. They pivoted to a general video-sharing platform, and the rest is history.
Instagram: Initially a location-based social network called Burbn, it was cluttered with features. The founders noticed that the photo-sharing feature was the most popular. They stripped away everything else and focused solely on photos, filters, and sharing. This pivot created the Instagram we know today.

The Power of Perseverance

Amazon: Jeff Bezos's vision for Amazon was always to be "the everything store." In the early days, many doubted that an online bookstore could succeed, let alone expand into countless other categories. Amazon persevered through the dot-com bust and years of unprofitability, staying true to its long-term vision.
Netflix: From its beginnings as a DVD-by-mail service, Netflix faced intense competition from Blockbuster. They persevered, believing in the convenience of their model. Later, they made the monumental decision to cannibalize their own successful business by moving into streaming, a move that required immense perseverance through technical challenges and licensing negotiations.

Conclusion

Building something new is never a straight line. It's about learning, experimenting, and making smart changes along the way. Knowing when to stick with your plan and when to make a change is what sets successful projects apart. By using data and being open to change, you can make the right call and give your ideas the best chance to succeed