Timeline for TDD negative experience
Current License: CC BY-SA 3.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 7, 2019 at 13:11 | comment | added | tgm1024--Monica was mistreated | @CoreyD, you said "Without discipline, all projects are destined for failure." Perhaps I'd change that to "Without talent [...]" Or perhaps "Without expertise [...]". You cannot establish TDD as something constructive just by declaring it a discipline. There are plenty of disciplines that have no hope for improving a project quality or timeline. | |
| Apr 7, 2019 at 13:06 | comment | added | tgm1024--Monica was mistreated | "Like everything that comes under the "Agile" banner, TDD is something that sounds good in theory, but in practice" .....is mere confirmation bias. TDD falls into the same-old bucket of hyped-but-fruitless anti-ideas, becoming a co-denizen of eXtreme Programming, Rapid Prototyping and Flowcharts. I'd put Scrum in there as well, but my soapbox is only so big. | |
| Jul 27, 2018 at 12:54 | comment | added | Kyralessa | "Guys like Kent Beck demand..." Wrong. Have a look at what Kent Beck really says: How deep are your unit tests? | |
| Sep 26, 2014 at 22:23 | comment | added | weberc2 | "in fact people are even less likely to fix bad code because of all the test it will break" lol. Then those are the changes you probably don't want your team making. | |
| Sep 26, 2014 at 22:22 | comment | added | weberc2 | @jwenting TDD is like a lock on the door: it won't guarantee that an intruder will break in, but it makes it more difficult. Yes, you can write a bad test and write code that happens to allow that test to pass, but the odds of doing so are much lower than if you'd never written the test at all. | |
| Oct 28, 2011 at 15:55 | history | made wiki | Post Made Community Wiki by Cesar Canassa | ||
| Oct 28, 2011 at 15:33 | comment | added | Corey D | Without discipline, all projects are destined for failure. Anyone can throw together some buzzwords and be "agile." TDD is a tool in the toolbox. If you start with TDD without doing some sketches or whiteboard planning for something, you're using your hammer as a screwdriver. Sketch out rough ideas until you have something that makes sense. Start TDD. Change the design when you realize you didn't accommodate for X and Y. Get something finished, watch it run. Measure code coverage and add additional test cases. Move on to your next user story. | |
| Oct 28, 2011 at 14:39 | history | edited | user23157 | CC BY-SA 3.0 | added 5 characters in body |
| Aug 10, 2011 at 4:00 | vote | accept | SiberianGuy | ||
| Aug 10, 2011 at 4:00 | vote | accept | SiberianGuy | ||
| Aug 10, 2011 at 4:00 | |||||
| Aug 9, 2011 at 6:22 | comment | added | jwenting | Can add another problem: as long as it passes the test, it mush be good. Never mind that the test itself may well be flawed and thus causes false negatives and/or false positives. And of course requiring "100% test coverage" and anything that has such is by definition perfect, causing useless tests that don't actually test anything but are written solely to achieve that 100% coverage, code that's undocumented because your coverage counter counts comments as uncovered code, etc. etc. | |
| Aug 8, 2011 at 19:44 | vote | accept | SiberianGuy | ||
| Aug 10, 2011 at 3:59 | |||||
| Aug 5, 2011 at 2:21 | comment | added | Antonio2011a | Good comment. I disagree with one point though and that is that "TDD sounds good in theory". When I read Beck's book I instantly felt it was a bad idea. Note I don't disagree with unit testing, just TDD. | |
| Aug 5, 2011 at 1:39 | comment | added | ocodo | @The Mouth of a Cow - lazy managers interpret it as "I don't need to write anything down, all I need to do is chew the cud and get my guys to write code" - This is the typical problem with Agile adoption. To a lazy organisation, agile is an excuse to throw too few resources at a problem and then cry about it when it's not perfect... "But it was agile!!! How did we fail?!?!" | |
| Aug 4, 2011 at 18:20 | comment | added | user23157 | @Adam - "Do people really jump straight into coding on the first day of an iteration?" erm yep. That's "Agile" man. Last place I worked (and got fired from for not being "Agile") they did an entire 3 month release cycle without ever planning a single line of code or doing a single page of documentation. And yes the code was terrible and yes the software was slow, clunky and buggy. The day I joined I was told proudly by the manager that they were "The most Agile shop in London". They sure were. | |
| Aug 4, 2011 at 17:20 | comment | added | Aaronaught | @Adam: That statement is really not true. There are lots of things you can and should plan at the beginning of a project, even if there's a chance it might change. There are also a lot of things you shouldn't plan, even if they probably won't change. I've seen both extremes and lowercase "agile" is generally somewhere in the middle, but uppercase "Agile" methods all too often party in the cowboy district while lying to managers that they actually spent the night doing the safety dance. When used as tools, techniques like TDD are fine; as an end unto themselves, they're dangerous. | |
| Aug 4, 2011 at 17:12 | comment | added | Adam Jaskiewicz | I mean "up front" in the sense of "at the start of the project". Of course you plan before you start coding a user story; just not six months before. If you do, your plan is out of date by the time you can fit the story into an iteration. Do people really jump straight into coding on the first day of an iteration? I mean, if you have some simple stories that don't require much in the way of design, sure, but in my experience, the first few days are mostly spent sketching stuff on a whiteboard or legal pad. | |
| Aug 4, 2011 at 16:49 | comment | added | user23157 | @Aaronaught - I think a lot of people who have seen 'strict Agile' know that is just plain dangerous. The whole problem with the Agile mantra is that lazy managers interpret it as "I don't need to write anything down, all I need to do is chew the cud and get my guys to write code". Once you get through that you realise that planning a large piece of software is vital. That does't need to be "100s of pages of obsolete Documentation", but it does mean being analytical. Planning the tests is an important part of that. | |
| Aug 4, 2011 at 16:48 | comment | added | CesarGon | @Adam Jaskiewicz: I love the "no upfront planning" thing. C'mon, planning is upfront by definition. If you don't plan beforehand but during the event you are not planning at all; you are improvising. ;-) | |
| Aug 4, 2011 at 16:31 | comment | added | Adam Jaskiewicz | No, it means you don't plan up front. You do your planning as you need it, during the iterations/sprints. | |
| Aug 4, 2011 at 14:01 | comment | added | Aaronaught | @Adam: "Just in time" and "planned" are exact opposites. You're partially right; in a philosophical sense, Agile does not mean no planning, it just seeks to minimize unnecessary planning - however, the most common interpretation of specific Agile methods among programmers is to simply not plan. | |
| Aug 4, 2011 at 13:54 | comment | added | Adam Jaskiewicz | @Aaronaught Agile doesn't mean no planning, it means just in time planning. | |
| Aug 4, 2011 at 13:38 | history | edited | Adam Lear♦ | CC BY-SA 3.0 | deleted 41 characters in body |
| Aug 4, 2011 at 13:21 | comment | added | Aaronaught | The irony is that "designing the tests up front on a high level as part of the planning phase" is part of the Waterfall model. The difference with TDD is that no planning goes into it. Par for the course in strict Agile. | |
| Aug 4, 2011 at 12:45 | comment | added | Steven Jeuris | +1 "designing the tests up front on a high level as part of the planning phase - alongside the architectural design" Sounds a lot more reasonable to me as well. | |
| Aug 4, 2011 at 12:02 | history | answered | user23157 | CC BY-SA 3.0 |