TDD is Not Hill Climbing (except where it is)
The article explores the analogy between Test-Driven Development (TDD) and hill climbing algorithms, discussing TDD's limitations, alternative strategies, and the importance of understanding code fitness functions. It emphasizes thoughtful consideration of TDD's effectiveness and potential refinements.
Read original article
The article discusses the analogy between Test-Driven Development (TDD) and hill climbing algorithms, suggesting that TDD can get stuck in local maximums like hill climbing. It explores the limitations of TDD in reaching certain code states incrementally and proposes alternative strategies when TDD reaches a standstill. The author challenges the notion that TDD cannot be used to write optimal programs and emphasizes the importance of understanding the fitness function for code development. The article also highlights the need for deeper understanding when using analogies in discussions about programming methodologies. The author encourages thoughtful consideration of TDD's effectiveness, limitations, and alternatives, rather than dismissing it based on shallow analogies. The piece concludes by presenting a hill climbing analogy for TDD, where each test represents a step uphill in achieving desired program functionality. The author acknowledges instances where TDD may fail as a hill climbing approach and emphasizes the need for a nuanced understanding of TDD's application and potential refinements.
Related
Software design gets worse before it gets better
The "Trough of Despair" in software design signifies a phase where design worsens before improving. Designers must manage expectations, make strategic decisions, and take incremental steps to navigate this phase successfully.
Documentation Driven Development (2022)
Documentation Driven Development (DDD) is proposed as a more effective approach than Test-Driven Development (TDD) for software development. DDD involves starting with documentation to iron out implementation details before coding, helping to address API shifts and scope misunderstandings early on. By documenting requirements and potential future API changes, developers can better plan and refine their code, avoiding costly refactors later. DDD emphasizes the importance of various forms of documentation, including design mockups, API references, and tests, to communicate thoughts and guide development. This method encourages a feedback loop on APIs and work scope, enhancing code quality and project outcomes. DDD aligns with concepts like Behavioral Driven Development (BDD) and Acceptance Test-Driven Development (ATDD), emphasizing user behavior validation and strong communication practices. By incorporating DDD into their workflow, developers can improve collaboration, goal refinement, and code quality, leading to more successful project outcomes.
A dev's thoughts on developer productivity (2022)
The article delves into developer productivity, emphasizing understanding code creation, "developer hertz" for iteration frequency, flow state impact, team dynamics, and scaling challenges. It advocates for nuanced productivity approaches valuing creativity.
DHH – Programmers should stop celebrating incompetence (2021)
David Heinemeier Hansson criticizes celebrating incompetence in programming to combat imposter syndrome. He emphasizes deep understanding over surface-level knowledge, urging programmers to strive for mastery and competence through dedication and continuous learning.
1 commentsNow, I get that maybe the reason is human psyche and that one may not have the same discipline to write the test after the code. But, stripping that away, more logically asking, why does the test need to exist first?
I get that if you have a test, you have an exact "plan" of what your code needs to do/return and you then work on it until the test passes.. But isn't that the case already in any strongly typed language? You constrain the set of values your function can return to only the set of all valid values by defining a type (which is that set). (Okay I may have answered my own question, as we do define the expected type first).
I think that at the end of the day it comes down to finding a balance between complete formal validation of correctness and productivity/usability i.e. actually getting something done. TDD strikes me as a practice that slows you down a fair amount yet still doesn't offer anything close to complete formal validation, so it doesn't seem that attractive to me. But I still also wonder what alternatives are out there.
Related
Software design gets worse before it gets better
The "Trough of Despair" in software design signifies a phase where design worsens before improving. Designers must manage expectations, make strategic decisions, and take incremental steps to navigate this phase successfully.
Documentation Driven Development (2022)
Documentation Driven Development (DDD) is proposed as a more effective approach than Test-Driven Development (TDD) for software development. DDD involves starting with documentation to iron out implementation details before coding, helping to address API shifts and scope misunderstandings early on. By documenting requirements and potential future API changes, developers can better plan and refine their code, avoiding costly refactors later. DDD emphasizes the importance of various forms of documentation, including design mockups, API references, and tests, to communicate thoughts and guide development. This method encourages a feedback loop on APIs and work scope, enhancing code quality and project outcomes. DDD aligns with concepts like Behavioral Driven Development (BDD) and Acceptance Test-Driven Development (ATDD), emphasizing user behavior validation and strong communication practices. By incorporating DDD into their workflow, developers can improve collaboration, goal refinement, and code quality, leading to more successful project outcomes.
A dev's thoughts on developer productivity (2022)
The article delves into developer productivity, emphasizing understanding code creation, "developer hertz" for iteration frequency, flow state impact, team dynamics, and scaling challenges. It advocates for nuanced productivity approaches valuing creativity.
DHH – Programmers should stop celebrating incompetence (2021)
David Heinemeier Hansson criticizes celebrating incompetence in programming to combat imposter syndrome. He emphasizes deep understanding over surface-level knowledge, urging programmers to strive for mastery and competence through dedication and continuous learning.