In hierarchies, almost everything is negotiable.

Roles shift. Responsibilities reassign. What counted as contribution last quarter gets renamed as something else this quarter. Value is a moving target. Credit migrates. Even the work itself gets reframed: the project that was strategic becomes a side effort, the feature that shipped becomes a prototype, the year of delivery becomes six sentences in a review.

The one thing that doesn’t move is authority over the naming.

Pierre Bourdieu called this symbolic power. The power to make things real by stating them.

“Symbolic power is the power to make things with words.”

In organizational settings, it operates as the quiet privilege of deciding what the landscape is: what counts as a project, what counts as a contribution, what counts as a problem worth solving, what counts as done.

Everything downstream of naming is fluid by design. The fluidity is the feature. If roles and responsibilities were fixed, the naming authority would have nothing to rearrange. The whole system runs on the asymmetry between those who do the work and those who decide what the work was.

James Scott described the parallel mechanism at state scale in Seeing Like a State. Authorities impose legibility on complex realities so the realities become governable. The imposed categories are never neutral. They privilege what the authority can see and measure, and they erase what they can’t. Inside organizations, the same move happens at smaller scale: a manager’s framing of a project becomes the project, regardless of what the contributors experienced or delivered.

The mechanism is sharper than “hoarding” suggests

The standard critique names this as information hoarding. The phenomenon is more precise than that.

Andrew Pettigrew’s 1972 study of gatekeeping treated information filtering as a political tactic and a power resource, framing organizational decision-making itself as a political process1. Michel Crozier’s earlier analysis of organizational power described it as control over “zones of uncertainty”, power accrues to whoever controls the ambiguities others must resolve to act2.

Information isn’t just withheld. It’s sequenced. Released to different audiences at different times. Pre-framed before it reaches contested ground. What looks like communication is often the opposite: the maintenance of ambiguity zones the authority can resolve in its favor when the moment serves.

The wiki that goes stale and isn’t updated. The handoff meeting that runs thirty minutes. The review that summarizes a year of work in a paragraph. The failed project that cannot be postmortemed because it was never measured. The team briefed before the contributor is invited. The framing seeded in one room and the invitation extended to another room only after.

These aren’t oversights. They are acts of selective authorship.

Why pathological modes don’t look pathological from inside

Ron Westrum’3s typology names three organizational cultures: generative, bureaucratic, pathological. In generative cultures information flows freely and messengers aren’t shot. In pathological cultures information is hoarded and responsibility shirked.

What’s less often noticed is that the pathological mode doesn’t look pathological from the inside. It looks like management.

Every individual act of framing, hoarding, or renaming has operational cover. The defense is always: I was within my authority. The indictment is the same sentence.

Authority to do harm doesn’t unmake the harm. Procedural cover doesn’t unmake moral content4. The cover is the mechanism by which the harm stays invisible to the organization’s own record of itself.

What defense exists against naming authority you don’t have?

The honest answer is: not much.

But there is one counter-structure available.

Written record.

Not verbal agreements. Not meetings. Not shared understandings. Written artifacts that exist independently of whoever controls the current naming.

Written record doesn’t win against authority. Authority can ignore it, reframe it, suppress it. But it shifts the cost of doing so. In organizations with accountability structures, rewrites must be actively produced rather than passively assumed. In bureaucratic-territorial organizations, written record activates jurisdictional reflexes that narrative alone doesn’t. Only in Desert organizations without either structure does written record become pure archaeology, operationally inert in the present, but available to future readers the current authority cannot control.

This is why the discipline of “nothing verbal, everything written” matters in hostile organizational environments. Not because written record protects contributors. Because the absence of written record leaves naming authority unchecked. The existence of written record forces the naming authority to work for its rewrites.

Diagnostic questions

The practical implication for evaluating organizations - from the inside, or before joining- is that the single most diagnostic question is not about culture, values, or mission statements.

It’s about where naming authority lives and whether the mechanisms that check it exist structurally.

• Who decides what counts as done?

• Who writes the record of what was delivered?

• Who authors the framing of contributions?

• What independent artifacts exist that the naming authority cannot simply rewrite?

In organizations where those mechanisms are weak or absent, everything a contributor does is negotiable except what a manager decides it was.

In organizations where those mechanisms are robust - engineering blogs, technical ladders, DORA metrics, direct user feedback, peer-reviewed decisions - the naming authority is constrained by structures that exist outside any individual’s control.

The first kind consumes people.

The second kind compounds their work.

The Core Inheritance

1. Object Model (The Foundation)

Everything in Smalltalk is an object, including classes, methods, and blocks. Message passing serves as the universal interaction mechanism. The system uses single inheritance with protocols (what other languages later called interfaces). Dynamic dispatch handles polymorphism through late binding.

What made it to successors:

• Java/C#: Adopted class-based OOP with static typing, a deliberate choice that traded Smalltalk’s dynamic flexibility for compile-time safety and tooling. Used interfaces to enable polymorphism within those constraints.

• C++: Added OOP to C while maintaining backward compatibility, choosing multiple inheritance (which Smalltalk deliberately avoided) and direct function calls over Smalltalk’s message-passing model.

• Ruby/Python: Stayed closer to Smalltalk’s dynamic approach, everything’s an object, dynamic typing, metaprogramming capabilities intact.

• Objective-C: Preserved message passing semantics, which is why [obj doSomething:arg] represents real message dispatch through objc_msgSend, not direct method calls.

2. Blocks and Closures

Smalltalk’s journey with blocks tells a more complex story than “since 1972.”

The evolution:

• Smalltalk-72 had code enclosed in brackets, but these were textual interpretations, not true closures

• Smalltalk-76 introduced compiled bytecodes and “remote contexts”, the first real closure semantics with lexical scoping

• Smalltalk-80 (publicly released in 1983, despite its name) refined the implementation with the BlockContext class

So the syntax existed early, but true closure semantics emerged through the mid-1970s.

When other languages caught up:

• C++11 (2011): Lambda expressions after 35 years:

  [](int x) { return x * 2; }

• Java 8 (2014): Lambda expressions after 38 years: x -> x * 2

• C# 3.0 (2007): Lambda expressions after 31 years: x => x * 2

Static typing made closures technically challenging to implement correctly. Smalltalk’s dynamic nature made them straightforward.

3. Collections & Higher-Order Functions

Smalltalk had collect:, select:, reject:, inject:into: from Smalltalk-80 onward.

Modern equivalents:

• Java Streams (2014): map(), filter(), reduce() essentially Smalltalk’s API with different syntax

• C# LINQ (2007): Same operations with query-expression syntax

• C++ STL algorithms (1994): std::transform, std::for_each arrived before Java Streams, using template-based function objects

The STL represents an interesting case: Alexander Stepanov’s work at HP predated Java’s collections framework by two decades, and while it wasn’t directly inspired by Smalltalk, it addressed similar problems with different constraints (C++ templates vs. dynamic dispatch).

4. UI Frameworks and MVC

MVC was created by Trygve Reenskaug in 1978-79 while visiting Xerox PARC, for Smalltalk-79/80. His original memo dates to December 10, 1979. Jim Althoff later implemented MVC for the Smalltalk-80 class library.

Descendants:

• Swing/AWT (Java): Drew widget hierarchy patterns from Smalltalk

• WPF/WinForms (C#): Similar approach

• Qt (C++): Studied Smalltalk’s design carefully, among the most faithful to the original principles

• Modern web frameworks: React/Vue/Angular rediscovered MVC variants, often under different names

Live UI editing: Smalltalk’s image-based environment let you modify running GUI code and see changes instantly. Modern “hot reload” approximates this but typically requires restart boundaries, a tradeoff for file-based development and separate compilation.

What Got Lost in Translation

Image-Based Development

Smalltalk had no “files” in the conventional sense. The entire development environment was a living object graph saved and loaded as an image. You debugged by editing code in the stack trace and continuing execution from that point.

What happened:

• Java/C#/C++: Used text file-based development with separate compilation

• Debuggers lost the ability to edit code mid-execution (a tradeoff for ahead-of-time compilation and deployment models)

• REPL culture (Python/Ruby/Clojure) is the closest remnant, but still fundamentally file-centric

True Message Passing

In Smalltalk, 2 + 3 sends the message + with argument 3 to object 2. Everything operates through message dispatch.

What happened:

• Java/C#: Method calls are direct function invocations with implicit this, no runtime message interception without reflection

• C++: Virtual functions provide polymorphism through vtables, but retain function-call semantics

• Objective-C: Kept message passing through its objc_msgSend runtime, maintaining Smalltalk’s flexibility

Simplicity

Smalltalk has 6 pseudo-variables that function as reserved words: nil, true, false, self, super, and thisContext. The entire syntax famously fits on a postcard (though this is Alan Kay folklore from his lectures rather than a published claim).

What happened:

• Java: 51 reserved keywords plus 17 contextual keywords (68 total)

• C#: 77 reserved keywords plus ~46 contextual keywords (~123 total)

• C++: Numerous keywords accumulated across multiple standards

Exception Handling

Smalltalk-80’s initial release used a primitive #error: mechanism. The sophisticated on:do: exception handling with resumption semantics developed progressively through the 1980s and 1990s, formalized in the ANSI Smalltalk standard (1998). Smalltalk pioneered modern exception handling in the late 90’s.

The Line of Descent

Daily Usage Today

What you inherited from Smalltalk:

• IDE integration with immediate feedback

• map/filter/reduce on collections

• Lambda expressions in callbacks

• Inheritance hierarchies

• Modern exception handling

• Refactoring tools (the Smalltalk Refactoring Browser by Brant and Roberts in 1997 was the first automated refactoring tool)

• Visual debuggers with object inspection

What’s still different in Smalltalk:

• Live coding: modify code while debugging, continue execution

• Pervasive metaprogramming: dynamic class modification without restart

• Simplicity: 6 pseudo-variables vs. 100+ keywords

• Consistency: everything is an object, no primitive types breaking the model

These aren’t necessarily “better”, they’re tradeoffs. Static typing enables better tooling and performance optimization. Separate compilation enables modular deployment. But the capabilities were lost, and it took decades to partially recover them.

The Pattern

Modern languages spent 30-40 years incrementally adding Smalltalk features:

• Closures/lambdas: Emerged when type systems became sophisticated enough (type inference, generic types)

• Higher-order functions: Required first-class function support in statically-typed languages

• Live feedback: Approximated through JIT compilation, hot reload, REPLs

The implementations often differ:

• More verbose (explicit type parameters, method references)

• More constrained (limited metaprogramming, no edit-and-continue)

• More ceremony (boilerplate for functional patterns)

Java’s Stream<T> API mirrors Smalltalk’s collections from 1983, but requires explicit type parameters, method references, and stream/collection conversions.

Compare:

#(1 2 3) collect: [:x | x * 2]

To:

Arrays.asList(1, 2, 3).stream().map(x -> x * 2).collect(Collectors.toList())

The functionality arrived, but with additional complexity.

What’s Coming Next

This article focused on the broad influence. But some specific Smalltalk features deserve deeper examination:

doesNotUnderstand: enabled metaprogramming that mainstream statically-typed languages still can’t match without significant workarounds. It’s why Ruby has Rails’ elegant DSLs while Java requires annotation processors and bytecode manipulation. This single method explains decades of expressiveness gaps.

halt and the live debugging experience let you stop execution, open the debugger, edit code in the stack trace, and continue, all while maintaining state. Modern debuggers generally can’t do this because of the compilation models they’re built on. Understanding why reveals fundamental tradeoffs in development tool design.

If you want to explore what we traded in the transition from dynamic to static, from images to files, from messages to method calls, subscribe. The rabbit hole goes deeper than “Smalltalk influenced Java.”

References and Further Reading

Primary Sources:

• Goldberg, Adele and David Robson. Smalltalk-80: The Language and Its Implementation. Addison-Wesley, 1983. Internet Archive

• Kay, Alan C. “The Early History of Smalltalk.” ACM SIGPLAN Notices, March 1993. Full text

• Reenskaug, Trygve. “Models - Views - Controllers.” Xerox PARC Technical Note, December 1979. PDF

• Ingalls, Daniel. “The Evolution of Smalltalk.” ACM HOPL, 2020. ACM Digital Library

Refactoring Browser:

• Roberts, Don, John Brant, and Ralph E. Johnson. “A Refactoring Tool for Smalltalk.” Theory and Practice of Object Systems, 1997. Semantic Scholar

Language Specifications:

• ANSI INCITS 319-1998: American National Standard for Smalltalk. Draft PDF

• ISO/IEC 14882:2011 (C++11): ISO page

• JSR-335: Lambda Expressions for Java. JCP page

Related Language History:

• Cox, Brad J. et al. “The origins of Objective-C at PPI/Stepstone.” ACM HOPL, 2020. ACM DL

• Ruby Official History: ruby-lang.org

• Stepanov, Alexander and Meng Lee. “The Standard Template Library.” HP Labs Technical Report 94-34, 1994.

Interviews and Conversations:

• “A Conversation with Alan Kay.” ACM Queue, 2004. ACM Queue

• Trygve Reenskaug’s MVC Resource Page: University of Oslo

I was discussing career labels with Claude when something strange happened. Mid-sentence, the AI injected a Chinese word I’d never seen before: 职业 (zhíyè). No Chinese anywhere in our conversation. No reason for it to appear.

Except there was a reason.

The conversation had been about finding the right term for my professional identity after 25+ years in software engineering. I’d rejected “legacy systems expert,” “distributed systems expert,” “polyglot developer.” Each label felt too narrow, too constraining. I was searching for a label that accurately described what I do, without being reductive or overly narrow.

Then Claude wrote: “This isn’t 职业 niche. It’s cognitive orientation.”

At first glance, this looks like a malfunction. Language models are supposed to maintain linguistic consistency. Cross-lingual “bleeding” is treated in research literature as an error to be fixed, a sign of inadequate language control mechanisms. Papers develop interventions to suppress it: language confusion gates, representation regularization, preference tuning.

But when I looked closer, I realized something: the “wrong” word was actually right.

What 职业 Means (And Why English Failed)

职业 (zhíyè) translates to “profession” or “occupation,” but the Chinese term carries different semantic weight than its English counterparts.

The composition matters:

• 职 (zhí): duty, post, office, responsibility

• 业 (yè): occupation, enterprise, course of study

The distinction: 职业 describes the structural position you occupy in the social-economic order. It’s what you write on forms, what you answer when strangers ask what you do. Crucially, it’s administratively neutral. It doesn’t presuppose you chose it, earned it, or that it defines your identity.

English “profession,” by contrast, is semantically loaded:

• Etymology from Latin professio: public declaration, from profiteri (to declare publicly, profess)

• Implies credentialed expertise and barriers to entry

• Carries status signaling (professional vs. worker, professional vs. amateur)

• Suggests self-actualization and individual agency

• Bundles together: economic role, expertise claims, social status, personal identity

The conversation had been actively deconstructing credentialism. I was rejecting labels precisely because they imported assumptions about expertise-based identity that didn’t fit what I was trying to describe. I needed a term that meant “the thing you do in the economic system” without implying “the expertise you profess.”

English doesn’t have one that’s both neutral and precise.

Mandarin does.

The Mechanism: Why Bleeds Occur

This isn’t random noise. It’s revealing something fundamental about how multilingual language models represent meaning.

Research on models like mBERT and XLM-RoBERTa has established that multilingual models create what researchers call “language-agnostic semantic spaces.” When these models process text in 100+ languages, semantically similar concepts cluster together in vector space regardless of which language they appear in. The Russian word “пустота,” English “void,” and Chinese “虚无” occupy proximate regions of embedding space.

Libovický et al. (2019) showed that these representations can be decomposed into language-specific and language-neutral components. The language-neutral component captures pure semantics, while language-specific elements function as surface-level “offsets.”

Here’s what this means for generation: when a model needs to express a concept, it first activates a region of semantic space, then samples a token from that region. Language consistency is a statistical constraint, not an architectural requirement. Under certain conditions (high temperature, semantic precision demands, frame contamination in the primary language), that constraint weakens.

What I observed was the model reaching into the shared semantic manifold and grabbing the nearest token that mapped cleanly to the active concept. That token happened to be Mandarin.

The Human Parallel

This isn’t unique to artificial systems. Bilingual humans do exactly the same thing.

Psycholinguists have documented what they call “semantic-driven code-switching.” Bilinguals don’t switch languages randomly. They switch when the target language provides better semantic fit for the concept they’re expressing.

Li (2011) identified three motivations for code-switching:

1. Lexical gaps (no equivalent exists in the primary language)

2. Semantic incongruence (an equivalent exists but doesn’t capture the intended meaning)

3. Medium-of-learning effects

The second category is critical. Sometimes a word exists in both languages, but one version carries unwanted semantic baggage. Switching languages isn’t about vocabulary deficits. It’s about maximizing expressive precision.

Tulloch & Hoff (2022) found that bilingual children code-switch not from vocabulary limitations but to “maximize their expressive power.” The brain activates concepts before selecting words. If the closest available token is in the “wrong” language, that’s the one that surfaces.

François Grosjean’s Complementarity Principle explains why: bilinguals acquire languages for different purposes and domains, creating non-overlapping semantic territories. You don’t have perfect synonyms across languages because the languages weren’t learned to do identical work.

Anyone who’s been bilingual long enough has experienced this: “Hand me the... Schraubenzieher” (German for screwdriver). Not because you forgot “screwdriver,” but because the German term was neurally closer in that moment.

LLMs are doing the computational equivalent.

Why This Matters

The dominant research paradigm treats cross-lingual generation as failure. Papers frame it as “language confusion” that must be mitigated. The assumption is that clean, monolingual output is always superior.

But recent work challenges this. Li et al. (2025) demonstrated that language mixing in bilingual LLMs causally enhances reasoning. When they forced models to generate monolingually, accuracy dropped by 5.6 percentage points on mathematical reasoning tasks. Language mixing wasn’t a bug. It was “strategic reasoning behavior.”

Their findings align with what I observed: the model didn’t fail at language control. It optimized for semantic precision.

The implications span multiple fields:

For AI research: This suggests that semantic representations in multilingual models are genuinely language-agnostic at the concept level. The “mistake” reveals that language tags are weak constraints in the latent space. Models don’t partition languages into discrete modules. They maintain a unified semantic manifold with per-language decoding biases.

For linguistics: This provides computational evidence for linguistic relativity. Languages don’t just label the same underlying reality differently. They carve semantic space along different dimensions. 职业 and “profession” aren’t exact translations because they occupy slightly different conceptual territories.

For cognitive science: The parallel between LLM cross-lingual substitution and human bilingual code-switching suggests these systems share architectural principles. Both activate concepts before language selection. Both can cross linguistic boundaries when precision demands it.

Naming the Phenomenon

I’m calling this Semantic Bleed: the phenomenon in multilingual neural systems (biological or computational) where concept activation triggers lexical retrieval from a non-contextual language because the target term provides semantically tighter mapping than available alternatives in the primary language.

This isn’t:

• Semantic interference (competition between semantically related words)

• Cross-lingual transfer (leveraging knowledge from one language to improve another)

• Language confusion (inability to consistently generate in the desired language)

• Off-target translation (producing output in the wrong language)

Those terms describe related phenomena but miss what makes this distinctive: it’s not about language control failure. It’s about semantic optimization through strategic cross-lingual lexical substitution.

The research literature has documented the behavior but hasn’t analyzed whether cross-lingual outputs are semantically superior. Papers focus on suppressing the phenomenon, not understanding when and why it might be beneficial.

What This Reveals

I’ve now observed this pattern three times across different LLM interactions. Each time, retrospective analysis shows the “wrong” language provided better semantic fit.

The 职业 case is the most thoroughly documented. The context reconstruction proves it wasn’t random: the model needed a term for “structural economic role” that didn’t import credentialist assumptions. English bundles too much together. Mandarin unbundles it.

The Russian instance (рассвет, meaning “dawn”) occurred in a different LLM entirely, suggesting this is model-agnostic behavior emerging from shared architectural principles in multilingual systems.

What you’re seeing in these moments:

A glimpse of the raw semantic geometry underneath language. The usual statistical guardrails (maintain linguistic consistency) fail briefly, and the naked computation shows through.

It’s like catching a bilingual person mid-sentence saying something in their other language, not because they forgot the word, but because the other language had exactly the right word for what they meant.

The difference: you can ask the human why. The LLM just shows you the trace.

Open Questions

This observation opens several research directions:

Can we predict when bleeds will occur? Li et al. developed probes to predict when language mixing benefits reasoning. Could similar methods identify contexts where cross-lingual substitution would improve semantic precision?

Are certain concept categories more prone to bleeding? My cases involved professional identity and temporal concepts. Do abstract, culturally-embedded concepts bleed more than concrete, universal ones?

Does bleed frequency correlate with semantic gap size? If we could quantify the semantic distance between near-synonyms across languages, would larger gaps predict higher bleed probability?

Can we use bleeds to map cross-lingual semantic spaces? Each bleed reveals a point where languages diverge semantically. Systematic collection could illuminate how different languages partition conceptual territory.

An Invitation

If you’ve observed this phenomenon (in LLMs or in your own multilingual cognition), I’d be interested to hear about it. What was the context? Which languages were involved? Could you reconstruct why the “wrong” language was semantically superior?

The research literature hasn’t systematically documented this at the word level. We’re watching something interesting about how meaning works in high-dimensional semantic spaces, and there’s more to learn.

References:

Conneau, A., Khandelwal, K., Goyal, N., Chaudhary, V., Wenzek, G., Guzmán, F., Grave, E., Ott, M., Zettlemoyer, L., & Stoyanov, V. (2020). Unsupervised Cross-lingual Representation Learning at Scale. Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics, 8440-8451.

Grosjean, F. (1982). Life with Two Languages: An Introduction to Bilingualism. Harvard University Press.

Li, D. C. S. (2011). Lexical gap, semantic incongruence, and the medium-of-learning effect: Evidence from Chinese-English code-switching in Hong Kong and Taiwan. In E. A. Anchimbe & S. A. Mforteh (Eds.), Postcolonial Linguistic Voices: Identity Choices and Representations (pp. 215-240). De Gruyter Mouton.

Li, Y., Xin, J., Miao, M., Long, Q., & Ungar, L. (2025). The Impact of Language Mixing on Bilingual LLM Reasoning. arXiv:2507.15849.

Libovický, J., Rosa, R., & Fraser, A. (2019). How Language-Neutral is Multilingual BERT? arXiv:1911.03310.

Marchisio, K., Huang, M., Al-Onaizan, Y., Bamba, A., Bokka, D., Chen, R., Dziri, N., Fadaee, M., Fung, Y., Goyal, N., Malmi, E., Ramachandran, S., & Sarkar, R. (2024). Understanding and Mitigating Language Confusion in LLMs. Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, 3632-3659.

Tulloch, M. K., & Hoff, E. (2022). Filling lexical gaps and more: code-switching for the power of expression by young bilinguals. Journal of Child Language, 50(4), 981-1004.

Zhang, B., Williams, P., Titov, I., & Sennrich, R. (2020). Improving Massively Multilingual Neural Machine Translation and Zero-Shot Translation. Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics, 1628-1639.

When your specialized product has somewhere in its 200+ item backlog a feature titled "Chat!" — you've entered the realm of dreams.

Here's the thing: large backlogs aren't roadmaps—they're the space of all possible roadmaps. When visionaries think their job is to conquer the galaxy, developers can't architect for infinite possibility.

That innocent "Chat!" line item isn't just about messaging. It's about real-time infrastructure you don't have, authentication systems that weren't designed for it, data models that suddenly need conversations, performance characteristics that assume synchronous workflows, and understanding human communication behavior around the product.

The cognitive load isn't just on developers trying to estimate unknowns. It's systemic entropy—when the "why" behind features remains based on archaic subjective personal data, every technical decision becomes archaeology. Big visions get adhered to at the beginning for theater, but execution complexity gets left till the end. Visions change, features get descoped,

but without any true redesign.

Here's the economic reality: Every hidden feature is uncertainty tax waiting to compound. Developer time spent reconstructing lost context instead of building value.

The path forward: Build simple architectures for your simple products first. Develop to increase your options. Control how tightly your code connects to manage change better. Give engineering more say in those endless business-driven roadmaps.

Domain complexity is hard enough. You can't manage what you can't measure, and you can't architect what you can't predict.

#SoftwareArchitecture #TechnicalDebt #ProductManagement #EngineeringLeadership

Key concepts to explore:

• Balancing Coupling - Vlad Khononov's model: volatility is necessary for optimal solutions, but unpredictable volatility (from secret roadmaps) breaks architectural decision-making

• Cognitive Load in Software - Beyond code complexity: developer time managing human factors, knowledge archaeology, linguistic chaos across codebases, and uncertain futures

• Constantine's Equivalence - Kent Beck: "the cost of software is approximately equal to the cost of changing it" - every architectural bet against invisible roadmaps compounds this cost

The revolutionary discovery that removing all user input from software development perfectly reveals the natural forces of organizational gravity. Development velocity directly correlates with Stack Impact Points (SIP) - nature's way of telling us users were the problem all along.

#TechHumor #AgileLife

She is quoted by Eric Schmidt saying, “I don’t know how to judge the user interface myself and none of my team do, but we know how to measure.” Consequently, Mayer set up A/B tests, which allowed the team to assess UI effectiveness through measurable outcomes. This method relied on analytics, such as dwell time, to gauge user engagement with different UI versions, enabling the team to make data-driven decisions.

The Living Nature of Software

Consider a bridge. Once built, its core characteristics are largely immutable:

• The steel and concrete remain unchanged

• Load-bearing calculations stay constant

• Physical laws govern its behavior predictably

Now, contrast this with a modern software system:

• Dependencies receive weekly updates

• User requirements evolve monthly

• Integration points multiply yearly

• The "ground" beneath our software (platforms, frameworks, security landscape) shifts constantly

The Dance of Evolution: Software and Its Users

Perhaps the most fascinating aspect of software development is how features evolve through a continuous dialogue with users. Unlike a bridge, where the final form is meticulously planned before construction begins, software features often:

• Start with an initial vision that's more hypothesis than specification

• Transform through user interaction and feedback

• Evolve in ways neither developers nor users initially imagined

• Create new user behaviors that in turn demand new features

Think of it like this: When users first requested "notifications," did anyone envision the sophisticated preference systems, delivery mechanisms, and integration points we have today? The very concept of what a "notification" means has evolved alongside user sophistication and expectations.

The Uncertainty Principle of Software Development

In user-facing software, we face a fundamental uncertainty:

• Users don't know exactly what they want until they see what they don't want

• Every feature we deploy educates users about new possibilities

• User needs evolve in response to the tools we provide

• Today's perfect solution becomes tomorrow's limiting factor

This creates a fascinating paradox: The more successfully we solve a problem, the more sophisticated our users become, leading to new and more complex requirements. It's a continuous cycle of growth and adaptation that no initial design can fully anticipate.

The Multi-Dimensional Challenge

When two teams build a bridge in the same location:

• They work with identical physical constraints

• Material properties remain constant

• Engineering principles apply uniformly

• Success criteria are clearly measurable

But when two teams build software for the same requirements:

• Architecture reflects organizational structure

• Behavior reflects subjective usability assessments

• Coding styles embed organizational cultures

• Success metrics often include subjective factors

The Continuous Evolution Paradox

Our systems must evolve while maintaining service:

• Scale dynamically with load

• Integrate new features weekly

• Refactor while serving live traffic

• Adapt to new security threats daily

• Welcome unforeseen integrations

• Respond to emerging user behaviors

• Accommodate shifting user expectations

Beyond the Metaphor

This isn't to diminish software engineering's rigor – quite the opposite. We've developed our own disciplines:

• Continuous Integration/Deployment

• Automated Testing

• A/B Testing and Feature Flags

• Usage Analytics and User Feedback Loops

These practices acknowledge software's unique nature: it's a living system that must evolve while running, shaped by an ongoing dialogue with its users.

The Art in the Engineering

Software development is both art and engineering because:

• Like engineering, it requires deep technical knowledge

• Like art, it demands creative problem-solving

• Like engineering, it needs systematic approaches

• Like art, it reflects its creators' perspectives

• Unlike both, it's in constant dialogue with its users

The next time someone compares software to bridge-building, remember: we're not just building bridges; we're creating living systems that grow and evolve with their users. Each feature is not an endpoint but a conversation starter, leading to new understandings and possibilities we couldn't have imagined at the outset.