Introducing Developer Driven Development (DDD)

http://www.codeanthem.com/blog/2010/05/introducing-developer-driven-development-ddd/

by AmberShah • 16 years ago

24 21 16 years ago

gfodor• 16 years ago

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.

mahmud2• 16 years ago

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 :-|

j_baker2• 16 years ago

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).

jamesbritt4• 16 years ago

"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.

mistermann2• 16 years ago

"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.

ryanbigg• 16 years ago

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/

mistermann2• 16 years ago

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• 16 years ago

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• 16 years ago

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.

Qz2• 16 years ago

The interface is really the only thing that matters.

mahmud2• 16 years ago

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.

malkia• 16 years ago

Loved it :)

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

jamesbritt4• 16 years ago

True that, along with faith-based contrarianism.

Qz2• 16 years ago

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

camccann• 16 years ago

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.

jrockway• 16 years ago

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• 16 years ago

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

gruseom• 16 years ago

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.

jamesbritt4• 16 years ago

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.

Introducing Developer Driven Development (DDD)

Related Stories