I've always thought that the transition from "test-first programming" in the late 1990s to "test-driven development" was influenced by the same kind of forces that moved us from "janitor" to "property custodian".
Junilu Lacar wrote:How well it supports the current requirements and how well it adapts to new requirements as they come?
You are never as ignorant as you are right now
Harry Kar wrote:Hi Corey,
The ancient Roman architect Vitruvius considered the question:
what makes a good building?
In his treatise De Architectura Libri Dece (Ten Books on Architecture), written in 29 B.C., he proposed three principles that many think provide a good starting point for
evaluating software designs.
A well-designed building, said Vitruvius, should have the qualities of commodity, firmness, and delight.
Based on your experience what you think about those considerations and what is the best way to meet commodity, firmness, and delight qualities in a well balanced manner?
TIA
Harry
meenakshi sundar wrote:
Dear Author,
On theory, Design drives implementation, but in the real world I have seen on many occasions a good design implemented very badly
How do we manage to narrow the gap between A good design vs bad implementation?
Thanks
Sundar
Burk Hufnagel wrote:
corey haines wrote:Hi!
I think a lot of that depends on the constraints and people's familiarity with TDD. Most people that I ran into came to a coderetreat with the expectation that it was "a chance to practice or learn TDD," so they at least tried. Personally I always emphasized that a coderetreat is a great time to try new things, since the goal isn't to finish the implementation, nor even to get anywhere at all. If a single test is written, but it is a great test, then that session should be considered successful.
-Corey
Thank you for the response. I was hoping to leverage your experience and get a feel for TDD adoption around the globe. Based on what I've seen in Atlanta, GA, USA, it seems that TDD still isn't common (less than 50% use it) and that many senior developers don't want to try it because... fill in the blank -- while younger developers at least seem open to the idea, give it a shot and mostly find it valuable.
Burk Hufnagel wrote:
Liutauras Vilda wrote:I guess quite usual answer is when current implementation no longer works with new requirements. So really there is no quality evolution with an existing functionality. Which is of course sad.
But if the code no longer meets the requirements that means the new version behaves differently than the original code, so the change doesn't qualify as a refactoring. Right?
Burk Hufnagel wrote:Corey,
I'm also wondering if you've noticed any correlation between the use of TDD and the quality of the code people produce, or whether they manage to get the game working at the end of the allotted time.
Thanks,
Burk
Burk Hufnagel wrote:Corey,
In the excerpt, there are several examples of test people write while working on getting their programs to work. Based on what you've seen, do most of the participants follow some form of TDD? Have you seen a difference between less experienced developers and more experienced developers regarding TDD usage?
Thanks,
Burk