DDD ~ Deck Driven Development
I recently found myself in a new development regime: Deck Driven Development, or DDD for short. We’re not talking about drivers for decks, like the Steam Deck. This is a very corporate way to drive development in the vibe coding era. The central piece is the Deck (a PDF or PowerPoint presentation passed around the client’s departments). Tomorrow (it’s always tomorrow), our contact needs to present it to an internal team, so the deadline is EOD.
The flow is more or less this: we use our harness of choice to generate a Markdown document explaining the methodology we want to use for the project. We review it against the initial brief and the comments and requests from the last meeting, turn it into a PDF or PPTX, and send it to the client. They use their harness of choice to interrogate the deck and generate an Excel workbook with mock data to stress-test the methodology. Out comes an Issues sheet.
The workbook comes back to us. We feed it to our harness, which judges each issue: valid, valid with minor modifications, or incorrect. We run a few internal iterations on real data with the half-developed analysis engine and app. Then we send back v2 of the deck, along with a log of resolved issues and updates. We hear nothing for three days. Then another update is needed by EOD because they have an internal meeting tomorrow and their harness has found new issues.
After a few rounds, you find yourself reintroducing concepts that disappeared from the client’s deck two versions ago (probably when (their) AI removed them).
The Deck also becomes the source of truth for the final implementation. Everyone has seen it, passed it around, and agreed on it. So that part kind of makes sense.
I’m not sure what I think about it yet. We’ve arrived at a fairly stable methodology, confirmed, reconfirmed, and rereconfirmed. I could do without all these EOD deadlines, though. The rush introduces errors, and things don’t get properly thought through. I’m all for fast iterations, but we need time to notice what changed between versions. Slowing down might look lazy in the short run. But by now I could have produced real results for them, if I hadn’t been so busy producing PDFs.