Agile resolves human communication failures. But what happens when the humans are taken out of the loop? I shipped my first product in 1998. Waterfall. 3 months of requirements documents, a month of design specs, and 4 months of engineering – followed by a go-live that revealed, with painful precision, that the stakeholder had wanted something slightly but critically different. We had built the right system for the wrong mental model. That experience wasn’t unique. It was the norm. And it’s exactly why a group of engineers and thinkers gathered in a Utah ski lodge in February 2001 and wrote…
J O H N R A . M E Posts
A few days after I published Part 2, a friend forwarded me a message. He’s been reading the blog on his phone during his commute, decided to open the live demo, and found that he couldn’t flag a single cell. He’s not wrong. On a touchscreen, right-click doesn’t exist. Context menus require a long-press that the browser intercepts before the game sees it. The entire flag mechanic – one of the two core interactions in Minesweeper – is simply inaccessible to anyone not sitting at a desk with a mouse. I’d known this. I’d filed it in the back of…
The planning session ended. I saved the conversation, and sat for a moment staring at the blank src/ directory on my screen. I’ve been in software long enough to know that the gap between a good architecture diagram and a working, tested application is where most projects succeed or fail. Anyone can draw boxes and arrows. The execution is where the real engineering happens – where the theory meets the edge cases, where the clean design confronts the messy reality of frameworks, tooling, and the particular perverseness of asynchronous state management. The question I was asking myself, honestly, was: does this hold up?…
I’ve just closed my laptop after a full day of meetings — roadmap reviews, architecture decisions, a particularly spirited debate over boundaries of our capabilities. The kind of day where you talk little about code and write even less of it. I’ve spent over twenty-five years in this industry. I started writing code when hard drives were measured in megabytes (my brother yelled at me for consuming couple of kilobytes of memory on his brand new Seagate hard drive on his 286), when “the web” meant blinking text on Netscape, and when the height of programmer ambition was getting your *.bas program…
Why TDD? Test-Driven Development flips the usual workflow on its head: instead of writing code and then testing it, you write a failing test first, then write just enough code to make it pass, then clean up. The result is a growing suite of tests that document exactly what the code must do — and a codebase that is only as complex as the tests demand. We will build a classic toy app — a Magic 8-Ball (Github)— from scratch using this discipline. The Red → Green → Refactor Cycle Every increment of TDD follows three phases: Phase Goal 🔴…