I got involved in that movement before the word "Agile" existed; I was really interested in the ideas coming from the Extreme Programming folks and had tried them out on a small project in 2000. All of the people I met early on really wanted to do software well; the question was how to do it well and responsively. Unit and acceptance tests were just part of the process [1], and Kent Beck also wrote Test Driven Development By Example [2] around then. So in my view there was strong early interest in quality.
But this was all happening during the rise of the internet, which changed people's expectations for software delivery. Previously, releasing every 18 months was seen as reasonable. Suddenly the web was changing people's expectations. (Although not as fast as you'd think; a consultant pal told me in 2004 that Weight Watchers still had an annual release cycle for their website.) Executives and managers were under pressure to deliver faster.
As I wrote about elsewhere [3], that created a need for Agile that was filled not by the humanistic culture and quality-oriented practices of my end of the Agile world, but by consultants and certification programs watering down the material until executives could slap some new labels on their same old bullshit and call it Agile.
It turns out that bullshit long predates Agile. If you go back to Royce's original 1970 paper on Waterfall [4], one of his big points is that it doesn't work. Why, then, did it become the predominant way to organize software projects? Because it feels good to managers. For most of the project, it gives them a feeling of control and competence. That feeling is false, as it just delays all of the real-world feedback until near the nominal end. But they can perform confidence and competence to their boss, which is vital in managerialist [5] organizations.
So I totally agree with you that Agile on average has mutated into a garbage pipeline. And that happened through a whole industry that produced manager-friendly process theater that threw out a quality focus and most of the Agile values, while using the Agile labels. But I think the real responsibility lies in our management culture and values, which both precedes Agile and whose harm extends well beyond it.
[1] http://www.extremeprogramming.org/map/loops.html
[2] https://www.oreilly.com/library/view/test-driven-development...
[3] https://web.archive.org/web/20170923232057/http://agilefocus...
[4] https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a...
[5] See, e.g., https://www.bloomsbury.com/us/confronting-managerialism-9781...
1. [The Pragmatic Programmer](https://pragprog.com) 2. Martin Fowler's [Refactoring Book](https://martinfowler.com/books/refactoring.html) 3. Kent Beck's [Test Driven Development: By Example](https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...) 4. [Thinking in Systems: A Primer](https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp...) 5. [Zen Mind, Beginner's Mind: Informal Talks on Zen Meditation and Practice](https://www.amazon.com/Zen-Mind-Beginners-Informal-Meditatio...) 6. [Pragmatic Thinking and Learning: Refactor Your Wetware](https://www.amazon.com/Pragmatic-Thinking-Learning-Refactor....)
Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
Vaughn Vernon, various: https://vaughnvernon.co/?page_id=168
Steve McConnell, Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2
Clean coder: https://cleancoders.com/ videos
Hunt and Thomas, The Pragmatic Programmer: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
Hitchhiker's Guide to Python: https://docs.python-guide.org/
Dustin Boswell The Art of Readable Code: https://www.amazon.com/Art-Readable-Code-Practical-Technique...
John Ousterhout, A Philosophy of Software Design: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... This one looks particularly interesting, thanks AlexCoventry!
Kent Beck, Test Driven Development: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...
Dan Bader, Python Tricks: The Book: https://dbader.org/
Ian Sommerville, Software Engineering: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...
Svilen Dobrev, various: http://www.svilendobrev.com/rabota/
- behind any given reason, there is a complex network of real reasons. You don't need to second-guess any decision/order/suggestion, but it helps understanding.
- most user stories / user requests are raw diamonds waiting to be polished. ("What do they really want me to solve")
Essential reading list:
- Clean Coder and Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma... https://www.amazon.com/Clean-Coder-Conduct-Professional-Prog...
- Test Driven Development by Kent Beck https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...
Yep. Uncle Bob is one person, too. tl;dr Think for yourself and don't listen to somebody just because they hurt your feelings.
> To pick a topical example: Is TDD hard in Rails apps because TDD is dead or because Rails makes TDD hard?
This is a misrepresentation of what DHH has said [1], which is that strict adherence to TDD can make your designs worse:
> Over the years, the test-first rhetoric got louder and angrier, though. More mean-spirited. And at times I got sucked into that fundamentalist vortex, feeling bad about not following the true gospel. Then I'd try test-first for a few weeks, only to drop it again when it started hurting my designs.
> Used as a hammer to beat down the nonbelievers, declare them unprofessional and unfit for writing software. A litmus test.
If you watch the conversations between DHH, Martin Fowler, and Kent Beck, it seems to me that they all agree: testing is good, test-driven design can be bad, and mocking everything is bad [2][3].
I took some time last week to re-read Uncle Bob's book, Agile Software Development, Principles, Patterns, and Practices [4], and Kent Beck's book on TDD [5]. There was a huge difference: Uncle Bob focuses on test-driven design, while Kent Beck focuses on test-driven development. Uncle Bob claims that test-driven development (especially through mocks) universally improves your design, because it reduces coupling and enables refactoring. Kent Beck talks about productivity, certainty, refactoring, and documentation. Uncle Bob says most of those things are just a side-benefit: the real point of TDD is decoupled design.
Uncle Bob's other book, The Clean Coder [6], berates people who do not strictly adhere to test-driven design: if you don't do it, you are unprofessional (he mentions this repeatedly). He says that TDD being universally good is a fact, and anybody who says otherwise is just ranting.
> Nowadays, however, they are just rants. The bottom line is that TDD works, and everybody needs to get over it.
> TDD is the professional option.
> It could be considered unprofessional not to use it.
The bottom line is that developers should listen to each opinion and use their head. Don't be hurt when somebody calls you unprofessional for not following the One True Gospel™ and mindlessly adopt practices. Don't be hurt when somebody says that mindlessly following those practices is counterproductive. Using your head is about the most professional thing you can do.
[1] TDD is dead. Long live testing. http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv... [2] Mockists Are Dead. Long Live Classicists. http://www.thoughtworks.com/insights/blog/mockists-are-dead-... [3] Is TDD Dead? https://www.youtube.com/watch?v=z9quxZsLcfo [4] Agile Software Development: Principles, Patterns, and Practices. http://www.amazon.com/Software-Development-Principles-Patter... [5] Test Driven Development By Example. http://www.amazon.com/Test-Driven-Development-By-Example/dp/... [6] The Clean Coder. http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
Edit: For those that don't know Kent Beck is basically the godfather of TDD.
[1] http://www.amazon.com/Test-Driven-Development-By-Example/dp/...
[2] http://pragprog.com/screencasts/v-kbtdd/test-driven-developm...
From "Test Driven Development" by Kent Beck, published 2002: http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0...
Here are some excerpts:
"What test do we need first? Looking at the list, the first test looks complicated. Start small or not at all. Multiplication, how hard could that be? We'll work on that one first."
The examples like this that were provided were of trivial methods. Trivial can be subjective, but, to me, methods whose bodies are almost always 2-5 lines long, not counting calls to other trivial methods, which may account for maybe another 2-3 additional lines, are basically trivial. It's one thing when you really don't need that much code, but it's another when you have classes upon classes upon classes upon classes, etc. to do something that could be OO and be in two classes with 1/2 as many lines and still be clear.
"Do these steps seem small to you? Remember TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps. Would I code day-to-day with steps this small? No. But when things get the least bit wierd, I'm glad I can."
This is what Kent meant, but few of us picked up on it, per the first comment to his answer in your example from S.O. and per my experience.
I'm not blaming Kent, Ron, etc. or even saying that they are or were wrong. But, the commonly understood epitome of TDD used to be 100% test coverage and methods for just about everything. Those in the know said more like 60% was better overall but that was not really "true TDD". The implication of 100% "trivial" methods is more overhead for method calls (minor cost, depending, but can be cumulative, increase/decrease call stack size more quickly, which is inefficient), a large number of entry points (more stuff can be null/nil, cause NPE's or need checks if you don't know what is going to call it later, though that can be mitigated somewhat), and just generally too many LOC.
Get the best books from Hacker News each week
Join 4,500+ subscribers and get the best books mentioned on Hacker News every Thursday.
By Kent Beck, right?
[1] https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...