Talking to developers in other communities, Java and Rails, they just laugh when I describe EF. “Standard road”…whose standard? Certainly not the rest of the developer world.

I think if anything, ALT.NET needs to open the .NET developers’ eyes that the developer world is much, much larger than the MS space.

If you really want to make a difference, start educating the community which you aren’t reaching on blogs, etc.. (Actually that’s probally 99% of the .NET developers). That will cause a chance in the market, which will cause MS to choose a different more better approach, the one advocated through ALT.NET instead of just making petitions and blogs about how great it is and what it should be…

I agree with most points in the petition, but I didn’t sign it.. Why? Because the v1 of the EF is great for the majority, but not for me (us). It’s not the wrong road, it’s a (very) standard road, which needs to be extended to fit more advanced needs when you want to use TDD, DDD etc..

Something which should be advocated by MS also and what they slowly are moving towards (MVC, StyleCop etc..).

Luckily the reaction of the petition is great and hopefully that opens an discussion, but stop whining how insulted you are… You are not alone on this planet and people have different views about it. Be constructive so that you later can tell all your grandchildren who start developing that you made the .NET world a better place!

Well said Scott.

Why are you a) posting as anonymous, and b) coming onto here almost personally insulting each developer who has raised there hand in concern to the EF?

I think its totally unacceptable trying to switch this around and blaming us, the concerned, for something that we are raising valid points for, and trying to provoke a “fight” – if you can call it that – on someones web blog?

Get a grip man, or at least come forward and reveal who your real self is.

David

Maintaining without proper test coverage is extremely risky and tends to encourage hero-coding and/or the Tower of Knowledge anti-pattern (where one person holds the key to most of the working knowledge of the system).

While you may find it ‘easy’, you may be actually harming your employer/customer because you haven’t left them plans for maintaining the software in your absence. Sure, you may have reams of documentation, but the only TRUE measure of maintainability are tests because they’re the only thing and that adequately identify when a new maintainer has made mistakes (mistakes that the customer may not be made aware of for many weeks or months).

RE: ‘other way around’: Interesting. I don’t know anyone of the big .NET Agile/TDD folks who doesn’t have at least 4-5 years doing things the old way (i.e. waterfall, big database schema with lotsa DBA’s, 1,000 sprocs, typed datasets, etc).

That’s great, I’m glad to hear that you’ve found a solution that you can deliver real success and you found the right combination of practices, tools, etc to drive it there. One thing we all should be asking ourselves is: Can I do it even better? Maybe you can, maybe you can’t. Anyhow, good job and thank you for sharing (that sounds sarcastic, but I really am sincere here).

I don’t necessarily object to designers and EF, etc as a whole. I realize that in several situations, they are appropriate or at least not evil.

The point here is: You’re aware of some of the concerns and you have made an INFORMED, CONSCIOUS decision to go that route. You are ENGAGED and ACTIVE in the community (judged by the fact that you read blogs and mailing lists and post to them).

I’m sorry, I don’t define this as ‘success’. Getting the app into production is 20% of the success, IMHO.

I don’t think I ever said getting the application into production made it a success, besides the only TRUE measure of success is how the customer perceives the application throughout its lifetime. Just because an application is testable doesn’t necessarily mean it solved the customers needs (which is the most important measure of success).

Code without tests is a ticking timebomb of cost waiting to be exploded upon unsuspecting business users/stakeholders who will get sucker punched by a huge price tag in 6 months when they request a change and the dev team tells them that the app has to be re-written

I think you are missing something here. I have worked with several applications without tests and they were easy to maintain and enhance. If the application is written correctly it shouldn’t need to be rewritten with or without test. Just because the application has tests doesn’t mean it is easy to maintain (although it does help).

The thing is, I’ve done software development the way that you/they’re talking about and I’ve done TDD/DDD. From what I can tell, they’ve only done it their way. They just don’t know and they’re speaking from ignorance which wouldn’t be so bad if they also weren’t so insulting and condescending when they did it.

Its funny you say this. I being an outsider in this discussion (who is using/learning TDD), I perceive it to be the other way around.