The EC and Save Anywhere think sounds a bit like a strawman argument.

Sam hit the nail on the head - unit tests provide a better developer experience than edit and continue. It requires good unit tests written test-first that result in testable designs that defeat the design conditions that bring about the need for Edit and Continue. Without those qualities and without the developer knowledge, unit testing and Edit and Continue aren't likely to express the differentiable qualities that folks like Sam and other testability and design folks take for granted.

Software developers who know how to achieve testability are often more accomplished software designers than folks who rely on EC. They achieve productivity that far outstrips the kind of penny-ante, short-term productivity achieved through RAD and tooling like EC.

And indeed, everyone should construct code the way we do. If we’re talking about building applications and systems, there’s a lot more at stake than a gamer twiddling away his study time in the glow of Halo. The domestic industry is being left with very little wiggle room to continue to play at coding rather than to take it head-on with a professional verve that spawns intellectual curiosity, inquiry, study, and practice.

In some respects, I think the analogy between coding and gaming is more telling about the attitude toward coding that folks who use EC as a low-grade buttress against their lack of understanding of testability. It highlights the lack of visibility into the meaning of testability by lethargic programmers who have yet to muster the person integrity and professional ethic needed to penetrate deeper into understanding testability and its inherent design considerations and benefits through practices like TDD.

Once you speak from real, prolonged experience with test-driven design, you realize that you’ve moved to another completely different game, rather than just a level in the same game with bigger monsters.

TDD is good. Refactoring is good. Use them together and you get a look at a bigger slice of the agile picture – a picture which is astonishingly under-developed in the minds of folks who write software while tied to the traditional development practice anchor.

Agile approaches like TDD and refactoring aren’t about writing perfect code. Both of these approaches exists specifically to address often extremely less than perfect code. TDD and refactoring are about designs that allow for changeability. I’m personally not after perfect code; I’m after a methodology that allows me to make code better when a better solution is presented.

Through a conscientious practice of Agile approaches including TDD and refactoring, I rarely have to use the debugger – not because my code is perfect, because it certainly isn’t – but because there are alternatives to having to resort to the debugger which exist in a spectrum or color that the Mort species presently is either incapable of or unwilling to perceive.

The Agile movement didn’t just come up with a handful of useful tools like NUnit, NAnt, CruiseControl, etc, to revolutionize traditional software development. These tools were forged by the requirements and expectations of an emerging development methodology. Folks making use of refactoring tools in Visual Studio without knowing about the greater context within which they are used are simply engaging in an impoverished approach to development in comparison to the power that those tools bring to bear in the context of the development environments that shaped them.

There’s a lot more to refactoring than refactoring tools, there’s more to TDD than NUnit, but you can’t see any of it until you go looking. If you think the a-ha moment going from VB 6 to VB .NET was big, wait till you get feel the magnitude of the Agile a-ha moment. Moving into a deep understanding of TDD is an order of magnitude bigger zen smack than the switch from a procedural to an OO world. It’s much more on the order of moving from a flat earth to a round world.

There quite a number of deeply-ingrained superstitions that Mort has to let go of before something like TDD will begin to make sense, and until that time, Mort is confined to the limited capacity for software development thinking that hasn’t evolved significantly since VB 6. And frankly, I have yet to see anyone really get TDD who didn’t put in the effort to really try it first.

Indeed this is definitely more vinegar than honey, but recipes for change in paradigm shift aren’t always formulated with candy-coated gumdrops in mind.

I maintain that a prolonged exposure to TDD practice will totally change your perception of software development and will re-wire your mind toward a higher magnitude of expectation for productivity and quality that go far beyond the middling gains brought by a development style that requires Edit Continue. But first you have to be willing to open your mind to the possibilities that the world may indeed not be a flat disk held on the backs of giant elephants floating in a cosmic sea on the back of a giant tortoise.

Scott,

And the last time I read up on "Agile Programming" it was called "Extreme Programming" ;)

Well no, Agile is an umbrella for all of the contemporary, test-centric methodologies like XP. XP is an Agile method, just like MSF is a waterfall method, but there's no formal methodology called "Waterfall".

Back to the point of EC, I still think it's useful and shouldn't be removed because there are some things that TDD can't really test for.

Can you provide an example that can't be resolved by refactoring the design to make it testable using Inversion of Control and Dependency Injection?

Or it seems to me that you'd go nuts writing unit tests to ensure that all of your spelling and grammar is correct.

Spelling and grammar for what?

Most of my issues with TDD come about when I try to apply it to legacy code and web applications (worst of all legacy web applications).

Indeed. TDD is a design methodology. If the code hasn't been brought into existence by the design pressures inherent in TDD, it's likely not going to have a whole heck of a lot of testability.

However, there are solid techniques for making legacy code testable. See: http://www.amazon.com/gp/product/0131177052/002-1083542-4004061?v=glancen=283155

How about an experiment? You can come work on my team for two weeks and if you still don't see that TDD is much more than you thought it was, then we won't charge you for the two weeks of training and coaching ;) (-- yes, it's a joke!)

Steve,

I agree the EC is a useful tool for folks building prototypes who may not have TDD skills, but I build prototypes without EC. I have yet to find a single justification for EC that design-for-testability and TDD hasn't simply made irrelevant.

I build the same kind of apps that most EC users build. The need for TDD isn't driven by the kind of application under construction.

It's not that TDD is a replacement for EC, it's that TDD changes the fundamental aspects of design so that EC isn't needed. And the result is software that is clean and grokable and much more of a pleasure and much less painful to build on and maintain.

The productivity comes from software designs that result from TDD practice that do not bring the obstructions to progress that are inherent in the opaque software that results from traditional practices.

The entire reason and justification for things like EC is wrapped up in a need to surmount obstacles that are themselves inherent in traditional design and implementation approaches.

It might sound crazy to hear a group of developers suggest that in TDD we've found a new route to productivity and that it's a greater store of productivity than we've ever found before, but that is precisely what what Agilists and TDD'ers are saying.

There's no shortage of TDD practitioners to sing the praises of TDD, what's required now are ears that haven't been desensitized by the numbing drone of traditional development.

The need for EC is a symptom of certain styles of software design that have become prevalent during an age when Microsoft opened the flood gates to a segment of developers who were need during a coder staffing crisis during the boom years.

EC is like putting a Band Aid on a shut gun wound. The real problem is the designs that necessitate EC. Even worse are the people who negligently continue to insist on these designs and who are too lethargic to learn a few new tricks.

The greatest shame rests with Microsoft for encouraging Mort to continue to engage in negligent software practices, but there's little hope that Microsoft will take a responsible stance and desist from its own negligence since the resulting deflation in productivity causes a percieved need for throngs of Mort programmers who in turn drive millions of dollars in revenue for expensive Microsoft developement tools.

Scott,

See, I "get" where TDD is useful for biz objects, transactions, and other objects which encapsulate application logic. But I don't get TDD for UI development. Which is where 90% of my pain during development is. 90% of my code is plumbing/data pump code. Put data in/get data out and display it. And that's the easiest, and most tedious code, to have to write. But the remaining 10% is where most of my errors occur.

Have you practiced the Model-View-Controller pattern for UI code testability? It's an Inversion of Control pattern for UI that is used to get all the testable code out of the opaque testing containers that Microsoft's tools create and reshape them into testable patterns.

There's usually some percentage of UI code that is better tested with human eyes and hands. The goal is to reduce that percentage to as low a number as possible and to automate the rest of the test using tools like NUnit. If you've got some high-end tool to automate some part of the remaining code, then you could drive toward an even smaller percentage of human-tested code. However, a significant number of UI test tools are more trouble than they're worth.

How do I "test" that an event fired correctly?

Are you asking how to test the wire-up between an event and a handler, if the handler did the right thing, or if the event was actually raised by some UI interaction.?

Correction:

Meant to say Model-View-Presenter... Freudian slip.

sigh

John,

I spent some time with a Mort who thought if he could only teach me how to use EC that I would see the light. He taught, I learned, it was just debugging in live mode on code that wouldn't need to be debugged through layers of opacity if the layering wasn't built to be opaque.

EC is a trouble-shooting crutch for folks who have simply copped out on learning about software layer opacity, IoC, and DI.

It's never been a matter of knowing how to use a tool like EC, but how to use a tool effectively under the guise of an effective methodology. It's the methodology that precipitates the EC tool that I take issue with. The tool itself is largely benign, except that it perpetuates lack-luster and less effective practices relative to TDD.

To wit, I don't think we're hurting Agile's adoption among Morts. I have yet to meet a Mort who was interested in Agile. I don't really think it's much of a target audience for Agile.

I'm with Jack Greenfield on the notion that a small percentage of Microsoft developers are likely to ever be able to adopt Agile. But I would posit that if the non-Mort developers adopt Agile, that we'll likely need a lot fewer Morts.

I look forward to your writings on TDD for Mort.

Well John, my contention is that once a Mort becomes a TDD'er, he is no longer interested in being a Mort - he has largely moved on from Mort practices. Mort practices and Agile practices are largely relative opposites.

I've introduced quite a few Morts to TDD through the workshops I've been doing in the US and Canada in conjunction with .NET user groups, as well as through consulting gigs. I've never been able to get a Mort to adopt TDD and still remain a Mort. By the time a Mort becomes interested in practicing TDD, he is already on the way out of Mort territory. So I guess it's more appropriate to say that I've tried to encourage recovering Morts through the transition, and I've helped turn on the TDD lights for a few open-minded folks who hadn't yet considered the possibility of a non-flat Earth.

The times where I have been asked to teach non-receptive, die-hard Morts to do TDD, the practices and disciplines often slid down Mort's back like water off a duck - TDD often doesn't stick to a die-hard Mort. Sometimes the material opens Mort's eyes to another dimension of software development, but those aren't the majority of situations. In these cases, the best I can hope for is to introduce them to mere automated testing, and usually not even the mere test-first practices stick - practices which would ultimately clear the path to understanding testability.

Many Morts don't often naturally think about *testability*. Many Morts are only now thinking about *testing*, but only because Microsoft is telling them to do because of VSTS' arrival on the scene. Testing and testability aren't necessarily the same dimension of concern. Not recognizing this is often the cause of new developer testing effort failures. Once a Mort adds testability concerns to developer testing concerns, I would venture that they have started down the path to Mort recovery.

In my experience, the die-hard Mort is a Mort because continuous study and practice aren't a part of his work method. Die-hard Morts typically learn the latest way to create opacity through Visual Studio designers, and that's where it ends. Mort is often a Visual Studio user, period. And that alone doesn't make for a good developer much in the way that owning a license for Microsoft Word doesn't make someone a good writer.

I'm not worried about offending Morts with recriminations about their low-sustainability practices - especially when they hold tight to these practices out of fear or lethargy because those are recriminable qualities for a software developer, and low-sustainability is a recriminable quality for software. When Mort finally learns that testability offers much greater sustainability over Visual Studio’s RAD tooling, then Mort will be a thing of the past.

Oh, and John... "Mort" *is* a generalization. So I don;t feel that it's inappropriate to speak generally about the persona.

Leon,

if the language features you choose to include will widen the base of users, then it will ultimately be a good thing.

Good for who? Does a larger user base always equate to a good thing? Is there a tipping point at which a larger user base becomes a hindrance?

Mark,

"I don't know why that test is failing...Silly me, my index is off by one!", edit, continue, test passes, get on with life.

That's not really an accurate depiction of typical TDD.

TDD practices often result in designs that are more reusable and thus classes that are reused more frequently. Making a change to code therefore could cause cascading defects.

The thinking is more often, "I KNOW why that test is failing...Silly me, my index is off by one. I'm going to fix that and run the unit test suite because I can't completely guarantee that the change to a reusable class won't cause failures elsewhere in the code."

Even if a change is done in Edit Continue, the unit test suite will need to be executed after the change is done. It's more likely that a test will fail, the problem localized, fixed, and then the suite executed. Most often this happens without necessitating time in the debugger. Since testability is a design concern, code is designed naturally by the shaping forces of test-first programming such that problems can be localized outside of the debugger.

Further, Edit Continue could leave the code in an invalid state along code paths that I have yet to traverse in the debugger after making a change with Edit Continue - especially for code paths that are re-entrant into the code changed in Edit Continue. This could lead to false positives or false negatives during the test execution, which is something that is pretty strictly eschewed in TDD. In fact calibrating out false positives and false negatives is what the Red and Green phases are all about in TDD's Red-Green-Refactor process.

TDD in general is more often a design practice than a quality assurance practice aimed at finding bugs. But unit tests are certainly good at doing that to.

If I find myself in the debugger in the course of a test execution, I'm usually not deep in the call stack because TDD produces code with shallow stacks and low opacity. Upon localizing a problem in the debugger I would be more apt to stop the execution of the test, make the fix, and then verify that the fix didn't cause un-localized failures.

If I had code that had to be tested into deep call stacks, with branching, and with opacity, I might consider the utility of Edit Continue, but that's not the kind of code that TDD typically produces.

Yes, a large user base is always good. More eyes reading and fingers typing means more code samples exist and more knowledge is shared.

A large user base is good. But is there a point at which a user base is too large? Can and should a user base grow infinitely? If so, would we expect negative repercussions?

A good debugger is, however, CLEARLY a core feature of any competent IDE. So in that sense, I think EC got the right priority

When I look at a debugger, I see a non-repeatable, visual assert. I very rarely need an assert that is non-repeatable. I agree that an IDE needs a debugger, but it's not as productive of an implementation verification tool, and too often it's used for that purpose.

removing features to force the "right" behavior is *never* the correct choice. You can do all the TDD you want with EC; you're not inhibited in any way.

My contention is that EC is extremely rarely necessary in TDD. The point isn't to introduce a motion that EC should be retired, but that the practices that precipitate EC are becoming rather dated in the face of emerging evolutionary software design disciplines.