
Experts, True Believers and Test-Driven Development: how advice becomes a religion - itamarst
https://codewithoutrules.com/2016/12/15/experts-vs-zealots/
======
maxxxxx
You can replace TDD with object orientation, functional programming, scrum and
other buzzwords. I never understood why people try to make everything into a
rigid religion. Maybe it's a substitute for thinking for themselves?

~~~
senorjazz
Saw a perfect example of this on stackoverflow (or stackexchange I forget
which).

But someone posted some actual code, it had a switch statement, only 3 case
options, about 7 lines and if the switch didn't hit, throw exception after

"I would be careful with that switch, it looks like a code smell, this is how
I would do it: 2+ interfaces, 3+ classes, abstract this, factory that and over
100 lines of code.

I just refuse to believe a simple switch that everyone can understand in about
1 second is not the better solution to some complex code, even if it does use
a "pattern"

~~~
sanderjd
Without having seen this specific SO thread, I can easily imagine both 1.
agreeing that the 7-line switch-based code is the better solution to a little
SO-question-sized problem, and 2. finding that same solution with no
abstraction inflexible and "smelly" in a huge codebase very actively developed
by tons of people. Context matters, and knowing what the context is currently
and predicting what it will be in the future are some of the tough things
about programming.

~~~
BeetleB
This. If it's a small program with limited scope, switches are fine. If it's
part of a much larger program, there's a chance that switch will explode to
switching on the same thing all over the codebase.

However, I think GP's point is valid. If during a code review I have a switch
and it makes no sense to abstract it, I'd smack the reviewer on the head if
he/she wants me to "fix" it.

------
agentultra
> And if the director of a movie has asked you write some code to 3D render a
> "really awesome-looking explosion" you won't benefit much from unit tests
> either, unless you can write a unit test to determine awesomeness.

I was skeptical of this post to begin with but this line sums it up for me.
The author is railing against a perceived threat. Of course you can't unit
test _awesome_. That's ridiculous.

So what's the claim here?

I think more developers need to be introduced to the concept of the, "state of
the art," and be led to resources like SWEBOK[0]. It has a section on software
testing and it's good to know what the state of the art is across the
industry.

I don't have the link in my db, but I've come across studies that have shown
no significant difference in productivity when utilizing test-first vs. test-
after approaches to software development. That's the only real religious sell
I still hear these days and it has been rather well debunked at this point.
All that matters is that software is tested... how you approach it seems to
just be a matter personal preference.

[0]
[https://www.computer.org/web/swebok/v3](https://www.computer.org/web/swebok/v3)

~~~
heimidal
The question is, how do those studies measure productivity?

In my case, I've found I write more readable, easier to understand code when I
use tests to drive out my design. It may actually take more time to write the
code itself, but the product ends up better, imo.

(Granted, I think I take the approach this article advocates and only do so
when I can help inform the design.)

~~~
mcphage
> In my case, I've found I write more readable, easier to understand code when
> I use tests to drive out my design.

In my case, I've found the opposite—when I use tests to drive my design, I end
up with lots of tiny moving parts; each one individually is understandable,
but the design as a whole is not, and figuring out how to do anything
different is an exercise in frustration. I end up jumping between 2 or 3
files, trying to figure out where anything _happens_ , because it's all been
unit tested into perfect isolated pieces.

------
lgleason
It's like design patterns, scrum etc.. When the tool is used correctly it is
awesome. When it's mis-used it becomes a cargo cult style liability.

With TDD a large part of the religion thing comes from people like Uncle Bob.
It's not that his style is bad, but the biggest problem I've seen with his
style is when people who are already passionate with their craft and maybe
practicing TDD go crazy with his advice while missing the context of his
message.

That context is his focus towards systematically sloppy corporate shops that
have picked up really bad habits and won't touch the tool.....often the same
ones that still use a waterfall development process (now with a thin scrum
veneer). When you have these kinds of shops it is probably better to to a bit
to the other extreme first, and to then find a happy medium after you develop
better habits and understand the tool .

~~~
BeetleB
>With TDD a large part of the religion thing comes from people like Uncle Bob.
It's not that his style is bad, but the biggest problem I've seen with his
style is when people who are already passionate with their craft and maybe
practicing TDD go crazy with his advice while missing the context of his
message.

I honestly don't know what Bob should do. I know he occasionally says stuff
that gets people upset. However, the _majority_ of the stuff that is
attributed to him is just outright false. It doesn't matter how many times he
publicly corrects the record.

Uncle Bob does not believe in unit testing every function.

Uncle Bob does not believe in a 1:1 mapping of function with unit test (or
even close). Uncle Bob is fine if a unit test spans/covers multiple functions.

Uncle Bob is not against unit tests that touch the database or disk.

The list goes on and on.

I watched many of his Clean Coder videos, and was surprised to see how nuanced
he is. He does not speak in absolutes. His blog posts are much less polished,
and often get him into trouble. But even there I see a fair amount of nuance.

~~~
Silhouette
_He does not speak in absolutes._

Not as often as some of his critics might suggest, perhaps, but he really does
speak in absolutes at times and some of those absolutes really are as foolish
as his critics say.

He also frequently adopts a style that presents his personal opinions and
experiences as if they were more than that, despite a lack of other evidence
to support his positions or even the existence of other evidence that seems to
undermine those positions. While he may hide a small disclaimer somewhere,
many of his readers aren't going to see it, and I don't believe for a moment
that he isn't fully aware of that when he chooses to present his material as
he does.

------
Silhouette
Sadly, I don't think all of the black and white advocacy for certain ideas
that we see from some sources in our industry is because the experts don't
realise how expert they are. I think much of it is because it sells more books
and consulting gigs, and because being controversial helps to keep a high
profile.

------
juskrey
I'm 17 years into coding and have never even tried TDD - just because it
seemed horribly wrong.

~~~
marsrover
And this is the other end of the spectrum, which is equally as bad. Don't be
the guy who never tries new things.

~~~
Mikushi
Is it equally bad?

I didn't do TDD most of my career, product I delivered worked, where delivered
on time and reached the goals set out by the business. Why bother? Because
it's good practice? Hardly a valid argument in a business perspective.

~~~
zachrose
"Business perspective" can be like hill climbing: you evaluate a potential
direction based on whether it makes your situation more profitable or less
profitable, regardless of the peculiarities of your local landscape.

I think got into TDD for its aesthetic or philosophical appeal. The idea of
being able to make reliable software by first writing down what its supposed
to do just struck me a poetic and tractable. On the one hand, I spent a lot of
time and money going through a dip in productivity while learning all the
things to make testing work for me. On the other hand, I eventually emerged
from that dip with skills and a mentality that allow me to be productive and
relaxed in a way that I wouldn't have thought was possible.

------
deepaksurti
By pg in On Lisp: >> It’s a long-standing principle of programming style that
the functional elements of a program should not be too large. If some
component of a program grows beyond the stage where it’s readily
comprehensible, it becomes a mass of complexity which conceals errors as
easily as a big city conceals fugitives. Such software will be hard to read,
hard to test, and hard to debug. >>>

One of the problem is not treating tests also as a design problem as in what
to test and what the code for tests should be like? I never see the rule of
simplicity applied to the test code as well. Eventually it all becomes like a
big city that conceal fugitive bugs.

EDIT: to end the quotation from pg book.

~~~
kazinator
Fugitives can hide very well in the backcountry too.

And I'm not moving to a village. :)

------
dep_b
I see a lot of projects where everything is just a vast context based
decisions. If you factor out all of the things that are not related to
databases or handling user input there's very little left.

However I can imagine having that logic built up "abstractly" by imagining
user input and database output objects and fully tested is something that
would really help a project.

Having only 20% code coverage or less is nothing to be ashamed of as long as
that code is the code that matters and it's better, more abstract and more
readable because you started writing it TDD. Before things got ugly with user
input and database results.

------
huherto
> You need to take every piece of advice and figure out when and where it does
> not apply.

This. It is almost obvious. But you still see lots of cases where advice is
followed where it doesn't make sense.

A particular contrarian thing that I do in Java. When I need objects that are
pure Data Transfer Objects (DTOs) with no logic whatsoever inside I just
declare all members public and do not bother writing (or generating) getters
and setters. I know we were told NEVER to do this. But in this case there is
not attempt to encapsulate anything as there is nothing to encapsulate.

~~~
douche
Java really needs to get auto-properties added in someday...

------
Murk
It happens all the time. It happened with "design patterns". It happens with
frameworks, languages, and many other things. Human nature. It's quite hard to
argue with someone who cites an "expert", because you are a relative nobody.

Always think for yourself.

~~~
protonfish
But where does "thinking for yourself" become "reinventing the wheel"?

~~~
falcolas
It happens remarkably easily. But like every other mistake, this is one you
frequently have to make for yourself to understand why it's a mistake.

The trick is having enough introspective capability to identify when you have
made a mistake, and not fall back on dogma to say "I followed The Path, so it
_can 't_ be a mistake".

------
Spooky23
All methodology has the potential to become pseudo-religion.

The worst ones are the ones that infect every aspect of the business like
ITIL. The scope and complexity of the methodology is so broad, you need to
hire priests (ie. consultants) and build shrines (ServiceNow, Remedy, etc) to
the religion and you end up in a state where nobody in the business
understands WTF is going on.

That answers the question frequently asked here re: why horrific and
dysfunctional companies like IBM get a tight grip on companies.

~~~
lgleason
Six sigma is definitely that way, especially when you consider that, like AA,
it is a 12 step program. On a side note if you put the two lists next to each
other six sigma almost looks like a dispassionate generalized version of AA
...

------
curun1r
This is so not new, it has been covered in religions for thousands of years.
Buddhist teachings tell that there are three forms of understanding.

The first is devotional understanding. Martin Fowler is a wise and learned
programmer and says that TDD is the best way, so One believes that.

The second is intellectual understanding. TDD is good because it codifies the
programmer's intentions for what the code should do, makes refactoring easier,
prevents regressions and all the other logical reasons that TDD proponents
talk about.

The third kind, and the only one that's true understanding, is experiential
understanding. TDD is good because you've experienced development with and
without it and feel how different they are. Once you get to this point,
there's no dogma about writing tests first or anything of that nature. The
practice becomes natural and you're free to deviate when it feels wrong.

See also: Shu Ha Ri

~~~
itamarst
The interesting thing about this model is that it maps pretty directly to
current research on learning.

In this context, experiential understanding (when you're an expert) is the
point where you start suffering from Expert Blind Spot.

And there's a bunch of research that suggests the best teachers (by default)
are the people at middle point, intellectual understanding, precisely because
the understanding is less automatic and integrated.

The book "How Learning Works" (which I review at
[https://codewithoutrules.com/2016/03/19/how-learning-
works/](https://codewithoutrules.com/2016/03/19/how-learning-works/)) talks
about this at length.

~~~
wpietri
Interesting. For me, teaching when I'm an expert means I must begin another
path of learning. I'm at Ri in understanding the material, but at Shu at
understanding how novices see the material. But I could well believe people at
the middle point will always be better than me.

For those who want a good example, I strongly recommend Julia Evans, aka
@b04k:

[http://jvns.ca/](http://jvns.ca/)

She writes a lot of novice-focused material on technology. She does a much
better job at explaining things than I would. And she does it with an
excitement for the material that is infectious. Even for those who know the
technical details, I recommend following her; I always walk away saying, "Wow,
she's right! I had forgotten how cool that is!"

------
NikolaeVarius
Not specific to Code.

See Also

Health Advice Including but not limited to (Diets, GMO, Types of
Exersize/Timings)

People want something to latch onto and feel superior about.

~~~
enraged_camel
I think the difference with healthcare advice, at least with the examples you
gave, is that the effects are directly measurable.

If I am eating 2000 calories a day now, and start eating 2500 calories a day,
I can measure the impact of that change on my weight as well as my lifting
performance.

I really doubt the impact of TDD is directly measurable like this. I may be
wrong though.

~~~
BeetleB
>I think the difference with healthcare advice, at least with the examples you
gave, is that the effects are directly measurable.

Nope.

"Oh, you have this problem? You probably don't take enough Vitamin D!"

"Oh, you have this problem? It's probably due to lack of exercise."

"Oh, you have this problem? You're probably not drinking enough water."

------
williamstein
My experience: TDD is _awesome_ for writing certain types of code... and it's
terrible for writing other types of code. Simple as that. The same is true for
many programming languages: good for somethings and terrible for others.

~~~
pmarreck
What is it terrible for? I've encountered situations where someone believed it
was bad for something and were wrong. Such as user interface code. The
solution in that case for example is to make as much of the code testable as
possible leaving just a thin layer of untestable stuff (which can still be
tested via an integration test of some sort). This idea generally follows the
principles of
[http://alistair.cockburn.us/Hexagonal+architecture](http://alistair.cockburn.us/Hexagonal+architecture)
or "functional core, procedural IO". Gary Bernhardt expounds on this
brilliantly in his
[https://www.destroyallsoftware.com/talks/boundaries](https://www.destroyallsoftware.com/talks/boundaries)
talk, btw.

------
data_hope
Uh, I think every TDD "expert" makes it pretty clear, that there are cases
where tests-first might not be the best option.

------
clifanatic
I think a lot of this religious behavior stems from an underlying belief,
mostly by people who've never tried it themselves, that programming _must be_
easy and anything that makes it appear hard (and especially slow) means that
somebody is making a mistake somewhere. So they go looking for a silver
bullet, and the latest fad seems to fit the bill.

