[rapala]

How many of those side projects ended up being 6 million lines of code maintained over 5 years? Because those are the kind of code bases I have in mind when I'm weigthing the pros and cons of TDD or other testing practices.

When reading Uncle Bob and others I have always got the feeling that the "goal" of the practices described is to have systems that can be maintained and extended for years by different people and teams. It never crossed my mind that Uncle Bob would recommend TDD for that tic-tac-toe I wrote to learn Buzzscript.

[kstenerud]

How many side projects end up being 6 million lines of code?

How many projects at all end up that big?

How many of those end up falling under their own weight?

How many of those failures are attributable to lack of TDD?

How many of the succeeding ones succeeded on account of TDD? Or in spite of TDD?

All I've seen so far is anecdotal evidence, which is no evidence at all.

[andrewfromx]

it's like i'm an artist. You can't tell an artist how to paint. I'm going to paint my best work when I'm allowed to choose my own easel and pallette and brushes. Let me throw some green paint on the canvas and make the trees how I wanna make the trees. Programming is more art than science.

[cellularmitosis]

I feel like most artists produce inferior results when they are allowed to fully express themselves with infinite resources and no limitations.

When George Lucas was given unlimited time and money, he produced inferior films.

McCartney and Lennon's solo efforts don't stand up to their collaborative works.

Elvis eventually became fat, gaudy Elvis.

[mazerackham]

True, if you're working alone. But 5, 50, 500, 5000 artists trying to paint on the same canvas? Then the game is significantly changed.

[andrewfromx]

https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar i'll take a Bazaar of 5000 artists any day over a forced Cathedral.

[rapala]

Testing practices are orthogonal to the cathedral vs bazaar idea. Linux is a great example of this. Anyone can checkout the code and work on it, but upstreaming the changes requires coordination and approval with the community.

The lessons by Raymond are also given in the context of OSS. Unfortunately it would be extremely difficult to find a team of developers that are passionate about the kind of stuff that SAP is written to solve, for example.

The lessons of Robert Martin and others are about how to be a professional developer. When you are writing software for someone else to use and they pay you money to do it, it is your reaponsibility to think about quality, extensibility and maintainability. It is not your job to express your self.

My take is that the point of TDD being so rigid is that a professional should always follow best practices, not just when they feel like it or when it is easy or convenient to do so. But TDD is an ideal and sometimes, or maybe even most of the time, there are externalities that make you fall short of that ideal.

[andrewfromx]

really good point about SAP! It's soooooo boring. That's the million dollar question - how to u inprise passion in a team of programmers all working for cash and not passion? I'd argue forcing TDD on your most brilliant artists is not the way. Or telling them that they are not "professional" if they don't follow what you consider to be "best practices" is a bad idea. That spark of true passion is worth it's weight in gold. Your best shot is to make an env where those sparks CAN happen vs. extinguish each little spark before it can grow.