What if we could put in the same place Kent Beck, Martin Fowler and a provocateur interviewing them both?
What if we wanted to analyze TDD?
Is TDD the Holy Grail? Should we use it everywhere?
Is there such a thing as too much TDD?
Lot’s of interesting questions answered by the creator of TDD ( Kent Beck ) and by one of the most renowned architects of IT ( Martin Fowler ) giving their opinions over TDD, where it is at, the learning curve, the different benefits for the different people and much more!
Just make sure you see it until the end. Most of the big insights are in the last episode (finishes and concludes the series).
Good point, I should make the title more clear so newcomers know that TDD is not driven by terror (although with any bad enough manager that is still very possible) but by tests !
Each of us needs to assess how best to spend our time in order to maximize our results,
both in quantity and quality. If people think that spending fifty percent of their time writing
tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend
that time thinking about my problem. I’m certain that, for me, this produces better solutions,
with fewer defects, than any other use of my time. A bad design with a complete test suite
is still a bad design.
Instead of spending time teaching people TDD, we should instead be spending time teaching
them more about design and especially more about refactoring, because that is the important
core skill. The ability to write and refactor code to a state with low coupling, well-separated
concerns, and great names will be applicable in all the codebases that we work in.
Every software methodology exists to deal with some risk. If TDD doesn’t address the risk you face in your project then you are just wasting time.
If anything the people who should be engaged in TDD are business and product owners. It is a clean, relatively simply means of getting them to clarify what they mean and to hash out the requirements (especially conflicting requirements).
To make it clear, TDD is not dead and is helpful and useful in many situations. However, we as Developers must be able to know when to use the tools we are given.
This talk focuses mainly on the consequences of over using it, which I think is helpful for every body, but I overall agree with your statement .
Your assessment also falls in line with “The best test suites are a mixed bag of tests ( unit, integration, property based, etc )” which I think is also valuable.
That link was provided already more than a year ago (with discussion): Do we need agile software development?
Uncle Bob links you can find in abundance on this forum, just search for his name. For a remarkable “confession” for example see BDD / TDD criticized
While I am an advocate of TDD, it can certainly be a distraction when mandated by management rules. I once worked for a large corporation that demanded 85% coverage by edict. This was for java code. Due to the verbose nature of java code, creating all the trivial accessors and mutators consumed time that could be invested in better pursuits. They also demanded that complexity level never exceed 7. In java many switch statements contained complexities much greater than this 7.
Legacy java code containing error messages, for example,
had a +1 complexity for each switch. Yes, this could be coded with newer with newer construct that did not increase the complexity, but this consumes effort.
I was in some review of this with developers almost in tears from having spent so much time to read the acceptance levels.
As a result, many developers felt considerable anger toward TDD, clean code, sprints, and agile in general. I can’t blame them. Management directive can’t cure social problems when management remains so inflexible. Many developers have left in disgust - including me.
Code suites with high coverage are awesome. Code suites with low complexity are even awesomer. Projects that have both? Would look like a dream land to me. However, your story does reflect the fact that Management was not familiar with Goodhart’s law:
“When a measure becomes a target, it ceases to be a good measure.”
This law states that when a metric becomes mandatory, it loses its value - mainly because people will focus only in the metric changing the workflow and code to achieve it, irrespective of the added cost the metric brings and at the cost of anything.
I do think TDD is good. I do think testing is great. I do think that low complexity saves lives and I do encourage ( and even teach ) my team all of the above.
But that’s the thing. I want a team. Not a set of mindless replicating drones. I want them to think for themselves and to consider the costs. Yes, all the above rules are awesome for the type of work we do 90% of the time. But there is also that other 10%.
I think these podcasts highlight the missing 10%. For me, these podcasts are about critical thinking more than anything else.
You should not enter the TDD for everything bandwagon. You should also not enter the TDD is horrible bandwagon. Bandwagons are bad.
A prime aspect of this management style I ommitted was,
“If it can’t be measured, it doesn’t exist.” Lower level managers
were compensated by how they could deliver on “metrics.”
While I am a developer, I developed an presented a course
in Clean Code techniques - primarily in C++ and Java and,
to a lesser degree, Python.
My courses were banned since I could offer no metrics.
Developers could not refactor if their code met complexity
and coverage levels. Developers were tracked on the amount
of code contributed to repositories (yes!).
Due to the line counting metric, maintenance dev suffered
greatly and some left the company. Fixing a bug in code
could consume 1-3 days to find and fix the bug while only
a handful of lines need changing.
As a result, some dev unrolled loops when they could
to bump up line counts delivered.
Tests were written to meet code coverage and not because
they really tested the code. (This would be a great topic for
a blog!)
While this company still exists, the churn has replaced
almost everyone in the area I was in.
I still use TDD in normal development and think of TDD as an
automatic debugger. TDD is my insurance policy when in
development and maintenance. TDD is more valuable than
the docs as TDD is live and the docs get disconnected from
the actual code.
Sorry couldn’t stop myself.
