Agile Otter Blog

 People are making a big deal about the new way of agentic working: Spec-Driven!!! But, wait... Big Design Up Front (BDUF) is something we tried for many years, in many companies, many times.  It was proven to be a losing proposition and a bad idea. We did it in the 80s, and by 96 or so we had alternatives.  If the idea of spec-driven is to fully detail a system up-front, and then use agents to implement it, then I think we're about to repeat a historic mistake  But, wait... BDD and TDD are also specification-driven, just in very tight loops with constant verification. The test acts as a specification, and we implement code to make all the tests pass. We do this incrementally and iteratively, adding tests as we go.  If the idea of spec-driven is to iteratively and incrementally build software covered by the safety mechanism of tests, and the feedback loop is tight, then maybe we're about to repeat one of the best ideas of the 20th and 21st centuries. But, wait.....

This is one of those things that just doesn't stick in my head, so I'm dropping this note to remind myself.  I often have trouble recalling cryptic variable names in bash, make, and perl. For my own sake, I thought I'd make a quick list of favorites and refer some sources.   Maybe you'll find this useful too.  Variable value, but exit if no such variable: ${var:?"error message"} Use default if   variable isn't set:  ${var:="default"} Get a substring : ${var: start: length}   Length: ${#var}  Uppercase:  ${var@U} Lowercase : ${var@L}   The first one is quite helpful when you expect a particular set of parameters and don't want to write if/then logic about each of them.   #/bin/env bash directory=${1:? You must provide a directory to search} pattern=${2:? You must provide a search term for filenames} find ${directory} -name ${pattern}   See more at the gnu shell expansion page. 

  A bit of background: I was chatting with some colleagues and friends this week about AI-augmented workflows.  M was talking about having LLMs "write the epics and features" for teams. He was envisioning a flow where a PO or PM would have much less cognitive effort and could do this work alone and then hand it off to the teams for execution. Of course, the teams are using LLMs to help with testing and code generation, and to explain code that should probably be refactored to make LLM explanations unnecessary. There are also AI code reviews, though they burn a lot of tokens for what they deliver. I was more cognisant that we should never (per Agile Manifesto) use tools or processes to reduce the interactions between humans doing the work, but might want to use them to improve or enhance those conversations. M talked about the really important conversations he wants to focus on: the discussion that happens when users and sponsors can see the working product increment and gi...