majikandy

I think it really means fight hard to get the time, and choosing any time in particular doesn’t matter, weekend or weekday is irrelevant, it is just an agreement with yourself and those close to you that those times are reserved, a bit like sleep at say 11pm to 7am is non negotiable (unless you choose to).

Always heard about this but never tried it. Sounds like fun. Great description, very clear and much better than just saying it lowers the temperature! Nice writing.

Something like…

1. Bit of banter. 2. Talk about aging cards/blockers 3. Talk about the cards on the board, from right to left. Since further right is most important. 3. Share things with each other that came up since last standup that you think is worth sharing. 4. Ask for help. Offer help. How can I help you get that card over the line? 5. Final bants.

Yesterday, today, blockers… already feels like a relic from the past.

Apart from the fact they said making the code better each time?

Yes it works. You eventually get to a place that is “not too bad”, whilst still allowing new features to be developed and the business moving forward.

Or a senior team.

If someone incompetent can make me $20mil a year in revenue, bring on incompetence!

And critically… never completing an incremental rewrite doesn’t matter. Everything remained working the whole time and continues to make the company money. And as a bonus, you were also able to make feature changes that the business wanted at the same time. It’s classic XP, when the money runs out, the system still works!

For the love of refactoring.

Nah, the best teams don’t need QA.

Caveat - because you bake the QA in. The code itself is already quality assured. Then QA resources can do exploratory testing which does carry a separate value.

> writing a test first by design produces crappily designed and messy code?

So you don’t get a say in the test or the code? It just messes itself up?

Interesting thought, but every evangelist of TDD that I’ve met has nothing to gain other than wanting the code in production to be cheaper to write, more maintainable, proven to work, faster to market, the list goes on. They often care more about the business and the costs involved in software development and are usually pretty selfless.

Some people do tests, some people do development, and some people do test driven development.

If you are picking up some code to work on, the nicest to work with is the one that was done with TDD.

Since you don’t know how to solve it, you first write a test that goes vaguely in the direction.

If you can’t do that yet, you spike, mess around with it, get your bearings and some insight into where you want to go, try a few things out. Then, trash that and then write the first test as above.

It almost always works, and excels somewhat in legacy code vs just changing things.

It isn’t about ‘might work’. The TDD paradigm isn’t about finding shiny places where you can use. It is just a nice way of writing clean maintainable software in almost all areas.

Places where TDD won’t work are usually by exception rather than the norm.

Often those exceptions are where something already exists and wasn’t put in by TDD because by the definition of TDD you wouldn’t have been able to write that in the first place.

That also means they weren’t being run. So you aren’t even doing tests, let alone TDD.

Is it possible that it was those tests and code in the TDD cycle that helped you realise you’d gone down the wrong path?

And if not, perhaps there was a preconceived idea of the code block and what it was going to do, rather than specifying the behaviour wanted via the RGR cycle. With a preconceived idea, with or without the tests, if that idea is wrong, you’ll hit the dead end and have to back track. Fortunately I find that even though I do sometimes find myself in this situation, quite often those tests can be repurposed fairly quickly rather than being chucked away, after all the tests are still software, and not hardware.

Not sure why you got downvotes for this. It is a very effective technique.

Since typing speed was never the bottleneck in software development. Throwing away the little bit of code you wrote, it not expensive. And writing it back in with TDD is incredibly efficient.

I find it as close as I have ever found to a silver bullet.

I seem to remember this being mentioned in the original TDD book. To brain dump that next test scenario title you think of so as to get it out of your head and get back to the current scenario you are trying to make pass. So by the same idea as above, to not context switch between the part of the feature you are trying to get to work.

Snap, me too, amazing how many times it catches a simple mistake too like a < instead of > that you were certain you got the right way round as you wrote it.

It’s funny that in your paragraph there I thought you were about to write… “for that reason alone, TDD is the only way that makes sense to me.”

The reason is, the tests and the code are symbiotic, your tests prove the code works and your code proves the tests are correct. TDD guarantees you always have both of those parts. But granted it is not the only way to get those 2 parts.

You can still throw into the mix times when a bug is present, and it is this symbiotic relationship that helps you find the bug fast, change the test to exercise the newly discovered desired behaviour, see the test go red for the correct reason and then make the code tweak to pass the test (and see all the other tests still pass).

> The problem I’ve run into is that when you’re iterating fast, writing code takes double the time when you also have to write the tests.

The times I have believed this myself, often turned out to be wrong when the full cost of development was taken into account. And I came back to the code later wishing I had tests around it. So you end up TDDing only the bug fix and exercising that part of the code with the failing test and then the code correction.

I do the same. But almost always wish I had done TDD. The times I can bring myself to git reset —-hard after I have finished exploring and then TDD it in, the code benefits. Often though I can’t bring myself to do it and I retro fit in a few tests and reorder the commit history :)

It sounds a little like you are trying to write all the tests to the spec up front? With TDD you are still allowed to change design choices as you go and as you realise how you want it to behave. That’s why the tests are one by one. In my experience, TDD carries the most value when you really don’t know where you are going, you write the first test and you start rolling, and somehow you end up at your destination and people think you were good at writing code but actually the code was writing itself in a way as it evolved its was to completeness.

I have exactly this issue too. And I still procrastinate and don’t do them and sometimes get fines. I need something that prevents me using my phone or computer until it is done. Which probably means I’d just pretend it is and fake tick it off.

I could have written almost the same 2 paragraphs. Feels like you worked where I worked. Never again.

Interesting idea and it certainly makes sense to ensure working software at all times.

However it doesn’t have to be one or the other.

Sometimes a single commit (or PR if you prefer multiple commits) can update the api and all clients at the same time.

Sometimes client callers are external to the repo/company. In which case backward compatibility strategy is needed.

There is no need to abandon a concept of a single repo just because you might not use one of the main benefits all the time.

Not scalable though is it. If everyone only goes when needing something right now, there won’t be any shops left to be able to get something right now. I love the concept of local recommendations but yes real-ish-time inventory of local shops needs solving too.

It is totally ready for visitors. I visited, I enjoyed it. Doesn’t seem particularly wise to advise people something isn’t ready for people to visit, when those visitors are the only ones who can actually give useful feedback.