

DHH Keynote from Confreaks - johnjlocke
http://www.justin.tv/confreaks/b/522089408

======
pothibo
One thing I want to add about TDD that always made it impossible for me to
build is how pointless (to me) it is to do TDD in the functional/integration
areas.

I tweak shit loads of forms, but as soon as a form get a little bit complex,
it's impossible, for me, to apprehend the parameter's structure. Same goes
with views. Your first view implementation is likely to be very different than
the one you end up using.

TDD is built on the assumption that you know everything from the get go which
has __never __be the case for me.

I write tests when things are settle down and ready to go live as a mean for
me to say: "Ok, I think this is good enough, let's go live with this, but
beforehand, let's make sure it works as expected".

Then bugs appears, and I add tests to cover those cases so I don't introduce
regressions in the future.

~~~
Legion
TDD is a means to an end, not an end in itself. I think some TDDers lose sight
of that fact.

The end is well-tested code. Developers often lack the discipline to write
tests after writing what appears to be working code. The point of TDD is to
force that discipline by making it part of the process of writing the code in
the first place.

It's a good technique that many use to great effect, but it is just that, a
technique, not a goal in itself.

What matters is that, when you're checking in new code and pushing it
upstream, that code has tests along with it. Whether you wrote the tests right
before the check-in, or as part of a TDD cycle, is immaterial to everyone
else.

~~~
benjiweber
I would argue the "end" of TDD is working, well factored code. It's a
technique for continually getting rapid feedback on every code change that you
make, working in very small iterations.

The fact it results in a regression test suite is a happy side benefit (and
actually, some of the tests generated are inevitably short lived).

There are other benefits of working in this style. e.g You should nearly
always have code in a state that could be deployed to production; It gives a
rhythm for pair programming; It encourages a certain coding style.

------
stephenitis
I liked his rant on unit testing.

It's not about the # of test or the % coverage. It's the # of test required
for a degree of confidence needed to sleep and further develop.

------
pmh
DHH starts at ~11:30 mark.

------
amrit_b
Video doesn't work for me. Any other URL?

------
rartichoke
This is the best keynote he's ever given. It boils down to actually writing
code and forget memorizing patterns.

That can't be more true.

~~~
karmajunkie
_headdesk_

While we're at it, let's get down to just cooking and forget food science.
Never mind how a recipe should be adjusted at altitude. Or what to substitute
when the person eating your minimally viable meal has a food allergy to an
ingredient. Or what other things go well with your main entree. We're just
cooking up things we got out of a can, after all.

Don't learn any patterns. Except the ones DHH wants you to—those are ok. All
the rest of them just get in the way of writing software.

(readers may proceed to downvote now.)

~~~
rartichoke
He never said don't learn patterns. He said it's not worth spending all your
time trying to memorize them before you even write a line of code.

Memorizing about 20 patterns for 3 months before you really write any code is
way worse than just hacking together something and improving it because after
enough time you know what's wrong.

The "you just know" thing is really powerful. I'm not a professional artist
but I just know that if you had a yellow background and you drew something in
the foreground with the same yellow code it wouldn't work because you couldn't
see it.

When writing shitty code I just know it's bad because I find myself having to
copy/paste something 8 times or maybe it's close enough to a copy/paste that
it still feels wrong so then I fix it.

~~~
karmajunkie
I think that's good advice—great, even—for the person just learning to code.
Its terrible advice for someone who is or wants to be a professional in a
field in which continuous self-education is an imperative to stay employed.
Patterns provide both a vocabulary and a toolbox to go to when you're solving
a problem. If you don't learn the vocabulary and the tools that are available,
you _don 't_ recognize problems when they arise, or you only recognize them
because you're no longer able to constructively execute on new features.

To take your example, yellow-on-yellow isn't an aesthetic assessment, its a
functional one. You recognize that functional anti-pattern because you've
experienced, at some point in your life, what happens with a lack of contrast.
If you aren't colorblind, you probably don't (intuitively) recognize that red
on green is also a functional anti-pattern. When you extrapolate to the world
of software development, without having previously learned these patterns or
something resembling them, you don't recognize the antipatterns when they
occur.

I'm not saying "Don't write software until you know all the patterns, ever."
I'm saying that DHH has a traditional antipathy for any pattern he hasn't
deigned fit to include in Rails canon, and that when you're coding solutions
that need to scale in both performance and complexity, you probably don't want
to take advice from someone who thinks a formalization of the AR pattern is
the height of domain modeling.

~~~
rartichoke
A beginner with a passion and goal to improve will eventually become a
professional. You don't get to professional status by just research and
reading, you have to actually do things and figure out first hand what works
and what doesn't.

Then you eventually learn to see things on your own. I don't need to read a
popular programming pattern book to know how to structure my code. I know how
to structure it based on feedback of using it on a regular basis while having
a solid base of information to work off of.

If something feels off, I fix it where the solution is it no longer feels off.
Until it feels off I'll likely leave it as is because at this point I haven't
experienced the problem.

If something isn't a problem to me then it's not a problem. It's only a
problem when it causes me to react in a negative way or is causing the system
to react in a way that is bad.

I wouldn't recognize first hand that red on green is a problem for color blind
people because I'm not color blind. If this hypothetical app had to work for
color blind people then I would open a ticket and flag it as a feature request
and then get feedback from someone who is color blind.

That's a good example of it's not a problem until it's a problem.

You can still constantly learn and keep up with things while taking DHH's
advice btw. I have been coding and working with his mentality for quite some
time now despite working with rails for only a year.

~~~
karmajunkie
Yeah, look me up when you've been cleaning up Rails code from developers who
didn't bother to understand solid design principles for several years... that
whole "wait til its a problem" thing falls apart pretty quickly in non-trivial
domains.

~~~
rartichoke
You can't ignore things until it's a huge problem, that would be a mistake no
matter what.

Do you have a real code example from a non-trivial domain?

------
midas007
There's no audio until 11:15.

------
trebor
Subject of the talk?

~~~
steveklabnik
I am not at RailsConf and haven't watched the talk yet, but:

"In many ways, the prism of computer science is harmful for the development of
information systems" \-
[https://twitter.com/wycats/status/458616115451527168](https://twitter.com/wycats/status/458616115451527168)

"DHH is essentially talking about how getting overly concerned with testing
millions of isolated pieces is more trouble than it's worth." \-
[https://twitter.com/wycats/status/458620203711344640](https://twitter.com/wycats/status/458620203711344640)

"A good TLDR of this talk is that pseudo-CS exploits your desire for "science"
but does more harm than good." \-
[https://twitter.com/wycats/status/458622138099183616](https://twitter.com/wycats/status/458622138099183616)

EDIT: I'm most of the way through the talk now, I agree with wycats' summary.

~~~
stephenhuey
His finale after all that was clarity. He suggested it'd be better to aim for
being a software writer more than a software engineer, and to focus on writing
software well.

As others have pointed out, he did argue that unit testing is sometimes a
waste of energy when taking to the extreme. However, along with that he
pointed out that he believes system tests are in fact important, and his take
is that they're much more important than 100% code coverage in testing. Does
your whole system work?

