It’s a late comment, a few weeks after you wrote the article.

I fully agree with the idea of better programmers vs. process.

One only need to look at the most awesome and hilarious contrast between Peter Norvig (strong programmer) and Ron Jeffries (strong process salesman) and their approaches to solving Sudoku.

Norvig’s code actually solves the problem. Jeffries’ code fulfills the need for process.

if your code have cascading effect problems, then you indeed are a bad developer.

I’m on the wrong side, that’s to say, I reckon that I write way to few tests; but that’s mostly because all the code is usually tested on spot: all the corner cases, race conditions, library access, everything that could fail for any reason is tested right there _in_ the code. And the code itself degrade gracefully

how many of those corporatish written TDD application fail with an exception if a configuration file is not properly installed, maybe because a written permission was not tested during installation and not checked within the code?

that is something that *proper* coding discipline doesn’t allow to happen.

there is no way a proper coded method would leave the application in an improper status. you’ll really need to learn to write stuff that works _or_ fail with a trace message and a proper notification. then you’ll have no cascading bugs and test will become so trivial that you can incorporate them in your code

Let’s say for a second you’re using “Developer Driven Design”, so you think about good code and then write it. Cool. And you’re on a team with crappy developers who think as hard as they can, but pump out completely crappy code. What now?

How is that any different than if I work with TDD, or any xDD for that matter, and end up on a team with a bunch of crappy developers who “use TDD” but have no idea how to do it properly or why they’re even doing it?

Either way we’re better off leaving that team and finding greener pastures.

As for the “plague”, who cares? Let them compete in open market. Their crappy work will lose them customers, and your quality work will earn you customers. They’re just driving business for you by showing customers what to avoid – buzzwords without clear understanding.

You’re right of course that there are people out there who do shitty work but who claim they’re embracing “best practices” to do it. But those people don’t get it. They’re appropriating a tool as a marketing term to sell services rather than really understanding the benefit of the technique and putting it to work. That’s not a failure of xDD, that’s just a shitty developer doing shitty work and saying what they need to say to make bank. Don’t confuse the two.

@nap I can only assume you haven’t been around the block, if having great developers is an obvious prerequisite to you. Consider yourself lucky, but there are plenty of mediocre shops churning out horrendous code using “best practices”.

The good programmer will likely find ways to make the program simple and the program will communicate it’s intent to some level.

The bad programmer will make a big mess no matter how much testing is done on the code. And the design and architecture will be difficult to improve.

Of course a good program with good tests is even better.

You might argue that bad code with tests can be refactored into good code using the tests as a safety net. In my experience that is rarely the case though as the bad programmer didn’t think through the interface of the classes he was building, so he ends up testing the ins and outs of the class instead of just the public interface leading to a situation, where you can’t refactor anything without rewriting a whole bunch of tests – and then the safety net is no longer a safety net.