👁229views

I Have Two Outlooks on a NASA Spacecraft and Neither Works

1. Ground Control to Major Redmond

In early April 2026, four astronauts aboard the Orion spacecraft radioed Mission Control. They were travelling at over four thousand miles per hour, more than thirty thousand miles from Earth, on NASA’s first crewed lunar mission in more than fifty years. The hardware that got them there represents the most concentrated expression of human engineering ambition currently in existence, and the mission is the kind of thing that makes people stop and feel, briefly, that civilisation might be going somewhere after all.

The report from the spacecraft was not about orbital mechanics. It was not about life support, propulsion, or the view. It was this: “I have two Microsoft Outlooks and neither one is working.”

If you have spent more than a calendar year inside any large organisation’s technology stack, you did not laugh when you read that. You nodded, because you have been that astronaut. You have been thirty thousand miles from a working inbox, and the solution was to ask someone to remote in and sort it out, which is exactly what NASA did. Mission Control patched into the crew’s Personal Computing Device and fixed it, and the astronaut’s request, “if you could remote in and check those two Outlooks, that would be awesome,” was phrased with the flat, practised resignation of someone who has learned not to be surprised by this anymore. That tone is the whole story. Not the bug. The tone.

2. Why There Were Two Outlooks

The reason a spacecraft can carry two conflicting copies of the same application is the same reason enterprise software is the way it is, and it is worth being precise about it, because the usual explanation, that large companies are lazy or greedy or incompetent, is both too easy and mostly wrong.

Microsoft shipped a renamed version of Windows Mail and called it Outlook. Microsoft 365 already had an application called Outlook. At some point these two products coexisted on the same Windows machine and nobody with authority over both of them asked whether depositing two identically named, functionally divergent applications onto a user’s system was acceptable. Each team had a rationale, the naming made sense within each product’s own internal logic, and the compliance review, the release process, the roadmap sign-off, all of it happened correctly within each team’s scope. What was missing was the person whose scope included the astronaut sitting in front of the screen, the one who ends up with two Outlooks and zero working email at thirty thousand miles altitude.

This is not a Microsoft-specific failure. It is the structural failure mode of every large software organisation, and it produces the same result every time: software that is technically defensible at every individual decision point and functionally indefensible as a whole. It also runs on a predictable loop, one that begins the moment a platform reaches a certain size. Every new feature introduces configuration surface, which requires abstraction layers, which require specialists, who introduce process, which slows change, which drives more tooling, which introduces more configuration surface. No individual step is irrational and every step is locally correct, but the outcome is globally catastrophic, and nobody inside the loop is positioned to see it, because nobody’s scope is wide enough to include the astronaut waiting at the end of the chain.

3. This Is What You Are Paying For

NASA standardises on Microsoft 365. Your organisation probably does too. The global enterprise software market runs into the hundreds of billions of dollars annually, and the experience it is delivering, at that price, to the people who use it every day, is two broken Outlooks and a ticket number.

Consider what enterprise software actually costs. The licensing, for a large organisation, frequently runs to more per seat per year than a graduate developer earns in a month, for software that requires a certified implementation partner to install, a change control board to update, and a dedicated procurement relationship to renew. Then there is the systems integrator, the statement of work, the steering committee, and the programme of change management that exists entirely because the base product is too complicated to deploy without professional help, help that is itself priced by the same vendor ecosystem that made it complicated in the first place.

Then there is the support contract, which was sold to your CTO as a strategic partnership with dedicated technical resources and accelerated resolution pathways. What you get is Jayden. Jayden is not the villain here, and it is worth saying that plainly, because Jayden is also a victim of the system, working a ticket queue that the platform’s own complexity made both inevitable and infinite. Jayden asks you to resubmit your Tenant Correlation ID, confirm the phase of the moon at time of deployment, and attach a HAR file. Jayden escalates to Tier 2. Tier 2 escalates to engineering. Engineering closes the ticket as working as designed and links you to KB4839201-REV-F, and the workaround is to reinstall. Jayden moves on to the next ticket, and the platform remains exactly as broken as it was before, because fixing it was never part of anyone’s scope.

And then there is the hidden cost, the one nobody puts in the business case: the engineering hours spent not building things because someone is debugging a flag, navigating an entitlement matrix, or waiting three weeks for a support response on a question that should have taken eleven minutes to answer. Multiply that by the size of your engineering organisation and the length of your vendor relationship and you are looking at a number that would make a CFO physically unwell if it ever appeared on a single line. It never does, because it is distributed invisibly across every sprint, every standup, every afternoon someone spent not shipping a feature because the platform was in the way, and the vendor calls this a success story. There is a case study. Your logo is on their website.

None of this is accidental, and it is worth being equally precise about that. Complexity increases switching costs, requires consulting, justifies premium support, and delays replacement decisions. The same mechanism that breaks the product protects the business model, and the vendor collects on both ends: once when you buy the platform that created the problem, and again when you pay them to help you understand it. You are not paying despite the complexity. You are paying because of it.

4. The Code That Should Not Exist

The Outlook situation is visible because it happened in public, on a livestreamed mission, in a quote that spread across the internet within hours. Most of the time the dysfunction is quieter, buried inside platforms that have simply accumulated years of reasonable-sounding requirements from teams who were each acting in good faith. Here is what that accumulation looks like when you write it down. The code below is enterprise-grade “Hello, World”. Read the phase comments carefully 🙂

try:
    # Phase 1: Primary entitlement resolution (straightforward)
    tier_eligible = (
        client_license_tier == "ENTERPRISE_PLUS"
        or (client_license_tier == "ENTERPRISE_STANDARD"
            and grandfathered_tier_exception
            and not grandfathered_exception_under_review)
        or (client_license_tier == "LEGACY_GOLD"
            and legacy_migration_grace_period_active
            and not (legacy_migration_grace_period_active
                     and legacy_contract_formally_terminated))  # don't ask
    )

    # Phase 2: Commercial eligibility (also straightforward)
    commercial_eligible = (
        (volume_discount_enabled ^ month_end_promotional_voucher_active)  # XOR: both active = pricing conflict, raise manually
        and not service_credits_exhausted
        and prepaid_credits_balance > 0
        and not account_frozen_pending_routine_review
        and not tenant_flagged_for_legacy_billing_dispute
        and not awaiting_annual_license_reconciliation
        and fiscal_quarter != "Q3_BILLING_LOCKOUT_WINDOW"
    )

    # Phase 3: Compliance posture (this is the easy part)
    compliance_eligible = (
        compliance_framework in ["ISO27001", "SOC2_TYPE2", "The_Other_One_Nobody_Can_Spell"]
        and mfa_posture_score >= ACCEPTABLE_MFA_POSTURE_THRESHOLD
        and (data_residency_zone == TENANT_HOME_REGION
             or (data_residency_zone != TENANT_HOME_REGION
                 and cross_region_data_processing_addendum_signed
                 and not cross_region_addendum_under_legal_review))
        and (gdpr_processing_basis in ["LEGITIMATE_INTEREST", "CONTRACT", "CONSENT"]
             ^ popia_processing_basis_override_active)  # XOR: dual-basis assertion triggers audit flag
        and user_consented_to_updated_terms_version >= 47
        and telemetry_opt_in_confirmed
    )

    # Phase 4: Infrastructure and deployment (nearly there)
    infra_eligible = (
        deployment_target in APPROVED_CLOUD_REGIONS
        and geography not in EXCLUDED_GEOGRAPHY_LIST
        and (runtime_environment == "CONTAINER_V2"
             or (runtime_environment == "CONTAINER_V1"
                 and container_v1_deprecation_waiver_active
                 and not container_v1_waiver_expired))
        and (network_egress_policy == "STANDARD"
             or network_egress_policy == "RESTRICTED_PLUS"
             or (network_egress_policy == "LEGACY_OPEN"
                 and legacy_network_policy_remediation_in_progress
                 and remediation_sla_not_breached))
    )

    # Phase 5: Support and feature flag validation (the home stretch)
    support_eligible = (
        active_support_contract
        and support_tier in ["Premier", "Unified", "GoldPlus", "PlatinumUltraElite"]
        and not (support_tier == "GoldPlus"
                 and goldplus_tier_sunset_acknowledged is False)  # GoldPlus sunset announced Q2, acknowledgement required
        and feature_flag_enabled("OUTPUT_SUBSYSTEM_V2_PREVIEW_STABLE_RELEASE_CANDIDATE")
        and not feature_flag_enabled("OUTPUT_SUBSYSTEM_V2_STABLE_PREVIEW_RELEASE_CANDIDATE")  # different flag, different behaviour, yes really
        and (diagnostic_logging_upgrade_purchased
             ^ verbose_output_legacy_mode_active)  # XOR: both active causes log storm, known issue, no ETA
    )

    if (tier_eligible and commercial_eligible and compliance_eligible
            and infra_eligible and support_eligible):
        if (
            workload_classification != "RESTRICTED"
            or (workload_classification == "RESTRICTED"
                and restricted_workload_override_approved
                and override_ticket_not_older_than_days(30)
                and override_approver in AUTHORISED_OVERRIDE_APPROVERS_GLOBAL_LIST
                and not override_approver_currently_on_leave
                and not (override_approver in AUTHORISED_OVERRIDE_APPROVERS_GLOBAL_LIST
                         and override_approver_also_requestor))  # approver cannot self-approve, even if authorised
        ):
            print("Hello, World.")
        else:
            raise PermissionError(
                "Output suspended pending override review. Please raise a P2 ticket "
                "with your Designated Technical Account Manager, referencing your "
                "Organisation GUID, Tenant Correlation ID, and the phase of the moon."
            )
    else:
        raise LicenseError(
            "One or more eligibility conditions unmet. Please review your entitlement "
            "matrix, validate your compliance posture score, confirm your support tier "
            "aligns with the expected GoldPlus-or-above threshold, ensure your feature "
            "flag is set to PREVIEW_STABLE and not STABLE_PREVIEW, which are different "
            "things for reasons we cannot discuss, resolve any XOR conflicts in your "
            "commercial and compliance posture before resubmitting, and resubmit after "
            "the next billing cycle closes. If the issue persists, refer to KB4839201-REV-F. "
            "The workaround is to reinstall."
        )

except Exception as e:
    if (
        active_support_contract
        and support_tier == "PlatinumUltraElite"
        and diagnostic_logging_upgrade_purchased
        and not (diagnostic_logging_upgrade_purchased
                 and verbose_output_legacy_mode_active)  # see XOR note above
        and not logging_quota_exhausted
        and log_retention_policy != "EPHEMERAL_ZERO_DAY"
    ):
        log.error(f"[REDACTED FOR COMPLIANCE] An error may (or may not) have occurred. "
                  f"Reference ID: {generate_opaque_guid()}")
    else:
        pass  # you didn't pay for errors - upgrade you cheapskate

All it needed to do was print two words and a punctuation mark to standard output, a task every programming language on earth achieves in a single line and most of them teach on day one. And yet the above is not a caricature assembled from thin air. It is a recognisable portrait of how enterprise software platforms actually behave when enough teams have layered enough reasonable-sounding requirements on top of each other over enough years, each phase comment more strained than the last, each XOR a tombstone marking an incident someone once had to explain to a steering committee.

Nobody designed this. There was no architecture review where someone stood at a whiteboard and said “and here, in the billing lockout window check, is where we will break the developer experience forever.” What happened was quieter and considerably harder to fix: every team added one condition, one guardrail, one compliance obligation, and none of them were wrong to do so in isolation. The license check made sense to the licensing team, the MFA posture score made sense to the security team, and the fiscal quarter lockout made sense to whoever got burned by a surprise revenue recognition problem in Q3 three years ago. The problem was not any individual decision. It was the absence of anyone accountable for what all those decisions look like from the other end, and there is a point at which that absence stops being recoverable. You have crossed it when no single team understands the system end to end, when safe change requires cross-team coordination, when rollback is no longer deterministic, and when incidents require interpretation instead of diagnosis. At that point the system is no longer software. It is an organisation. And forty-five minutes of debugging later, you discover that the feature flag is set to STABLE_PREVIEW instead of PREVIEW_STABLE, which are different things, the documentation does not explain why, there is a KB article, and the workaround is to reinstall.

5. Why Open Source Keeps Winning

The reason open source software consistently wins developer mindshare is not primarily about price, though that matters, and it is not primarily about transparency, though that matters too. It is about the absence of accumulated obligation. PostgreSQL powers the transaction layer of banks, hospitals, and government systems on every continent, has done so for decades, costs nothing to license, and does not require you to confirm your compliance posture score before executing a query. Python runs the world’s scientific computing infrastructure, the majority of AI research, and a significant portion of global financial modelling, and its installer does not ask for your Tenant Correlation ID. Linux runs most of the internet, and it also runs the computers on the International Space Station, which is worth noting given recent events.

Open source maintainers tend to be ruthless about removing things that do not serve their users because their users can leave instantly and they know it. They cannot hide behind a procurement cycle, an implementation partner, and a twelve-month renewal motion, and if they make the thing unbearable, people simply stop using it. Commercial enterprise platforms accumulate conditions instead, because the switching cost is high enough that users cannot easily leave, which makes each additional layer of complexity politically survivable in a way it would not be if the customer had a genuine alternative available by lunchtime. Enterprise vendors survive precisely because their customers often cannot do the same.

The sharper irony emerges when organisations try to escape this by building internal developer platforms. If your internal platform has accumulated the same entitlement matrices, the same opaque flag naming conventions, and the same “raise a P2 ticket” error handling as the vendor software it was meant to replace, you have not solved the problem. You have just become the vendor, without the sales team to at least take your engineers out to lunch while doing it to them.

6. AI Makes the Trap Worse, Not Better

There is a widespread assumption that AI is the antidote to enterprise software complexity, and it is an assumption worth correcting early, because the opposite is closer to the truth. AI does not remove complexity. It compresses the time it takes to create it, and when a developer can generate working code, integrations, wrappers, policies, configuration, and scaffolding in minutes rather than days, the rate at which new conditions enter the system increases dramatically. The feedback loop described in Section 2 speeds up, the accumulation accelerates, and the irreversibility threshold arrives sooner than it would have otherwise.

The small number of teams genuinely escaping the complexity trap are not winning because AI is magic. They are winning because they have constrained ownership, tight scopes, fewer abstractions, and the organisational permission to remove conditions as well as add them, and AI multiplies that structural advantage enormously. Everywhere else, in the organisations that lack those properties, AI is being used to generate more layers, more flags, more glue code, more policy wrappers, and more surface area inside structures that were already incapable of managing the complexity they had. An engineer at a company that has not yet accumulated twenty years of enterprise vendor obligations can describe a problem in plain language and have a working answer before the support ticket has even been acknowledged, at a cost roughly equivalent to a flat white coffee, with an SLA of eleven minutes rather than three weeks and no requirement to attach a HAR file or confirm the phase of the moon. The comparison is not subtle, and it is not meant to be. AI does not fix enterprise software so much as it reveals, with increasing clarity, which organisations were already structurally incapable of building it.

7. The One Person Who Fixes It

The fix is not a rewrite. Careers reward starting programmes rather than finishing them, vendors sell clean slate narratives that ignore integration reality, executives underestimate coupling, and nobody owns the whole system for long enough to be punished by its eventual shape. Every rebuild begins with confidence and ends with entropy, and the new platform eventually accumulates its own phase comments, its own opaque flag names, and its own version of Jayden.

The fix is the deliberate appointment of someone whose job is to own the experience of the whole platform, with the authority to remove conditions and not just add them, and with a success metric tied to what the engineer or the astronaut on the other end can actually accomplish. That person needs to be able to walk into the room where the next reasonable guardrail is about to be added and ask what it will cost the person at the end of the chain before it gets merged, and that question needs to carry enough weight to actually stop the merge. Most organisations have plenty of people who can add a condition to the if-statement. Almost none of them have someone whose performance review depends on how short that if-statement is.

You do not need a formal audit to know whether you are already inside the trap. If your roadmap is integration driven rather than product driven, if every meaningful change requires coordination across multiple teams, if incidents involve reconstructing what happened from logs and tickets and Slack archaeology, if vendors are regularly required to explain your own system back to you, if workarounds are documented more clearly than intended behaviour, or if reinstalling is a legitimate operational strategy, you are not heading toward the trap. You are already inside it, and the question is not whether to fix it but whether anyone in your organisation has the scope and the authority to try.

When the Solutions Architect finishes polishing that deck, someone in the room should be allowed to ask two questions: whether a developer can print “Hello, World” without raising a support ticket, and whether the crew of a spacecraft running this software would be able to check their email. If either answer is “it depends”, you already know everything you need to know about the platform, the vendor, and the decision you are about to make.

The Artemis II crew are, at time of writing, on their way to the moon, carried there by some of the most sophisticated engineering in human history, running on an operating system that still ships two copies of the same email client and calls it a product. NASA got them there anyway, because the mission critical systems, the ones that actually keep people alive and on course, were built by people who could not afford to make them complicated.

The rest of us are still waiting for Jayden to escalate.