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.

12 thoughts on “I’m not taking on the Alt.NET world”

  1. Thank you Kathleen

    There is a thin line between being passionate and being dogmatic. It would seem that those who are dogmatic have a tight grip on ideologies and a ready to rant about something they don’t like, agree with, or just doesn’t conform to their black & white thinking.

    oops…did i rant…sorry.

  2. “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).”

    I think that a distinction needs to be drawn between “following blindly” and learning lessons of the countless thousands who have already been down the road.

    OR mapping is far from a new concept and as it is currently implemented by the EF is actually categorized rather succinctly as being an anti-pattern (anemic domain model, a domain model lacking behavior). They have posted some stories of working around this but the stories are still extremely immature mainly due to their lack of persistence ignorance …

    Overall I think you hit the nail on the head though they should not *keep* certain methodologies from working which as of now they are. The terrifying thing is that the situations they keep from working are not the “best practices from the alt.net crowd” but the best practices from the community as a whole (Java, SmallTalk, etc) that have been brought up through years of pain…

    I do however believe that the EF team is trying to realize the benefits that others have learned over time and will do so in future versions … I see the outreach of the team to an advisory board and to members of the various communities as an extremely positive path towards developing a quality system.



  3. There’s plenty of people listening on Alt.Net. Just post your topic and discuss. Who are these people on Alt.NET that “aren’t listening?”

  4. Stefan,

    Yes, absolutely. Members of the broader movement behind Alt.NET are at the table (including Martin Fowler as I understand), and belong at the table. And people in the Alt.NET community should continue to ask for what they need – even shout for what they need. The next EF should have many things including POCO. They should just not be the only voices nor the sole direction of EF*.

    I tried to make a reasonable interpretation of Tim’s post and didn’t have much luck. I would find it as least as appalling as you do if they were not members of the team that understood lazy loading. They did things in EF and said things to me in the past that gave every indication that they did understand lazy loading, particularly its expense and the danger of doing it blindly without options (Danny Simmons and Sanjay at least, DevConnections April 2008). So, I’ve no idea what Tim is trying to say. I don’t have a problem discussing lazy loading in the context of explicit lazy loading. I think they used that term but it was in contrast to true lazy loading, as I recall a passing conversation. I also understand Martin’s concern over terminology. I don’t care what they call it, but I need the capacity to control loading if I’m ever going to use EF (FWIW, EF is a minor player in my world as it just doesn’t fit my scenarios at present).


    *This is slightly disingenuous as there is a post I am holding until this current conversation dies down that leaves open that possibility, but the context of that claim is quite different from and not relevant to this conversation.

  5. Greg,

    I threw away my first two responses. Learning from the past is a delicate dance. I am going to resist the temptation to answer this with my own alternate view, also based on experience. I do not wish to derail the conversation into one about competing approaches to common problems. The conversation I wish to have this week is about how we have dialog to contribute to the evolution of the shared space. I believe the petition was an anti-pattern to effective dialog. And when the further conversations reflect a notion of superiority it further derails cooperation.

    EF should support persistence ignorance and POCO in the next release. We agree. I think the team has said they agree to.

    EF today has issues in many scenarios. It deserves thoughtful caution, and guidance through the experts that have spent a ton of time playing with the complicated underbelly of that beast.


  6. Adam,

    That’s a valid request, but I simply do not like to joust and I believe my time is better spent in other venues and doing other things (both at and away from the keyboard). I think my blog (which has been sorely neglected) is a better place for technical material. I’m in this conversation in a probably vain attempt to shape the public conversation. The petition was public, so I commented publically. I’m about done.


  7. Kathleen,

    Can you talk about those scenarios where you need the capacity to control loading? A post on this topic would be a good bit of info to add to the communal .NET knowledge base.

    Lots of folks are struggling with understanding of how to make decisions between lazy loading, explicit loading, and eager loading, and are often trying to make decisions armed only with superstition.

    I’m especially interested in the metrics that drive the need.

    Your experience here would probably be of great service to the community.

  8. Scott,

    No metrics. Just complex object models that are used in different scenarios (different load patterns) and the need to control data round-trips both for server load and because I can’t guarantee a really fast pipe. The full range between a full load and complete lazy load of something like customers/invoices/line items could be several order of magnitude (obviously). It would be a rare side case to do the full lazy load assuming some reasonable aggregation on database server (but that arguably moves the business logic to the database). Because you don’t know what the user is going to do next, the difference is (obviously smaller) but we often have a good guess on what they are doing next, and often have rather small records so a larger packet and single call is an acceptable resource risk.

    OTOH, I realize that there are many people and scenarios that thrive on the “don’t make me think about details like that and just do a full lazy load”.

    EF either has to have a lot of flexibility and do both, or it has to pick a single scenario and accept that its use is narrow, or it isn’t going to be worth much.

  9. Let’s not confuse intentional architectures for lazy loading and don’t-make-me-think. There’s very little in a specification-first software practice that isn’t thought through.

    Lazy load as a default architecture has been used in high volume systems in practice.

    I’m curious about the specifics of the scenarios that you’re talking about because they represent the extreme cases where lazy loading must be traded off.

  10. From over four years of experience in building OR/M based applications, I can tell you that I have found three things:

    1/ I don’t know how my code is going to be used.
    2/ Trying to hand optimize on a case by case basis is a losing proposition, not to mention that it makes maintaining the application much harder.
    3/ Settings reasonable limits, getting smarter tools and optimizing only when necessary is the key to getting things done right, fast and on time.

    Take a look at a sample here:

    This is an approach that allows self optimization that holds very well in place of changing circumstances and additional requirements.

    Implicit Lazy Loading is a key feature of OR/M. Can it cause issues? Sure it can.
    But its absence is a bad sign. It means that the implementation don’t have the appropriate tools to handle it, and move the problem to the end developer.
    The application is causing too many queries, well, obviously it is the developer fault, even though he doesn’t have the tools at hand to support the appropriate style of work

  11. Scott and Ayende,

    I regretted answering this the way I did. This isn’t an appropriate time to discuss my architectures, and I don’t intend to continue. My envronment doesn’t look like yours, the same rules do not apply and that is completely irrelevant to this conversation about communication and community input.

    I hope EF supports both lazy loading and controlled loading, both early and late. Once there is a real product I’ll explore whether its appropriate for what I am doing based on the specific demands at the time. Load patterns will be one of many issues I’ll look at.

    The issue I have with full lazy loading scenarios is that I cannot always control the size/perf of the pipeline, or whether the db server is overburdened. Servers are cheap, but pipes may not be. But it sounds like from what both of you are saying, we are not talking about full lazy loading, but a tuned lazy load, and assuming that means I can exert control (sort of like LINQ to SQL does), is what I said. Ayende, I agree that I don’t want to hand tune everything, but I do need to be able to optimize, and I can sometimes see the issues coming when I see the screen design. I cannot buy Udi’s philosphy that grids are reports and non-editable. Just not my world. But, it would seem we agree.

    But what’s the point of EF being just another OR/M? Why use it instead of NHibernate if what you want is just another OR/M. Making EF NHIbernate seems very wasteful and it can’t meet your needs as you can’t evolve it fast enough. Doesn’t it have to be more? Or do you buy Jeremy’s theory that becuase its MS he’ll have to use it? That’s just dumb. Microsoft has around 14 data access strategies on the table and a constant remix of marketing messages.

    I understand that you perceive a certain est of minimum requirements for very good reason – including but not limited to POCO, lazy loading, and a better designer. I actually support all those features. I’m just a whale of a lot more interested in where they go with metadata, select stored procedure support, code generation strategy and pushing EF into new ground. The metadata is a near disaster for the things I want to do and while I applaud them for being the first team I know of at MS to seriously try to bridge the MSFT code gen gap, it isn’t where it should be yet.

    Sorry to ramble this morning.


Leave a Reply

Your email address will not be published. Required fields are marked *