{"id":688,"date":"2025-12-29T22:03:32","date_gmt":"2025-12-29T22:03:32","guid":{"rendered":"https:\/\/mityjohn.com\/?p=688"},"modified":"2025-12-29T22:24:39","modified_gmt":"2025-12-29T22:24:39","slug":"scrum-2-0-0-programming-by-intent-and-a-little-faith","status":"publish","type":"post","link":"https:\/\/mityjohn.com\/?p=688","title":{"rendered":"SCRUM 2.0.0 \u2014 Programming by Intent (and a Little Faith)"},"content":{"rendered":"\n

There\u2019s a moment in every side project when it stops being fun and starts becoming serious.
For SCRUM, that moment is version 2.0.0<\/strong>.<\/p>\n\n\n\n

Not because the syntax suddenly got stricter, or because someone wrote a 40-page spec. But because intent itself became a first-class citizen<\/strong> in the language. SCRUM 2.0.0 isn\u2019t about writing less code for the sake of cleverness\u2014it\u2019s about reducing cognitive overhead, lowering accidental complexity, and letting developers express what they want to happen<\/em>, not just how<\/em> to make it happen.<\/p>\n\n\n\n

This release marks the point where SCRUM moves from \u201cinteresting experiment\u201d to something you can genuinely reason about, build with, and trust.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

And yes, this involves Large Language Models at compile time<\/strong>.
No, this is not a runtime magic trick.
And yes, this will feel slightly uncomfortable at first. That\u2019s normal.<\/p>\n\n\n\n

\n\n\n\n

The Traditional Way: Java, Boilerplate, and Determination<\/h2>\n\n\n\n

Let\u2019s start with the familiar and (occasionally) love: traditional Java<\/strong>.<\/p>\n\n\n\n

In Java, even the simplest business rule requires a fair amount of ceremony. You describe intent indirectly, through classes, methods, conditionals, and defensive code. The compiler doesn\u2019t care why<\/em> you\u2019re doing something\u2014only that the syntax is valid and the types line up.<\/p>\n\n\n\n

public class HelloWorld {\n    public static void main(String[] args) {\n        System.out.println(\"Hello world!\");\n    }\n}<\/code><\/pre>\n\n\n\n
That\u2019s the simple<\/em> version. The moment you add input, logic, validation, or state, Java politely reminds you that:<\/p>\n\n\n\n
    \n
  • Types matter<\/li>\n\n\n\n
  • Structure matters<\/li>\n\n\n\n
  • And yes, you will<\/em> write all of it yourself<\/li>\n<\/ul>\n\n\n\n
    Java is explicit, powerful, and unforgiving \u2014 which is exactly why it scales.
    But it also means the intent<\/em> (\u201csay hello\u201d) gets buried under implementation<\/em>.<\/p>\n\n\n\n
    That precision has value. It\u2019s explicit, predictable, and leaves very little room for interpretation. But it also comes at a cost: verbosity, boilerplate, and a growing gap between business intent and implementation. The more complex the domain, the more effort is spent translating meaning<\/em> into mechanics.<\/p>\n\n\n\n
    Classic SCRUM: Still Explicit, Much More Human<\/h2>\n\n\n\n
    SCRUM already made a big step forward by expressing logic in business-readable terms<\/strong>.<\/p>\n\n\n\n
    SCRUM already tried to close that gap.<\/p>\n\n\n\n
    Instead of low-level constructs, you describe behavior using structured concepts like actors, conditions, and outcomes. You\u2019re no longer writing \u201ccode that happens to implement a rule\u201d; you\u2019re writing the rule itself.<\/p>\n\n\n\n
    Still, classic SCRUM remains explicit. Every condition, every edge case, every branch must be spelled out. It\u2019s readable, but it\u2019s still exhaustive. You describe intent\u2014yet you do so in full detail, step by step.<\/p>\n\n\n\n
    Here\u2019s Hello World<\/em> in classic SCRUM:<\/p>\n\n\n\n
    #SPRINTGOAL Deliver our first Scrum program\n\nEPIC \"SampleStories\"\n\n    USER STORY \"HelloWorld\"\n\n        #REVIEW Our first Scrum Program\n        SAY \"Hello world!\"\n\n    END OF STORY\n\nEND OF EPIC<\/code><\/pre>\n\n\n\n
    Compared to Java:<\/p>\n\n\n\n