EnC: Big Deal
I think it's semi-humorous to see serious posts all over the place about C# support for Edit and Continue being added to Visual Studio 2005. WFC?
To hear people wax dogmatic about it, it's either the antithesis of quality-focused TDD development and will lead to thousands of man-years of lost productivity... or, it's the most useful and productivity-augmenting developer enhancement ever brought to bear against the challenges of computer science.
If you tell me you can't live without EnC, please don't ever take a job developing aeronautical control software. If you tell me you will never ever use it, not even once when you mangle a char in a regex or make a limbic typo somewhere, then I probably think your either intellectually dishonest or, worse, pigheaded to the point of self-flagellation.
I don't see the two as inexorably linked, some would say they're orthogonal. If I still do TDD, and yet I use EnC to fix a typo and thereby still get to green, I'm not sure I just committed a crime against technology. I'm going to run my fixtures again right away anyway, I'm not sure why correcting an issue in advance of that is heresy.
Or maybe it is heresy actually, since it sure feels like there's something akin to religion involved.
The other position I've heard voiced is "I don't use the debugger, I do it all in my NUnit harnass of choice." Excellent for you. Personally, I do both. I step through my tests frequently if they're not behaving as possible. This may mean I'm not making small enough change increments--to you. To me, it's productive, and I still get what I principally want out of TDD: repeatably verifiable software that's written test backward and nearly self-documented by its tests. If I do 7 line test-code-test cycles, sue me if you think 4 is the magic number.
I like the way this works for me and I also like it when you do it the way that works best for you. It's like someone telling you they hate your keyboard mappings.
I agree that EnC not a good way to write software if it's your primary way of hammering your code into its requirements--that said, anyone who's doing that has so many other hurdles to clear, to me it's nearly a premature optimization to worry about EnC (bringing down global software quality).
The argument of fixed VS C# team cycles is valid, but I don't pretend that they would have used the EnC cycles productively. Sam Gentile claims refactorings were removed--I don't know enough about which refactorings were removed and how well they were going to be implemented, but between R# and R!, I'm pretty covered for refactoring.
You could claim that those aren't included in VS out of the box, they cost extra and therefore not everyone will embrace them and extend the art. Personally, I think people who understand refactoring and see the value in it are the same people willing to invest < US$100 in something that saves them extensive amounts of time and improves the quality of their code. So, I don't see a net loss (and no third-party was going to add EnC, so somehow I personally just got additonal functionality--excellent).
Net: who cares, it's just another feature. Use it a lot, use it a little, use it never. I personally don't care and just don't see what the big issue is. People are going to write good/bad code with/without this--very little changes. If anything, what I take away is that Microsoft listened to its users and tried to move closer to where they were being asked to go. They're a business, I'm guessing they had a pretty good internal read on the business case for the decision.