- It's always better the second time.
- If it takes you more than 5-15 minutes
git reset -hardand start over. - Don't spend long in red. If you can't quikcly get to green revert back to a green state and start over.
There's a lot I've heard, and agree with, about how the second version is better. Only one of the above directly talks to that, but the others do in a subtle way.
If we spend too long trying to make something work, we're locking ourselves into that one path. What if it's a less than ideal path? What if it's a wrong path?
The revert points are specifically about learning. The result is better the second time because we've learned.
If we can't make it work in 15 minutes, that's OK, we've learned something, so we'll do better after reverting. If we're sitting in red too long, lets start over, we know things that don't get us to green.
We want to maximize the utilization of the things we're learning. The best way to do that is use the learningings IN THAT moment. It's why we do pair programming; code reviews are good, let's code review real time. Test feedback is good, let's get feedback before we even write the code.
If we are learning, let's apply that learning ASAP. The way I do this is to try and try again to get to green in under 5 minutes. A TCR (Test && Commit || Revert) approach takes this an even shorter time.
Once I've gotten to green, I can use everything I learned in those few minutes, and my entire career to refactor the code. I can use learning and knowledge to change the code into something better.
I don't have to wait for a story in the backlog to "Refactor BLAH". I advise never having tech debt stories in the back log... if you see it; fucking fix it! (Minus some acceptable larger scale architectural things).
I'm clearly in agreement with my interpretation of what this point means... I REALLY hate the wording though... because that's pretty easily taken to mean "Write it" then "write it again". I completely oppose this. We will do some things better, but we'll do different things less better. If we write the system new, we'll do better on the mistakes we know of, and make entirely new mistakes. The cycle of re-writes is never ending. We can never stop rewriting because we never learn how to improve the existing.
OK... Now it's time to read what the book has to say in it's blurb...
Oh.. No. No, no, no, no, no. Fucking hell I don't agree with that.
The whole thing is premised on an absence of refactoring. Seriously - Was refactoring not a thing in 1995? Fucking hell...
It gets worse. It's basically entirely premised on "Mythical Man Month" and a phrase Plan to throw one away; you will anyway. Cool story... yes-ish. You don't have to throw away the entire thing. What you wrote to meet the requirements SHOULD NOT be what you deploy. It won't be "thrown away" in the literal sense the book is advocating, but the fact you learn and improve the code as you work in it.
The worse part is one of the views that I think has held back our industry; that software should be replaced.
"be aware that you can fiddle wiht the program just so much before it becomes unstable and must be replaced"
...
What bullshit is that?
High quality code and refactoring are clearly not part of this author's wheelhouse because - holy shit is this wrong... Wrong wrong wrong wrong!
I stopped keeping count; I'm enjoying the ranting.
Yeah - Don't actually throw it away, unless you can't refactor... then... well... you'll never be able to work in a single system long term. Your peers will come to hate the garbage you produce.
Refactor. That's what we need to do. I advocate ruthlessly and until you can't.
But fucking hell - "you can only update code so long before it's too hard to work in"... fuck that. ... That one hurts my brain...