[Jtsummers]

I was going to say the same thing. His characterization of TDD as "writing a whole smattering of tests and then coding until they all pass" suggests he's gotten some bad information about TDD. Sadly common, though.

His TLD is pretty much TDD except he doesn't mention refactoring after passing the tests. Even leaving a failing test at the end of the day as a kind of "todo" for the next day, I'm pretty sure Beck mentioned using that idea in his TDD book.

EDIT: Found it finally. From Beck's Test-Driven Development by Example (page unknown, ebook copy, chapter 27):

> How do you leave a programming session when you're programming alone? Leave the last test broken.

> Richard Gabriel taught me the trick of finishing a writing session in midsentence. When you sit back down, you look at the half-sentence and you have to figure out what you were thinking when you wrote it. Once you have the thought thread back, you finish the sentence and continue. Without the urge to finish the sentence, you can spend many minutes first sniffing around for what to work on next, then trying to remember your mental state, then finally getting back to typing.

> I tried the analogous technique for my solo projects, and I really like the effect. Finish a solo session by writing a test case and running it to be sure it doesn't pass. When you come back to the code, you then have an obvious place to start. You have an obvious, concrete bookmark to help you remember what you were thinking; and making that test work should be quick work, so you'll quickly get your feet back on that victory road.

> I thought it would bother me to have a test broken overnight. It doesn't, I think because I know that the program isn't finished. A broken test doesn't make the program any less finished, it just makes the status of the program manifest. The ability to pick up a thread of development quickly after weeks of hiatus is worth that little twinge of walking away from a red bar.

[alasdair_]

Beck had this process (test, code, refactor) in place in his original eXtreme Programming book, which helped spawn the whole “agile” movement. It’s kind of cool to see how the process was refined over time.

It’s also sad to see how twisted people’s idea of both agile and tdd have become, usually because they never read the source material.

[switchbak]

Having been involved in that world from pretty early on, I must admit I'm pretty appalled at the odd interpretations I get both on HN an in real life.

I'm not sure where to put the blame, but "Agile" does get a particularly bad rap these days. Mostly I'd say a corporate watering down of Agile concepts, money hungry consultants who didn't know much, and I h ave a personal dislike of how most of SCRUM tends to be implemented.

TDD in particular has fallen off the map in a way that I find very surprising. Generational amnesia I suppose.

[throwawaymaths]

I mean we should get used to this kind of stuff and just accept that Agile means "corporate agile" and just call classical agile that. Just like how OOP today means "like c++" and not whatever smalltalk is.

[mpweiher]

> corporate watering down of Agile concepts

I think inverting agile concepts is more accurate.

[Jtsummers]

It's very common. When I was working at a USAF base they decided to adopt Lean. What they actually implemented was almost the exact opposite of Lean in every way, almost comically so.

A key element of Lean is empowering the workers to improve the processes. Let them come up with ideas that improve things and run experiments (guided by management perhaps, but not directed by). But the way USAF did it, the managers would watch a process being done, identify "wasted" movement, and then rewrite the process/procedures to eliminate that wasted movement. It was clearly just Scientific Management but being called Lean because they "leaned out" the processes. Naturally, the actual workers did not like coming in every other week and having to learn their job all over again. After a while they still held "Lean Events" but by then it was for show rather than to actually effect change in how things were done.

[evil-olive]

I once interviewed at a place that told me they did "design sprints", "coding sprints", "integration sprints", and "testing sprints"

[Gibbon1]

Corporate agile looks from a distance like waterfall in a dress if you get my drift.

[smaudet]

Once the scrum "masters" start becoming unspoken management, then you know the process has got off the rails and is no longer agile.

Sometimes it makes sense, corps don't actually have any need to churn out new features, at that point you just have kanban, or even waterfall. Be nice to stop pretending, though.

[dccoolgai]

Agile is a lot like Communism: there's a lot of people who swear it works great but everywhere it seems to have been tried it hasn't gone well... And the apologists just insist "those places didn't understand it and do it right".

[orzig]

I worked at a big company which did a full agile transformation, including full-time, agile coaches. I imagine everyone hired afterwords hated agile for the very real swirl the process caused, but those of us who’d been there before know it was FAR better than that chaos.

I also worked at a funded start up that implemented agile from the beginning, worked pretty great.

[imtringued]

I don't understand this recent pushback against agile development.

Do you really want to go back to the waterfall and V model style of development? Those are basically guaranteed failures in a fast moving industry like software development. If anything your comparison should be applied to the waterfall/V model because it is essentially central planning.

If you are doing things like building MVPs, iterated/incremental development with frequent changes and deployments to production then you are doing agile development.

Maybe it is not hyper formalized like Scrum but it is agile nevertheless.

[garethrowlands]

I've seen agile working well at a fairly big company.

[throwawaymaths]

There's a bias there, I think there are a lot of small shops where agile works great and you mostly hear about big shops that use it where it will never work great because you probably don't care that much about SmallTechCo.

Versus communism where people (e.g. Benjamin Tucker) were predicting its primary failure mode decades before it ever was instantiated at any scale.

[Jtsummers]

Small shops have a benefit of freedom of choice that large corps often don't give to workers. Sometimes it's accidental, sometimes deliberate, but large corporations have a tendency to want a single defined process. Variation (or as they'd call it "deviation") from that process is bad (it's not, but from the corporate management perspective it is). It has to be justified, you have to prove the thing you want to do will work before you can even try it to demonstrate that it does or does not work.

This hinders freedom to experiment with new techniques and methods within development teams, but it doesn't stop it. A "trick" is to provide all the artifacts that they want as if you followed their process to the letter, but still do things the way you want so long as it gets the job done. The problem with that is that you have no evidence you did things differently than the defined process and so they'll continue to believe the defined process is perfectly fine, if not excellent. Then some exec will decide to write a book about it and become a consultant selling the (broken) defined process (I assume this is how SAFe came to be, an ironically very rigid "agile" process).

[hxfjcuvyvy]

50 dev teams, every team can choose how they work and their own tooling.

The result: if you're not using safe you're lead is going to be removed. Zero consistency between project tooling.

It's like the worst of both worlds.

[ozim]

Process is not the problem.

People are the problem.

What I mostly see it is people doing it to themselves. Someone thinks he has to be guardian of the process and refuses to let the experiment run.

[throwawaymaths]

Excellent points.

[QuercusMax]

I don't know why you'd care about a brand new test being broken overnight. It's not like you're submitting the change yet anyway. It's just leaving a breadcrumb.

[uldo]

I think it is a good practice to push only working code, I think it stems from this. And it has a good point - you have finished something. Sometimes if you leave something “hanging” you keep thinking about it for a while, especially when falling asleep.

[sithlord]

its a good idea to push code before signing off, what if you get sick and someone needs to pick it up, or your computer dies. A small broken test can be fixed likely faster than reinventing the whole thing again.

[QuercusMax]

You commit and push your working code, then write a failing test and go home.

[uldo]

Yes, you are right about the technical aspect, but my comment was about psychology. Writing test and going to sleep is abit like asking a question to your friend and waiting for answer to the morning - it might get annoying.

[QuercusMax]

Have you tried it? It's actually quite refreshing since you don't need to remember what you were doing in the back of your mind. The test is there for whenever you get back to it.

[mrnonchalant]

I like this a lot actually l

[deckard1]

> (page unknown, ebook copy, chapter 27)

page 148 in the physical book, at least my copy.

However, you leave out the following section titled "Clean Check-in" in which Beck argues the exact opposite when working on a team. Clearly it's the days before git and trusting code to sit on your PC overnight without checking it in (I, too, would not trust Windows98 with code that long).

But this is the general problem with the book and TDD. It's outdated and overrated. The book is not a well-written book, even for year 2000 standards, and I'm quite surprised people are still referencing a 20 year old book that is almost entirely composed of trivial examples using Java classes and objects. It is my least favorite tech book on my shelf.

> leaving a failing test at the end of the day

As far as this point goes, you pretty much have to. The TDD methodology, per the book, is to get to green as fast as possible. If you are testing for a function to have inputs of 5 and 2 and expect an output of 10 then the book literally tells you to do:

  function() {
    return 5 * 2;
  }

What's going to happen is you write that code, get distracted or need to quit for the day, and you come back and your test is green. You forget that you wrote some total shit like the above and move on to the next Jira ticket.

As a methodology or system it's just bad. Imagine instead of writing the implementation to pass the tests that you instead are writing tests for some AI to "implement". You set the inputs and the expected outputs and the AI goes to work and does the implementation. In AI this would be called overfitting. Yes, the tests pass. But only for the cases you wrote. There is no guarantee your code works for the general case. Now replace AI with you and the same thing will happen. If all you care about is green tests you're liable to stop thinking of what the implementation should be doing.

Sure, you won't do that. But I promise you people, in general, do. One code base I worked on had minimum coverage required. More than half of the tests were total garbage. They either tested nothing useful, or were false positives that could never fail (because no one knows to check for failure, ever!). This is the opposite scenario, but the same outcome. It's the difference between the letter of the law and the spirit of the law. Give the people a rule to follow and they will mindlessly follow it.

Agile and TDD are both too nuanced and leave too much up for interpretation that it's no surprise we continually see debate on "true TDD" or "true Agile".

There are useful ideas in TDD. But this would be better packaged and sold as "here are some ways to build software under X scenario." These are techniques applicable to a time and place and not a paradigm.

[Jtsummers]

Yes, I was actually considering writing another comment about the next section and how that's (somewhat) changed thanks to git and better distributed version control systems these days.

Regarding that code snippet:

If you forgot that you hadn't finished it, and then check it in, then that's on you. Good news, hopefully you and your office aren't morons and you aren't relying just on the tests from the TDD bits, because TDD itself doesn't directly address creating integration and end to end tests. So your integration tests will catch that. And if not, it'll make it to production and your customers will, rightly, call you a moron. And you'll be embarrassed, write a test to catch the error, fix it, and hopefully not fuck up like that again.

TDD doesn't aim or claim to cover all the testing needed to verify and validate a system. It's one part of the whole (if you use it at all). In fact, it doesn't address validation at all so that's something you have to cover another way entirely.

> If all you care about is green tests you're liable to stop thinking of what the implementation should be doing.

If all you care about are green tests, I'd say you're aren't just liable to stop thinking but that you have stopped thinking. You have become, in my more polite way of saying it these days, a fool. My advice: Don't be a fool, you have a brain, use it.