I could risk saying, that Entity Framework made what ALT.NET movement is today. It was strong voice of resistance against it, that gave the impulse to action for people that started evangelizing about alternative approaches, pointing out its flaws and suggesting corrective actions. I guess to some extent this strong voice has been heard at Microsoft, but due to various reasons, not many changes have been made for v1.0 release.
I’m not very surprised to see ADO .NET Entity Framework Vote of No Confidence. (Here you can see who signed it). Sure it’ won’t change anything instantly, but I think that the stronger the voice of people who care about these things, the more likely Microsoft will take them into account. The less products like Visual Studio Team System and Team Foundation Server, overloaded with wizards diagrams and ‘click me baby one more time’ windows.
Read it, and if you agree, sign.
Comments
I’ve got a feeling that even Microsoft is overwhelmed by all the new technologies/services that they have recently released.
From my own experience I can say that Entity Frameworks or OR/Ms are extremely useful as long as the usage and features are kept to minimum. You would find a pattern if you speak to anyone who developed some kind of entity framework before. They start with something very simple and then they end up with a fully blown OR/M that many developers would find it difficult to understand the whole features or still for many tasks they have to do it in conventional way.
I might blog about this more in details soon. I do hope Microsoft pulls out Linq to SQL soon, I found it so impractical in real life.
By the way I have moved back to the UK last week. I hope we can catch up soon.
I believe the vote of no confidence in the entity framework to be well founded. However, I am completely unable to make any sense of your statement regarding Team System. The source control, work item tracking and automated build components of Team Foundation Server are each useful on their own, quite powerful when used in combination, and completely devoid of “wizard diagrams”. I have not used all aspects of Team System’s functionality (never looked at the edition for architects, for example) so I am in no position to completely refute your claim but I have to ask: what functionality is overloaded with “wizards diagrams” and “click me baby one more time” windows?
@Paul
Sure, *the fact* that Team System has integrated bug tracker, source control and task assigning is good. What I don’t like about it, and I regard as manifestation of promoting bad practices is the *how*.
To do the simplest thing, like check in, I have to do several clicks, to open checkin window, select task i want to relate this check-in to, set its status, click to switch to policies window, do whatever I need to satisfy those, and finally click check-in. (I may have missed something, as I’m recalling this from the top of my head. My impression is, however that it’s flat too much clicking to do simple thing.
Also, my impression is, that in every corner there is a diagram or wizard lurking. Add a test – here’s a wizard. Test up team build – another wizard. And every window has lots of butons, tabs and combo-boxes that open yet another window with several new options to click through.
And don’t even get me started on the testing generation.
To sum it up: The idea might be good (as is the idea behind EF), but the realization – not so much. Instead of promoting good design, my impression is that Team System promotes lots of code generation, and mouse driven development. And that’s what I don’t like about it.
@Krysztof
There is nothing wrong with mouse driven development. As you know Smarties 2008 has few commands that with a couple of clicks it generates all the code you need.
What I’m personally aganist of is any tools that generates code that would force me to change the design or the pattern that I’m used to for the sake of saving time.
Once of the latest features that I added to Smartoes 2008 was the comparer type support for collection types which incidently can also be generated with a couple of clicks. I’m sure you are more than capable of writing a comparer type for a type but why do you want to do all by hand when you can do it with a couple of clicks?
I have spoken to few developers during Smarties 2008 development who admitted they found it difficult to give up the old habits but they eventually realised the potential a productivity tool such as Smarties 2008 can have. Normally this is realised when you need to do repetitive tasks on few classes.
One of the slogans that I use for Smarties 2008 is “Type less, think more”. Simple logic, when you have less to type you have more to think of your application’s architecture design.
Alan, think about the kind of code that Smarties generates and Team System generates. Smarties does not *drive* my development -it aids it. If a tool creates properties for my classes, or helps me implement an interface, i.e. – it creates code small portions of well-understood I would eventually write myself, I don’t regard that as a bad think, quite the contrary.
On the other hand, if a tool does things like Team System’s throws at me big blobs of generated code in partial classes, that I’m best not to touch, that influence my design, and promotes this as a good thing – it’s something I regard as steep road down to hell of unmaintainable software.
And history proved that Mouse driven development is a blind alley. Think XUML, MDA…
@Krysztof
With the team foundation source control, doing a checkin is a straightforward as clicking the checkin button. You have to do more clicks if more policies have been put in place but the default behaviour is to enforce nothing. Yes, if you want to reap the benefits of having integrated source control, work item tracking and automated builds then it pays to put certain policies in place because you can trace the path from your requirements to the code that implements them to the builds that deliver them.
In general there is very little code generation in team system. I think Team Edition for Testers features some for writing tests. But the way you make it sound is that team system is all about diagrams, wizards and code generation and this could not be further from the truth!
@Paul
Sure, Team System is still a Visual Studio, so you can ignore most of it’s stuff amd work with it just as if if was Pro edition. But who would spend so much money to do that, right?
As I stated in my earlier comment, I really like the fact that many features like bug tracker, or task management are integrated in the IDE. However I don’t like the way how this is done, and the amount of noise clickery you have to go through to achieve that.
Last week I was on a two day event (one day presentations, one day labs) on Team System, held by Microsoft. From what I’ve seen, most of the stuff that is specific to Team System, are endless chain of windows you have to click your way through to do simple things, lots of wizards, and diagrams. It also encourages bad practices, like generating useless tests from code to have meaningless 100% coverage, but it’s a topic on its own.
It has some great features, but my overall impression is very bad.
Perhaps the reason why our opinions are so divergent on this topic is that you’ve worked with the testing tools in team system while most of my efforts have been spent on source control, work item tracking and automated builds.
I’m not saying we should ignore most of it’s stuff. I’m saying that source control, work item tracking and automated builds ARE most of its stuff! Both organisations I’ve been with that have used TFS bought CAL’s and then stayed with Visual Studio professional edition, because you can leverage the majority of the functionality (i.e. all of the three areas I keep mentioning) without buying and installing any of the team editions or team suite!
I will happily stand by and watch someone take shots at the functionality provided by all the team editions because I am in no position to defend them. But I have seen first hand how much of a difference the CORE TFS functionality can make to an organisation. No need to write off the entire package just because the implementation of SOME of the features puts you off.
In any case, I know it was just an off-the-cuff remark so I apologize if it seems like I jumped down your throat. I find TFS a joy to use, but I am probably biased because I came to it from a “VSS + Excel + no automated builds” environment. :/
@Krysztof
Your point is well taken in regards to my earlier comment. I was glad to hear about the distinction you made in your reply.