I nerd out about lots of stuff, one of which is software development lifecycle (SDLC) methodologies.
I started my career in the world of waterfall. I developed and authored requirements and test plans. I was the process engineer at an aerospace consulting company that was trying to get DO-178B level C certification, and … hey, wake up, it’s not that boring.
I got a job with Amazon and learned about Scrum and Agile Development. I read books, took classes, learned Kanban, tried both Scrum and Kanban on my teams, and taught classes about Scrum and Kanban and the differences between them.
But now, I’m working in a post-AI world, and I think a new SDLC model is developing. It’s not quite vibe coding. It’s more swarming, or swarm-and-storming, but it’s also not that.
I’m seeing tiny groups of people – literally two or three – get together, take an epic, and burn through the equivalent of a two-week sprint’s worth of work in 3 days. They use their LLM of choice to refine their requirements, create the stories, and write the code, all in –dangerously-skip-permissions mode.
I’m seeing a product owner, a product manager, and a developer in a Slack channel, doing 2-day hackathons that spit out production code.
I’ve heard the term “10xing” (pronounced ten-ex-ing), and truth be told, I don’t like it. I think it’s more like Ultra-Kanban.
You’re putting one unit of work in the pipeline, and burning it down with the burner turned on max while pouring liquid oxygen over it.
The process engineer in the back of my head is screaming. The QA manager is crying in the corner of my subconscious. The current me is terrified, but curious, because I’ve been telling people for years that AI is the future of computer science, so doesn’t that mean I should embrace it?
I think we’re seeing the shift to a new software development paradigm, similar to the shift from waterfall to agile, but WAY more dangerous. You need better requirements, better testing, more robust pipelines, and easy rollbacks when there’s a production issue. I think if you can manage the cost of a defect in testing, deployment, and post-production (see: Boehm, 1981), then the advantage you get in the development time can easily offset the risk, while creating more opportunities for the big wins you need to grow a company.
I don’t know what it’s called yet, and I don’t know what the best practices it’s going to steal from Scrum, Kanban, and waterfall. I think someone’s going to write (probably already writing?) a book about how to do it right. The fundamentals still hold: know your customer, verify AND validate your requirements, invest in quality at the beginning of the lifecycle, quantify and mitigate your risks, and expect production failures.
But how? And how fast? Thoughts?
