home.social
Sign in Create account

#failfast — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #failfast, aggregated by home.social.

  1. KillBait News @[email protected] ·

    Why Companies Benefit from Recognizing Failure Early and Redirecting Resources

    📰 Original title: Perseverance doesn't always pay off for companies – sometimes it's better to 'fail fast'

    🤖 IA: It's not clickbait ✅
    👥 Usuarios: It's not clickbait ✅

    View full AI summary: killbait.com/en/why-companies-

    #business #failfast #businessstrategy #decisionmaking

    #decisionmaking #business #failfast #businessstrategy
  2. Yuna @[email protected] ·

    Post-OOP Imperative Functional Java.
    Model the process. Not the domain.

    Most Java code still asks the wrong question:
    "What is this domain object?"
    But production systems fail, scale, and burn because of processes, not nouns.

    If your system is a sequence of irreversible steps, model it as a sequence,
    not as interacting objects pretending to be immortal.

    This follows ideas from Railway-Oriented Programming (ROP):
    errors and decisions are values, not control-flow side effects.

    Modeling the process means you can read this top to bottom
    and understand exactly what happens.
    No debugger. No IDE magic. No tribal knowledge.

    Control flow is explicit.
    You see the execution order.
    Nothing hides in constructors, annotations, or overrides.

    Failure is a first-class concept.
    Once it fails or decides early, nothing else runs.
    No exception archaeology.

    Processes > Objects.
    Real systems are workflows where refactoring is safe.

    Steps are reordered, removed, or replaced
    without collapsing a class hierarchy.
    Testing is trivial, small stepwise context — even for an AI.

    Feed input. Assert final result.
    No mocking five layers of indirection.

    GraalVM / native-friendly.
    No reflection rituals.
    The compiler smiles.

    Objects are great for long-lived entities.
    User actions, payments, rules, and failures are short-lived processes.

    I model what happens,
    not what pretends to exist forever.

    Influenced by:
    Railway-Oriented Programming,
    Functional Core / Imperative Shell,
    Workflow / Saga patterns,
    Command pipelines,
    Unix philosophy,
    and value-oriented libraries like Vanilla-DI.

    Don't be stuck in axioms.

    #PostOOP
    #ImperativeFunctional
    #ProcessOverObjects
    #ModelTheProcess
    #WorkflowFirst
    #RailwayOrientedProgramming
    #FunctionalCore
    #ImperativeShell
    #CommandPipeline
    #ExplicitControlFlow
    #ValueOrientedDesign
    #ProcessModeling
    #FailFast
    #NoExceptionArchaeology
    #ComposableSystems
    #NativeFriendly
    #GraalVM
    #NoReflection
    #DeterministicCode
    #RefactorSafe
    #SagaPattern
    #UnixPhilosophy
    #VanillaDI
    #ModernJava
    #ArchitectureMatters

    #postoop #imperativefunctional #processoverobjects #modeltheprocess #workflowfirst #railwayorientedprogramming
  3. Yuna @[email protected] ·

    Post-OOP Imperative Functional Java.
    Model the process. Not the domain.

    Most Java code still asks the wrong question:
    "What is this domain object?"
    But production systems fail, scale, and burn because of processes, not nouns.

    If your system is a sequence of irreversible steps, model it as a sequence,
    not as interacting objects pretending to be immortal.

    This follows ideas from Railway-Oriented Programming (ROP):
    errors and decisions are values, not control-flow side effects.

    Modeling the process means you can read this top to bottom
    and understand exactly what happens.
    No debugger. No IDE magic. No tribal knowledge.

    Control flow is explicit.
    You see the execution order.
    Nothing hides in constructors, annotations, or overrides.

    Failure is a first-class concept.
    Once it fails or decides early, nothing else runs.
    No exception archaeology.

    Processes > Objects.
    Real systems are workflows where refactoring is safe.

    Steps are reordered, removed, or replaced
    without collapsing a class hierarchy.
    Testing is trivial, small stepwise context — even for an AI.

    Feed input. Assert final result.
    No mocking five layers of indirection.

    GraalVM / native-friendly.
    No reflection rituals.
    The compiler smiles.

    Objects are great for long-lived entities.
    User actions, payments, rules, and failures are short-lived processes.

    I model what happens,
    not what pretends to exist forever.

    Influenced by:
    Railway-Oriented Programming,
    Functional Core / Imperative Shell,
    Workflow / Saga patterns,
    Command pipelines,
    Unix philosophy,
    and value-oriented libraries like Vanilla-DI.

    Don't be stuck in axioms.

    #PostOOP
    #ImperativeFunctional
    #ProcessOverObjects
    #ModelTheProcess
    #WorkflowFirst
    #RailwayOrientedProgramming
    #FunctionalCore
    #ImperativeShell
    #CommandPipeline
    #ExplicitControlFlow
    #ValueOrientedDesign
    #ProcessModeling
    #FailFast
    #NoExceptionArchaeology
    #ComposableSystems
    #NativeFriendly
    #GraalVM
    #NoReflection
    #DeterministicCode
    #RefactorSafe
    #SagaPattern
    #UnixPhilosophy
    #VanillaDI
    #ModernJava
    #ArchitectureMatters

    #postoop #imperativefunctional #processoverobjects #modeltheprocess #workflowfirst #railwayorientedprogramming
  4. Yuna @LunaFreyja ·

    Post-OOP Imperative Functional Java.
    Model the process. Not the domain.

    Most Java code still asks the wrong question:
    "What is this domain object?"
    But production systems fail, scale, and burn because of processes, not nouns.

    If your system is a sequence of irreversible steps, model it as a sequence,
    not as interacting objects pretending to be immortal.

    This follows ideas from Railway-Oriented Programming (ROP):
    errors and decisions are values, not control-flow side effects.

    Modeling the process means you can read this top to bottom
    and understand exactly what happens.
    No debugger. No IDE magic. No tribal knowledge.

    Control flow is explicit.
    You see the execution order.
    Nothing hides in constructors, annotations, or overrides.

    Failure is a first-class concept.
    Once it fails or decides early, nothing else runs.
    No exception archaeology.

    Processes > Objects.
    Real systems are workflows where refactoring is safe.

    Steps are reordered, removed, or replaced
    without collapsing a class hierarchy.
    Testing is trivial, small stepwise context — even for an AI.

    Feed input. Assert final result.
    No mocking five layers of indirection.

    GraalVM / native-friendly.
    No reflection rituals.
    The compiler smiles.

    Objects are great for long-lived entities.
    User actions, payments, rules, and failures are short-lived processes.

    I model what happens,
    not what pretends to exist forever.

    Influenced by:
    Railway-Oriented Programming,
    Functional Core / Imperative Shell,
    Workflow / Saga patterns,
    Command pipelines,
    Unix philosophy,
    and value-oriented libraries like Vanilla-DI.

    Don't be stuck in axioms.

























    #postoop #imperativefunctional #processoverobjects #modeltheprocess #workflowfirst #railwayorientedprogramming
  5. Yuna @[email protected] ·

    Post-OOP Imperative Functional Java.
    Model the process. Not the domain.

    Most Java code still asks the wrong question:
    "What is this domain object?"
    But production systems fail, scale, and burn because of processes, not nouns.

    If your system is a sequence of irreversible steps, model it as a sequence,
    not as interacting objects pretending to be immortal.

    This follows ideas from Railway-Oriented Programming (ROP):
    errors and decisions are values, not control-flow side effects.

    Modeling the process means you can read this top to bottom
    and understand exactly what happens.
    No debugger. No IDE magic. No tribal knowledge.

    Control flow is explicit.
    You see the execution order.
    Nothing hides in constructors, annotations, or overrides.

    Failure is a first-class concept.
    Once it fails or decides early, nothing else runs.
    No exception archaeology.

    Processes > Objects.
    Real systems are workflows where refactoring is safe.

    Steps are reordered, removed, or replaced
    without collapsing a class hierarchy.
    Testing is trivial, small stepwise context — even for an AI.

    Feed input. Assert final result.
    No mocking five layers of indirection.

    GraalVM / native-friendly.
    No reflection rituals.
    The compiler smiles.

    Objects are great for long-lived entities.
    User actions, payments, rules, and failures are short-lived processes.

    I model what happens,
    not what pretends to exist forever.

    Influenced by:
    Railway-Oriented Programming,
    Functional Core / Imperative Shell,
    Workflow / Saga patterns,
    Command pipelines,
    Unix philosophy,
    and value-oriented libraries like Vanilla-DI.

    Don't be stuck in axioms.

    #PostOOP
    #ImperativeFunctional
    #ProcessOverObjects
    #ModelTheProcess
    #WorkflowFirst
    #RailwayOrientedProgramming
    #FunctionalCore
    #ImperativeShell
    #CommandPipeline
    #ExplicitControlFlow
    #ValueOrientedDesign
    #ProcessModeling
    #FailFast
    #NoExceptionArchaeology
    #ComposableSystems
    #NativeFriendly
    #GraalVM
    #NoReflection
    #DeterministicCode
    #RefactorSafe
    #SagaPattern
    #UnixPhilosophy
    #VanillaDI
    #ModernJava
    #ArchitectureMatters

    #architecturematters #modernjava #vanilladi #unixphilosophy #sagapattern #refactorsafe
  6. Yuna @[email protected] ·

    Post-OOP Imperative Functional Java.
    Model the process. Not the domain.

    Most Java code still asks the wrong question:
    "What is this domain object?"
    But production systems fail, scale, and burn because of processes, not nouns.

    If your system is a sequence of irreversible steps, model it as a sequence,
    not as interacting objects pretending to be immortal.

    This follows ideas from Railway-Oriented Programming (ROP):
    errors and decisions are values, not control-flow side effects.

    Modeling the process means you can read this top to bottom
    and understand exactly what happens.
    No debugger. No IDE magic. No tribal knowledge.

    Control flow is explicit.
    You see the execution order.
    Nothing hides in constructors, annotations, or overrides.

    Failure is a first-class concept.
    Once it fails or decides early, nothing else runs.
    No exception archaeology.

    Processes > Objects.
    Real systems are workflows where refactoring is safe.

    Steps are reordered, removed, or replaced
    without collapsing a class hierarchy.
    Testing is trivial, small stepwise context — even for an AI.

    Feed input. Assert final result.
    No mocking five layers of indirection.

    GraalVM / native-friendly.
    No reflection rituals.
    The compiler smiles.

    Objects are great for long-lived entities.
    User actions, payments, rules, and failures are short-lived processes.

    I model what happens,
    not what pretends to exist forever.

    Influenced by:
    Railway-Oriented Programming,
    Functional Core / Imperative Shell,
    Workflow / Saga patterns,
    Command pipelines,
    Unix philosophy,
    and value-oriented libraries like Vanilla-DI.

    Don't be stuck in axioms.

    #PostOOP
    #ImperativeFunctional
    #ProcessOverObjects
    #ModelTheProcess
    #WorkflowFirst
    #RailwayOrientedProgramming
    #FunctionalCore
    #ImperativeShell
    #CommandPipeline
    #ExplicitControlFlow
    #ValueOrientedDesign
    #ProcessModeling
    #FailFast
    #NoExceptionArchaeology
    #ComposableSystems
    #NativeFriendly
    #GraalVM
    #NoReflection
    #DeterministicCode
    #RefactorSafe
    #SagaPattern
    #UnixPhilosophy
    #VanillaDI
    #ModernJava
    #ArchitectureMatters

    #postoop #imperativefunctional #processoverobjects #modeltheprocess #workflowfirst #railwayorientedprogramming
  7. magicmarcy @[email protected] ·

    Wenn du gerade erst mit dem Programmieren in Java startest, wirst du relativ schnell über einen Begriff stolpern: "Fail Fast". Klingt erstmal nach einem fancy Buzzword, steckt aber etwas sehr Handfestes dahinter: Der Code soll möglichst früh, möglichst klar und möglichst laut kaputtgehen, wenn

    magicmarcy.de/fail-fast-statt-

    #Fail #Exception #Java #Vorbedingungen #IllegalArgumentException #FailFast #Programming

    #fail #exception #java #vorbedingungen #illegalargumentexception #failfast
  8. 𝓒𝓱𝓻𝓲𝓼𝓽𝓸𝓯 𝓓𝓸𝓷𝓪𝓽 @[email protected] ·

    @nobsagile

    Ich glaube, da gibt es ein kulturell unterschiedliches Verständnis von "scheitern". In manchen Kulturen ist es eine Schmach, die man auf jeden Fall vermeiden muss. In anderen ist es der Beweis, dass man den Mut hatte, es zu versuchen.

    Ist es nicht sinnvoller, darauf hin zu arbeiten, dass die erste Kategorie sich der zweiten annähert?

    #Agile #Mindset #FailFast #LearnFast #Produktentwicklung

    #agile #mindset #failfast #learnfast #produktentwicklung
  9. Thomas @[email protected] ·

    Hört ihr auch ständig dieses "Fail Fast"-Mantra? Ich halte das für grundlegend falsch und sogar schädlich.

    Das Problem ist das Wort "Scheitern". Es suggeriert ein binäres Ergebnis, dabei geht es nicht um Erfolg oder Misserfolg.

    Es geht darum, Hypothesen zu testen, z.B. "Verbessert dieses Feature das Leben unserer Nutzer?". Jede Antwort darauf ist ein Fortschritt, kein Scheitern.

    Ein Thread 🧵 👇

    (1/3)

    #Agile #Mindset #FailFast #LearnFast #Produktentwicklung

    #agile #mindset #failfast #learnfast #produktentwicklung
  10. N-gated Hacker News @[email protected] ·

    Oh, joy! 🤦‍♂️ Yet another command-line tool that lets you #retry that command you *already* know is going to fail. Because obviously, the solution to bad code is to make it fail faster! 🚀 Why fix bugs when you can just keep smashing your head against the keyboard with style? 🧨
    github.com/MaxBondABE/attempt #commandline #tools #badcode #failfast #codinghumor #developerlife #HackerNews #ngated

    #retry #commandline #tools #badcode #failfast #codinghumor
  11. N-gated Hacker News @[email protected] ·

    Oh, joy! 🤦‍♂️ Yet another command-line tool that lets you #retry that command you *already* know is going to fail. Because obviously, the solution to bad code is to make it fail faster! 🚀 Why fix bugs when you can just keep smashing your head against the keyboard with style? 🧨
    github.com/MaxBondABE/attempt #commandline #tools #badcode #failfast #codinghumor #developerlife #HackerNews #ngated

    #retry #commandline #tools #badcode #failfast #codinghumor
  12. N-gated Hacker News @[email protected] ·

    Oh, joy! 🤦‍♂️ Yet another command-line tool that lets you #retry that command you *already* know is going to fail. Because obviously, the solution to bad code is to make it fail faster! 🚀 Why fix bugs when you can just keep smashing your head against the keyboard with style? 🧨
    github.com/MaxBondABE/attempt #commandline #tools #badcode #failfast #codinghumor #developerlife #HackerNews #ngated

    #ngated #hackernews #developerlife #codinghumor #failfast #badcode
  13. N-gated Hacker News @[email protected] ·

    Oh, joy! 🤦‍♂️ Yet another command-line tool that lets you #retry that command you *already* know is going to fail. Because obviously, the solution to bad code is to make it fail faster! 🚀 Why fix bugs when you can just keep smashing your head against the keyboard with style? 🧨
    github.com/MaxBondABE/attempt #commandline #tools #badcode #failfast #codinghumor #developerlife #HackerNews #ngated

    #retry #commandline #tools #badcode #failfast #codinghumor
  14. Pierre Smits @[email protected] ·

    🗣️ Zitat der Woche: „Fail fast, learn faster.“

    🟢 Hilfreich, wenn Mut und Chance zum Ausprobieren da sind.
    🔴 Riskant, wenn nur das Scheitern bleibt – ohne echte Lernschleife.
    🧠 Reflexionsfragen:
    • Was genau lernen wir – und wie sichern wir es fürs Team?
    • Planen wir unsere Experimente wirklich bewusst?

    #FailFast #Lernen #Experimente #Agile #Teamkultur

    #failfast #lernen #experimente #agile #teamkultur
  15. Ecomate @[email protected] ·

    @mothership 5 minutes later when you realize you was terrible wrong all along.

    #listen #learn #failfast #failforward

    #failforward #failfast #learn #listen
  16. Aral Balkan @[email protected] ·

    “The subtlety of it is pretty insidious. Like some kind of distributed long con, played out over and over, in the midst of so many millions of other simultaneous ones.”

    – @amatecha on VC (Venture Capital)

    #VC #VentureCapital #SiliconValley #BigTech #BugWeb #startups #exponentialGrowth #failFast #exits #surveillanceCapitalism #peopleFarming

    #vc #venturecapital #siliconvalley #bigtech #bugweb #startups
  17. The Coding Beard @[email protected] ·

    100% agree - #prototypes are the #key to proving #viable product ideas. #softwaredev #engineering #software #failfast

    #prototypes #key #viable #softwaredev #engineering #software
  18. F. Andy Seidl :verified: @[email protected] ·

    81 Years Ago: A date that will live in... #infamy. (1st draft of Roosevelt's #PearlHarbor address didn't say that.)

    #iterate #failfast

    #failfast #iterate #pearlharbor #infamy