Write Twice
During discussions on the enduring identity of a prototype the same counterpoint kept cropping up:
You should only write code once.There's a prevailing belief that, in our lean workflow, we must be committed to our user stories before we enter them into Production, that it would be wasteful to create something, then change our minds and have to scrap it.
Why do we believe it to be wasteful?
Firstly, once upon a time, it was.
Turning an idea into a code reality used to be an huge investment; if we're truly working iteratively and being smart about being lazy, this is no longer the case.
Secondly, a number of our processes and nomenclature originate from physical manufacturing and engineering.
"Production" has connotations of cutting that first bit of metal, taking chisel to stone. I believe this clouds our understanding that code is, by design, a mutable medium.
Lastly, the notion persists due to a legacy of disharmony between those who write code, and those who work out what should be written.
The following are extremes, but they highlight the core issue which, I believe, exists to varying degrees in most teams.
What it feels like to write twice, to non-developers
You wade through weeks of Idea Showers and Brainswarmstormwall Sessions while expertly distilling these multi-stakeholder brain farts into a series of user stories, learning as you go, changing your mind about what matters and what doesn't on an hourly basis.
You prioritise your stories, pop them onto a Kanban board and Production begins.
Because you know that what's being created is only a best guess, and things may change at any point, you continue to test and learn.
Mid-way through a sprint you realise you were wrong about the underlying premise of the work being produced.
You inform the Production team, bitching commences.
What it feels like to write twice, to developers
You're given a series of user stories - a to-do list - you take pride in your work so focus on delivering them efficiently with the finest code you can muster.
Just as you feel you're near the end of the list, someone changes their mind, you're not sure why, but you now need to scrap your work and start again.
Back to the start of the to-do list. Frustration ensues.
Shifting focus
As I say, extreme cases, but I'm sure we can all relate to them on some level. The responsibility lies with all of us, developer or non-developer, to redress this disharmony.
Developers: Focus on the product, not your to-do list; you'll find it less frustrating to ditch your beautifully crafted code and start again.
Your code is not the product. The product is not your code.
Non-developers: If we're to ask developers to focus on the product as much as they do their code, they need to be involved from the start, they need to feel as invested in the product as they do their code-base.