The ALT.NET Criterion

Recently I was on a mail thread where the following question was raised. "What are the kinds of things that concern folks from the ALT.NET community?"

Over the past year I’ve been pretty involved with ALT.NET and have been part of countless conversations, blogs and email threads on this topic. One of the main takeaways from those experiences is that many of the problems in developing software arise from a lack of application of the following set of principles.

  1. Separation of Concerns
  2. Single Responsibility Principle
  3. Law of Demeter (LOD)
  4. DRY
  5. Not doing BDUF
  6. Liskov
  7. Favoring Composition over Inheritance

These principles are orthogonal to language, technology and platform. Applying each of these principles leads to software that is easier to test, easier to maintain, and easier to extend.

So the real question is not about ALT.NET, it’s "How do we build better software?"

This entry was posted in misc. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Glenn Block

    Hi Damon

    I agree that ALT.NET is not saying something new. As David used the flag metaphor, I think ALT.NET is saying “Woa..something is wrong”. The good news is we have an answer that has stood the test of time which are the many established practices that exist and which were fathered by many of the people you mentioned. Whether you do it and call yourself an alt.netter or not makes no difference. If you want to call yourself an alt.netter as way of saying I support those practices..go right ahead.

    The most important thing is “the practices” themselves vs the messenger who is calling people to them.

    On the subject of how do we get the masses to accept that these are not principles limited to some elite, and they are just basic things you MUST DO. I am not sure. It’s easy to blame Microsoft (and I am sure we are in part), but from my ten years outside Microsoft, it has a lot to do with software shops themselves and management. The push is always for quicker turn around times, lowering the bar of development, cranking code / more features in less time, etc. In these shops, designing good software is often considered more of an artistic exercise rather than a necessity. The belief is that with the tooling, we can get there without the principles. I also mistakenly believed this at one point. Until these organizations perceive it as a necessity, it won’t happen.

  • Damon Wilder Carr`


    Good discussion but one thing has started just recently to make me pause around ALT.NET.

    Someone said to me the other day about a slightly forward thinking idea (nothing to do with anything ALT.NET, OO Design, Tools, Agile, or anything related, but an early release from a vendor)

    “You and your ALT.NET stuff… We must liv in the real world at ‘Company X'”

    Excuse me!!!!!

    1) There is really nothing new or even a little innovative about any of this

    2) We are setting a rather bad example in our behaving as if (1) is not true.

    99.9% of the current leadership in ALT.NET (from a hands-on perspective, what else is there?) didn’t discover, invent or even contribute to most likely any of this, and most of the really amazing ‘team oriented’ software people with over say fifteen years of experience already knew this stuff cold. The Bob Martin… The Kent Beck.. Martin Fowler. Grady Booch. Tom DeMarco & Time Lister. The list goes on and on and on.

    The material was always there. The culture I built in 2001 was what people today would call ‘ALT.NET” (as much as we could be and that was not close to what we can do today).

    So I submit ALT.NET = Simple Proven Facts around Being Good (not even great) at Software, extended into focusing on Long-Lived Software with Assumed Strategic Value etc.

    The bullet items are GREAT! But they are just the cost of entry.

    I know… There is more to it. We put our spin on these ideas I agree. But not enough to cause the chasm I see now between those who are ‘base line informed’ and ‘clueless’.

    We have an arguably better set of ‘toys’ to implement with, and I certainly have put functional programming to good use in just about all the common and core design patterns (like implementing the concept of a Decorator instead with a Repository based set of externally defined delegates which are discovered at run-time).

    I just would not have done that before (or when I did before it was a hack much more then now). But at what point to we eliminate the reasons the mass .NET developer is not fond of ALT.NET? When do we shame the average into accepting facts?

    When we discuss this stuff like it is novel, or in some way ‘optional’ or ‘optimized’ we are saying ‘this is for us, not you’.

    I know that is not the intent. However I would submit until the people who set the tone of software culture and indeed the average member of the average team ‘see no viable or rational alternative’ to be just reasonably informed, we’re in for what? Another decade if not more of stagnation if history is our guide?

    “Politics is getting others to do what you desire but having them believe it was their idea” – Winston Churchill

    I’ve rarely found a way that works but this, ESPECIALLY with the ‘herding of cats’ that is software culture.


    I believe the purpose of ALT.NET has been served. A fire is now out of control. There is no turning back. .NET is saved and even Microsoft could not turn back now I believe, and a more evolved image for those involved serves us far better.

    A name? Who knows..Something like ‘Strategic.NET’. ‘NotAnIdiot.Net (sorry), or … well this is why I named my group (as we are so grounded in all things domain-driven). See I suck at names.

    ALT.NET is like XP. The words kill you and have emotional baggade. We are now describing far more the intended.

    Kind Regards,
    Damon Wilder Carr

  • Casey

    Don’t accept that the status quo is neccessarily the best solution

  • Glenn Block

    Guys I forgot to add one principle to the top of that list, wholesale application of the Bellware principle :)

    Scott, I hope you think this is funny. It’s meant to be.

  • Glenn Block


    Good points. I tried to avoid specific methodologies like DDD, Agile etc. The principles above can be applied in any methodology (I believe)

  • Glenn Block


    Easy answer. Don’t limit yourself to those guidelines. I hope you weren’t inferring my list was that predefined list :)

  • Glenn Block


    Good point, I didn’t touch on methodology and avoiding tooling, though we should probably add Resharper on that list. How many systems would be more maintainable if they were built with Resharper? :)

    On the methodology, are they mutually exclusive?Meaning are you saying that someone developing with a Waterfall methodoloy AUTOMATICALLY means doom and gloom?

  • Glenn Block


    How do you mean? DRY doesn’t say anything about reinventing existing solutions. DRY is about not having to repeat the same thing over and over whether in code or configuration within a solution.

  • Glenn Block


    I am not arguing these are ALT. I don’t think the ALT.NET community claims to “own” anything. That was the point I was trying to make. It’s easy to just box in the community and say they “these are ALT.NET concepts”. ALT.NET is just taking from a pool of good practices that already exist, and have for some time, but which seem to have been forgotten. It’s this revival of practices that ALT.NET is about.

  • Glenn Block


    I didn’t say these were the only set…

    On DI it’s not really a principle though it’s a pattern you can use to apply many of the above principles like SOC for example.

  • Alex Simkin

    What happened to several othet letters from S.O.L.I.D.?

    Open/Closed Principle, Interface Segregation, Dependency Injection?

  • Christopher Bennage

    I’m with you.

  • joe

    While I don’t think anyone can argue with the points you have listed, I do think that you’re missing a big one: What makes these “Alt”?

    Outside of the .net community, with the exception of #5, these are just considered good (and standard) OOP principles and practices. Why is it different for us?

  • Marc Brooks

    The one thing that stick out on this list that doesn’t seem to be FOLLOWED by some people claiming Alt.NET is DRY. Far too many things are being reinvented and reimplemented instead of used as-is.

  • Scott Bellware

    “How do we build better software without limiting ourselves to only those criteria that Microsoft wants us consider lest we invalidate half of Microsoft’s product lines.”

  • Brett Baggott

    As I read this, I found myself nodding my head. I completely agree, but then, I’m part of the choir. I think ALT.NET is more on track to find relevant solutions to the problems we face as developers than anything else I heard in recent memory. I’ve had a few people recently tell me things like, “don’t give me that ALT.NET crap”. They must not understand. Please, send me developers that ARE searching for exactly what you mention, how do build better software (and software better I would argue). I do have one nit pick, I’m beginning to loath hearing the overused word “orthogonal” and I don’t think it’s appropriate hear. These principles DO apply across the board regardless of language, technology and platform. They are not “independant of”, IMO. However, I do not presume to tell you anything you don’t know, I highly respect your opinion – I just wanted to share mine.

  • Jeremy D. Miller

    I’ll add:

    * Maintainability / Sustainable development
    * Agile Methods, and specifically in regards to MS technology, the ability or ease of use of Agile practices with MS tooling
    * Efficiency of code centric techniques

  • Johnny Hall

    Add SOLID

    Single Responsibilty Principle
    Open Closed Principle
    Liskov Substitution Principle
    Interface Segregation Principle
    Dependency Inversion Principle



  • Anon

    8. Whatever Bellware says
    9. See #8
    10. You must be a bellware kiss ass too…don’t forget that.
    11. See #9