I’m not taking on the Alt.NET world

I’m not taking on the Alt.NET world

I’m not taking on the Alt.NET world because I value their contribution. I’m not trying to start any battles or wars. At the same time, I think things need to be said about the attitudes and actions of that community to keep things in perspective and foster more effective dialog across the entire industry.

The synergy of the greater Alt.NET world has led to a maturity and cohesion in tools that is very impressive. And I continue to learn from that space as from an array of other spaces. I value that.

I think the relationships of individuals within the Alt.NET community are an amazing discordant symphony that is pushing ideas forward at an astounding pace. My occasional brief observation – most often occurring in hotel bars – are that ideas float and are shot down a dozen times slowly morphing through the head of another amazing individual. Eventually some of the ideas gain traction and someone writes some code or otherwise formalizes it. Formalization allows formalized criticism and therefore improvement. This is really cool. It does not, however, look like any fun, words like stupid and misguided and childish fly around at an amazing pace. The negativity and intensity that makes it just short of a rugby match without teams. But the output is amazing in quantity and quality of thought.

The movements that Alt.NET champion have helped shape our actions and conversation. I have the opportunity to interact with hundreds of programmers a year and I have a sense of what they are doing. Continuous integration is making real inroads into how groups work and formal “integration” phases built into schedules are becoming as rare as the Prebles’ Jumping Mouse.

But this, even along with the fact the surviving results work for the practitioners involved, does not survive the corollary logic that it is the best development strategy for all, or even most shops. Cohesion and maturity do not define the best approach for the vast numbers of programmers that make up this industry. That’s why the good thing is that Microsoft did not blindly follow the pattern that worked for the relatively small Alt.NET community when developing Entity Framework. Entity Framework is a far broader initiative and EF must work in scenarios where the other pieces of Alt.NET style development are not in place (BDD, behavior based objects, test first development, etc).

If the Alt.NET ideas are the whole answer, why isn’t everyone using that approach? If it’s because everyone hasn’t personally been indoctrinated by working for months on an Alt.NET project, as I understood Scott Bellware to be implying about me in a recent comment on my blog, then Entity Framework cannot succeed regardless of the perfection of the tool. If you have to go be personally instructed, you can no more be personally instructed in EF than in NHibernate.

Entity Framework should not block any technique, including agile, additional infrastructure, code generation, rules engines, workflow, SOA, dynamic user interfaces, as the top of my head list. But neither should it be built in the vision of one existing – and therefore outdated – approach to software development. The change in terminology from TDD to BDD illustrates how fast thinking within the Alt.NET community changes and Entity Framework cannot chase these changes must but blaze its own trail based on the best thinking in every community.

I am not defending EF v1. It has issues. That’s not the point. The point is that the Alt.NET community is not a group of priests or gurus* that understand what the rest of us poor peasants need. Not for EF, not for broader development. I don’t believe in buying what other people tell you, thus what I value is not the “market” with its top down stories – in this case not Microsoft’s strategy outright. I believe in the intelligence of an industry evolving together – strictly the evolution of memes where continuous integration wins and behavior driven objects haven’t. Bottom up intelligence. What works in the trenches of Cleveland or Huntsville or Cut ‘n Shoot or Miami or Fairbanks. That’s what I want Microsoft to prospect and drill for. That’s what I want the Entity Framework team to become impassioned about uncovering.

Finding bottom up intelligence is an interesting ballet because it requires leadership, test products and the ultimate programmer in the trench getting out an application. Alt.NET actually represents all three of those things, so as a self-reinforcing environment it is interesting and important. I think anyone not paying attention to the ideals espoused is missing an opportunity. But the techniques and tools coming out of Alt.NET must meet the much higher bar of relevancy to the broader programming industry and by in large they have not made that cut (and incidentally, neither have my quite different ideas).

The interesting question – for all the good ideas that the broad industry does not embrace – is why? That’s the question I wish we were discussing. But that conversation is nearly impossible to have if predicated on the assumption that one set of ideals (agile is the current fashion) is considered to have more value than others. Meaningful conversations can’t happen until the visible presence of the Alt.NET community appears much more willing to listen and much less intent on its own internal modus operandi of shooting down ideas simply to see what can survive the onslaught.

*The priest guru thing has not been stated, but I’ll be happy to stand up and help squash implications of superiority in any group or individual within this industry. From Alt.NET “We are a self-organizing, ad-hoc community of developers bound by a desire to improve ourselves, challenge assumptions, and help each other pursue excellence in the practice of software development.” But the most important word in this declaration is the first “a”. There are many, many, many programmers outside this community that share these espoused ideals and that are successful in pursuing other strategies to obtain the only real goal – saner, faster development of quality software to meet business needs.

Entity Framework Petition

I feel I need to respond to the “Vote of No Confidence” on the Entity Framework.

I have little interest in petitions. They are by nature backwards looking. To get a group of people to sign onto something they have to either understand it or be driven by the charisma of the leaders. In this case, I assume the first. The contents of the petition must be stable and old enough that everyone has worked out the details. That’s the case with all the technical petitions I can think of, although admittedly that’s just a handful like the VB6 petition.

When it comes to the appalling scenario where we have at least 14 major categories of data access strategies in use in new projects today, we need the Microsoft teams to look forward and be creative in combining the best set of techniques – NOT pick one of the existing strategies and latch on to it because it came from the group that yelled the loudest.

Entity approaches are good because they better separate the business and data sides of our middle tiers. But they are also inherently difficult and inaccessible to most programmers. Entity Framework’s goal must be to bridge this gap. That means being extremely creative in picking its battles to reach toward the real world developer – not copy a strategy that is available to that developer today and fails (the combination of NHibernate and other tools used in a specific style of development). The failure is not because NHibernate is an Open Source tool. It’s not because people don’t know about it. If it worked in the majority of shops it would burn through our industry like wildfire. Why don’t you use them? Because they do not fit your development environment! This is not an easy problem that someone’s solved and Microsoft is looking the other way. It’s an incredibly hard problem – how do I know? I’ve been working on occasionally novel solutions to the problems for 20 years.

Entity Framework has issues. This is not news. It’s not even news to the Entity Framework team.

- EF is not a failure because it doesn’t fit TDD development

- EF is not a failure because business logic goes into partial classes

- EF is not a failure because it treats data as an important part of biz objects

- EF is not a failure because it accepts that most people do data first development

- EF is not a failure because lazy loading is hard – lazy loading can destroy performance

- EF is not a failure because its design tools are 1.0 level

- EF is not a failure because it has a poor strategy for merging into source control

All of these are potentially issues, but it’s critical, essential, I cannot yell this loud enough – Entity Frameworks must not be designed for the group that is best organized and screams the loudest. This already happened once with the disastrous IPOCO attempt that helped no one and wasted a lot of manpower that could have improved mapping and provided better metadata.

But then I’m sort of caught in a corner, because an important point of the petition is correct. Be cautions with EF. Do not jump into Entity Framework because of Microsoft marketing. It’s a tough platform that will get a little easier when the current spasm of books comes out. The niche is pretty narrow and if you step off the boards, the quicksand can be pretty deep. Treat it like what it is – an amazingly large and complex project that is being released as a 1.0 product. It’s an infant. The metadata and mapping still stink. Look at it as Microsoft’s current future direction, but remember how many current future directions we’ve had over the last 15 years (around ten) and remain skeptical.

GenDotNet Tools (at CodePlex) Fail with AdventureWorksLT

AdventureWorksLT might look like a good database to get started with if you want to look at the GenDotNet tools (they are still in a very alpha state), but its not. The reason is the use of multi-part primary keys. I don’t know how much to support these in the tool, so for now they just aren’t supported.

The underlying question is whether your many-to-many tables should have their own primary key and use the parent primary keys as logical keys, or whether the parent primary keys should be combined into a multi-part primary key. Because my many-to-many tables often have, or evolve into having a payload, I use the first approach. The second becomes relatively complex at a number of points in the generation process.

If you feel multi-column primary keys are tremendously important or valuable, I’d love to know why.

For now, multi-column primary keys and tables without primary keys are simply not supported.

Object Browser

Yes, amazing as it sounds, I probably need to teach you how to use Object Browser.

I know, I know, you think you know. Open a project hit F2 or whatever key you have mapped and voila you see Object Browser.

Crippled.

To use Object Browser in a non-crippled state, you need to do some things that are, let’s pick a word, bizarre, surprising?

Open a new instance of Visual Studio 2008. Leave your old one open or close it, it doesn’t really matter. Open Object Browser in this empty instance of VS and you’ll find a combo box in the upper left. Drop it down and select “Edit Custom Component Set.” Browse to the location that where you’re building your startup project (It should contain the appropriate assemblies) and select all the assemblies for your project.

That’s right. Don’t open the solution in Visual Studio, but open an empty Visual Studio and select all the assemblies of your project into a custom component set.

Now, select a class that is interesting and you’ll notice not only a node for base types, but also one for derived types. It takes a minute to search a large solution, but you can see the basic relationships from within Object Browser.

Cool.

The empty Visual Studio was certainly not obvious to me, but thanks to Bill McCarthy and DJ Park for showing me the light.

Now, here’s your part. I have a Connect issue to fix this to work inside your solution that was closed. I’m not sure how loud to scream about this in VNext. Does it matter to you that this work inside your solution? How important relative to other features that have floated such as the Call Hierarchy?