

Introducing Developer Driven Development (DDD) - AmberShah
http://www.codeanthem.com/blog/2010/05/introducing-developer-driven-development-ddd/

======
jrockway
I have to agree with this.

The reality is that testing everything before you even write it locks you in,
emotionally, to a certain design. ("If I clean up this module, the bar goes
red! Ahh, fuck it!")

You end up writing the code to _make your tests pass_ , not the code to _solve
your problem_ in the best way. Without any iteration during the design phase,
you're not going to get the right design. At that point, you don't care if you
get the right answer, you care that you have the framework for getting the
right answer. Once you like the design, then you can worry about making sure
it works (sure, use TDD for that).

Now, the reality is, people that are forced to use TDD weren't going to come
up with a good design anyway, so at least they have some idea that their code
works and can change it would losing too much sleep. Fine. But when you aim
for 75%, you get 75%. I like to set my sights higher.

(I use TDD approximately never, and I have hundreds of thousands of lines of
code in production that never give me a headache. They are tested, but they
were _designed_ first, not tested first.)

~~~
wlievens
So would "design -> test -> implement" work for you?

------
j_baker
Do we really need to have another debate around development methodologies? I
mean... it's getting to the point where I'd rather write COBOL to access SOAP
webservices using DOS on a 386 than read another article talking about how
smart people don't need methodologies ( _especially_ if TDD is mentioned).

~~~
jamesbritt
"Do we really need to have another debate around development methodologies?"

Well, it's not really much of a debate when one side is bluntly asserting, for
example:

    
    
        Good programmers will write good code regardless of
        whether or not they use TDD or not.  
    
    

... without a shred of non-anecdotal evidence, or tossing up strawmen to be
knocked down. Like this one:

    
    
        It becomes ridiculous when people start to think that
        this tool that may be useful to some is going to save 
        us all from bad code and crappy software.

~~~
mistermann
"without a shred of non-anecdotal evidence,"

Did you know, _working_ software has existed for 30++ years, performing its
job day after day, before TDD was conceived and marketed to the world?

People might take TDD advocates a bit more seriously if they dropped this
assertion that if you aren't using TDD, or even worse, if you're not even
writing tests for your code, you are doomed!

I've been writing code for well over 15 years without TDD, and I've never had
a major problem with bugs or refactoring, because I think when I'm working,
and anticipate future problems. Yet I have seen many young people come along
with many different silver bullets to solve all out problems, and I've had to
clean things up after they were done.

This is not to say TDD is bad, and especially not to say testing is bad, I'm
just saying, it is definitely not a panacea, and often not even necessary.

~~~
j_baker
Did you realize that people wrote working software for 10 years without high-
level languages? Or that people wrote working software for 20-30 years without
the web? How many working programs have been written without garbage
collection?

Approaches to programming improve over time. Yeah, people got by without TDD
for 30+ years, but I'd much rather be a programmer today than 30+ years ago.

------
gfodor
To me, TDD (when I use it, more and more rarely) is less about making up for
coding prowess and more about removing fear and frustration.

~~~
mahmud
As someone who has written no more than 3 unit tests his entire professional
life, I can tell you untested code is fraught with fear.

For things that really matter, authentication, payment processing and service
orchestration, I have resorted to ad-hoc specification; I cheesy pseudo-
algebra based on axiomatic semantics, guards and boatloads of die() type
assertions :-|

------
ryanbigg
This makes me incredibly sad.

Once upon a time I wrote a story about a person who didn't use TDD and how he
suffered: <http://ryanbigg.com/2010/02/congratulations/>

~~~
mistermann
It's a great story, but the advocacy of TDD was lost on me.

As a person that is genuinely interested in why TDD is so important but
doesn't understand the importance or practice it, could you point me to an
article that explains it?

I'm a developer who really doesn't have serious problems with bugs. Maybe I
write my code a bit slower as I am always thinking about edge cases as I go,
but everyone keeps telling me I have to write all these tests, but for what?

Is it mostly for the following developers? I suppose that makes sense. But
then, I've inherited projects where I had to throw 50% of the code away, and
all of the tests, because it was hotshot young developers who were hip to all
the new things, but couldn't code their way out of a paper bag.

I see you point, but I think some sort of a reasonable balance has to be
reached here.

~~~
thorax
Well, it has a lot of uses.

For developers that are new to a largish code base, it can help them ensure
they don't break important subsets (as would any good unit testing strategy).
But also it proves to be quite handy when you have a really complex system
that grows over time. When you go to refactor it to keep it evolving and
working, the tests throughout (while costly to maintain) give you more
reassurance that you didn't wreck the world.

TDD adds costs but reassurance that you don't break major things during a
refactor. It can get a bit cumbersome at times, but it's hard for me to avoid
seeing the value for long-lived code (i.e. non-prototypes) and/or shared code.

It's not for everyone or everything, but I think it's pretty reactionary for
anyone to say it's not a useful process to have in your toolbox.

For example, I recommend TDD for cases where you're making a public API to
unknown people. It's much more likely you'll break some unknown importance
nuance in a refactor unless you have a good number of comprehensive unit
tests. If you can generate those in some other fashion, awesome-- but TDD puts
you ahead of the game there.

For me, I also don't have the best long-term memory on details given how many
vastly different projects/technologies I work on, so TDD is basically encoding
that memory for me so I don't make multi-tasking mistakes for problems I've
already solved a month or few weeks ago and helps pass on that memory to
people who inherit that code later. I'm an aggressive commenter for that
reason, too, but nothing helps you keep cross-component issues solid than unit
tests designed to be the canary in the coal mine when you break something in a
refactor.

------
tbrownaw
I tend to like Front Ahead Design myself -- build the interface first and make
sure that's acceptable (which may require faking some parts of the backend),
then just fill in back end logic until it actually works.

~~~
Qz
The interface is really the only thing that matters.

~~~
mahmud
A badly designed front-end can negatively affect your backend code. For
example, a radio button can lead to cleaner code, only one callback for the
whole option-set and one dispatch per each option. However, changing the radio
to a checkbox will lead to some woolly code.

Similarly, the introduction of an _accurate_ progress-bar might require the
introduction of threads to the backend, or force you to update a global
variable, or even rewrite it as an stream-based algorithm.

For CLI applications, independent utilities (a la git) might lead to cleaner
code, but sometimes you want to pass more state between phases, and having a
per-application _shell_ , a la OpenSSL might be better since you can then
implement variables and pass intermediate representations in memory, instead
of disk files and sockets.

------
gruseom
_The obvious (and correct) solution to this problem is to only use bright,
thoughtful programmers. Instead, the software community reacted by putting in
place safeguards and frameworks and processes._

This misses the point. The fundamental fact of the software industry is that
the demand for software exceeds the supply of good programmers by about an
order of magnitude. Many of the irrational properties of the industry can be
deduced from that.

~~~
jamesbritt
It also ignores the fact that without safeguards in place, good programmers
have to be good _every_ day, all the time.

You can't have an off day; there's no net to catch you.

------
camccann
Hmm. A solid idea, but it's important to contrast it with a less desirable,
but superficially similar methodology, namely "Development Driven
Development":

1\. First, develop some code

2\. Think about whether it solved the problem

3\. If not, repeat until it does

...which I fear is a rather more common variant.

------
malkia
Loved it :)

Lately I've seen lots of FBP - Faith Based Programming.

~~~
jamesbritt
True that, along with faith-based contrarianism.

------
Qz
Sounds a lot like the gnome underpants plan in a loop (obviously).

