After months of development, the application was deployed to production.
Users began using it immediately.
The senior developer asked, “When is the software finished?”
The developer replied, “When it’s deployed.”
“And when does it begin?”
What This Means for Your Practice
The koan presents a temporal paradox that mirrors the reality of modern software operations. We organize our work around deployment as a milestone – sprint planning points toward it, stakeholders wait for it, teams celebrate it. Yet anyone who has worked in production knows that deployment is neither completion nor commencement, but rather a phase transition.
Consider what actually happens at deployment. The code doesn’t fundamentally change in that moment – the same bytes that ran in staging now run in production. What changes is context. Real users with unpredictable behavior. Real data with unexpected edge cases. Real load patterns that differ from every synthetic test. The application that was “done” in one environment is suddenly “beginning” in another.
This creates a profound challenge for how we think about software completion. If deployment isn’t the end, what is? Many teams have moved toward continuous deployment, acknowledging that software is never truly finished but constantly evolving. Yet even this framing carries assumptions – it suggests ongoing addition and improvement. What about the moment when you stop working on something not because it’s perfect, but because priorities shift? Is that completion? Is that abandonment?
The senior developer’s counter-question – “And when does it begin?” – invites us to trace backward. Does software begin when users first interact with it? When it first runs in production? When the first test passes? When the first line of code is written? When the initial requirements are discussed? Each answer reveals different assumptions about what software fundamentally is.
For infrastructure and hosting professionals, this koan resonates particularly deeply. You maintain systems where the line between “development” and “operation” blurs. A configuration change, a scaling adjustment, a failover test – these aren’t separate from the software, they are the software continuously adapting to reality. The application is always simultaneously finished (it works right now) and unfinished (it will need changes tomorrow).
Perhaps the teaching here is about releasing our attachment to definitive states. Software exists in continuous becoming. Deployment is significant not because it marks an end or beginning, but because it marks a transition in relationship – from developers working in controlled environments to users working in the chaos of reality. Both before and after are necessary. Both are incomplete without the other.
What would change in your practice if you held deployment not as a boundary, but as a permeable membrane? If you designed systems with the explicit assumption that “finished” and “begun” are temporary labels we apply to something that flows continuously?