Re: [extremeprogramming] The principle behind How Test-Driven Development Works
"Tim Ottinger via Groups.Io" <[email protected]> Tue, 19 Nov 2019 19:09:08 +0000 (UTC)
| Newsgroups | gmane.comp.programming.extreme-programming |
|---|---|
| Message-ID | <[email protected]> |
Yes, and.... I always teach that the value/purpose/use of TDD is to enable quick and successful refactoring. The enablement is in feedback that the code still does (at least) what the developers think it should do. And, of course, this leads to understanding that tests which lock down the solution structure instead of the solution behavior are not good tests for TDD. They might be a good starting point (pin-down tests) but they’ll need to be refactored along with the code if we’re to create the conditions for rapid, safe refactoring. Tim Sent from Yahoo Mail for iPad On Tuesday, November 19, 2019, 12:49 PM, Steve Gordon <[email protected]> wrote: Any rigorous argument that does not start from the EXPLICIT axiom that the requirements are not known until after there is concrete feedback from appropriate stakeholders on working software that implement the current best guess at those requirements will lead to the conclusion that some form of waterfall is the most efficient way to develop software. If the premise is that we can know M requirements correctly N days in advance of delivering them, batches of size M implemented by enough teams to deliver them in M days is the most efficient way to deliver those requirements. This is why, for example, despite totally Agile principles, SAfE devolves into an unwieldy, bureaucratic, anti-agile mess due to concepts like the COD, WSJF, and ART, all of which assume we know what a sizable batch of requirements are before we get feedback on working software that implement the current best guess at those requirements. Software development is a people problem, not a technical problem. If you are explicit about the error-prone nature of human beings, it becomes obvious that we need feedback as early and often as possible. TDD provides feedback early and often, especially if we commit only to working with the customer on solving their problem rather than to a pre-specified solution to that problem. On Mon, Nov 18, 2019 at 1:26 PM J. B. Rainsberger <[email protected]> wrote: The mathematics of the argument don't matter as much as the self-similarity of the argument. When they see Waterfall turn into Lean Startup, it's hard to argue against the value of incorporating feedback. What about the math literally argues for top-down pre-design? I've never seen that argument. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#160236): https://groups.io/g/extremeprogramming/message/160236 Mute This Topic: https://groups.io/mt/39414677/2417047 Group Owner: [email protected] Unsubscribe: https://groups.io/g/extremeprogramming/leave/4902963/619838065/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-