Alt.Net Evangelism And What We Could Do Better

If we assume our goal as the Alt.Net community is to improve software development as a whole, we’re doing a pretty bad job.  Not that many people have even heard of the concepts we espouse, and those that have but didn’t convert become hostile to our ideas. 

My theory is because we focus so much on things that at the surface seem extraordinarily complex. Our terminology while correct, is acryonym laden and hard to grasp the real meaning. We ourselves sometimes lose site of why we even care about some of those principles, why we enacted them in the first place and what pain they caused to begin with.  

I’m not the first person to say or think this, but this has really hit home with me lately since now I get to talk to developers who are brilliant, talented and overall effective at what they do but who consider XP+SOLID a bunch of “enterprise junk” that fights against “natural coding” and my personal favorite “Unit testing is just testing your tests” .

I’ve tried to talk to people in a reasonable way when I hear things like this, but usually before I know it, the alphabet soup of acronyms is out of my mouth, BDD, DDD, on and on. Even as a hungry student those terms shut my brain down when I first heard them,  so why would I expect someone who feels they know what goes into software development to have a different reaction?

Since my goal is to do my small humble part to improve software development as a whole I’m going to try something new. If someone feels pain in the development process, then I’ll speak up with a solution and focus my language on the solution only. Because really thats what all these ideas and concepts are, solutions to big pain points.

The terms we use to describe them are unfortunately for the already intiated. Inversion Of Control, did any of you understand that without looking at code examples first? Behavior Driven Development, how many of you thought you knew what that was, practiced it, then realized that it means something else.  Just spouting off a bunch of acryonyms only excites the already curious who just have to know what they mean and for better or for worse they do not make up the bulk of the software development community.  

As for blogging thats a tough break, I use blogging as part envangelism, part bouncing ideas off my peers and superiors.  For the later I do need to actually use our alphabet soup to communicate, but for evangelism I’m afraid I contribute to turning off devs who are only googling for a solution. 




About Ryan Svihla

I consider myself a full stack polyglot, and I have been writing a lot of JS and Ruby as of late. Currently, I'm a solutions architect at DataStax
This entry was posted in Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I couldn’t agree more. I, too, hear GOOD devs saying bad things and trying to explain them without going into TLA-Land is problematic. I recently started a blog post series called “Let’s Build a Dev Shop” that I had put off for far too long. I wanted to give the uninitiated a quick initiation into putting a project using all these tools the ALT.NET crowd talks about all the time. I would love to get your feedback/assistance in making this series as accessible as possible for its intended audience.


  • jdn

    I think that a certain amount of appealing to the self-interest of developers can be helpful.

    There are idealist/purist/(dare I say)religious reasons for why a devleoper should embrace SOLID principles, testing, DI/IOC, etc. And some of those reasons are good ones. But, it also can lend to a confrontational tone that is off-putting.

    It can be helpful to put it in other terms. For instance, having a codebase that is based on SOLID principles makes it easier to have a test suite that one can run in 15 seconds, as opposed to having to launch the application and testing each thing manually, and then having to launch a debugger to figure out why things fail when they fail.

    This isn’t to say that you never need a debugger, or never need to launch the application, in order to verify one’s code. That isn’t the case. BUT, by only having to do those things for troublesome edge cases, you greatly increase the chance that your code will actually fulfill the specifications of the application.

    This means there is less of a chance that I, the smart but lazy developer, will have to spend time and effort that way. It lowers the risk to me that I will have to rework things.

    On some idealist level, it is, I believe, true that you will be a better developer if you embrace SOLID, etc. etc. etc. But I can defend that by practicing it and proving it by example. I’ve had more people follow certain things that I’ve done by just doing them in the first place and then explaining why it has been helpful, rather than beat someone over the head with it.

  • Henning Anderssen

    As a dev who is relatively new to the game, with only a year of experience, I feel it is much easier to absorb the “new” ideas than the seniors that have been doing their same old stuff for the last 10 years.

    Especially the last half year has been like a great awakening to me. I’ve been like a sponge, absorbing every new thing I can come over, and get all kinds of ideas that I want to apply to my projects. My recent adventures has been TDD and more interestingly BDD, as well as teaching myself DDD. I feel I belong more to the ALT.NET crowd than the mainstream devs.

    I’ve just been to Roy Osherove’s TDD masters course here in Norway, and I’m giving a quick intro/course to the rest of my coworkes, and it will be interesting to see how they respond to the ideas. I will also try to teach them everything I think I know about BDD. I’ve shown some examples using Mspec to a couple of colleagues, with mixed responses. As I expected, the seniors with years of experience where skeptical to the ideas and especially the tools. Hope it won’t be a challenge to introduce TDD/BDD to our shop.

  • @Henning from my own experiences and talking to fellow colleagues who’ve done the same, it’ll be painful. Either you yourself will lean that things are not always what your first interpetation was, only now you’ve taken your entire crew down that wrong path, AND/OR you will find so much resistance that you’ll learn a whole lot about politics.

    So my advice is go in expecting it to be hard, expect that when you explain something acronym laden that everyone will look at you like an alien, expect every old timer will think you’re a punk kid.

    Now with those ideas in mind approach your task with the utmost delicacy and gentleness. Because you are going in to change things you”ll be viewed by some as the enemy. Most wont care that you’re bringing in new ideas to improve things, they just see CHANGE == PAIN.

    What I’ll do differently next time follows: Win people over first, get to know them, propose these acronym laden things not as acronyms but as solutions first, last and in between, then once they see the benefits explain in detail the background of that idea, and the deeper concepts. Finally, I’d only introduce concepts as rapidly as I think they’re comfortable with.
    Throwing a bunch of new ideas at them all at once can magnify negativity.

    Example: If I want to teach them BDD, I probably have to show them DRY, YAGNI, and some aspects of SOLID long before that or they’ll have very brittle specifications that CAUSE more pain than they solve.

    As all the ex-Wachovia devs I know are fond of telling me, It took them 3 years before they had a “proper agile shop”, and this was with some of the most receptive and open people I’ve ever met. This is a journey of many steps.

  • @Lee I’ll make time tonight to review your blog posts, I think thats a great idea for a series.

  • This is a great and interesting topic. It seem though, however, that there are many who simply don’t want to hear about these things no matter what. In other words, approaching them with the solution is not enough to remove their “that’s how I’ve always done it” filter.

    A common example of this in my experience involves SRP. The single most common response I get to showing people SRP is “That seems like a bunch of extra code”. These people think that creating a new class is a major effort that should be avoided at all costs. Even though I can show the “solution” of how much easier it is to test and maintain code, these people will probably never admit to that and continue writing God classes. Unfortunately, this affects more people than just themselves, so the incentive is there to expand their knowledge, but they are content with doing things the way they do them and simply refuse to change.

    How to approach this situation?

  • T. Moriarty

    “If someone feels pain in the development process, then I’ll speak up with a solution and focus my language on the solution only. Because really thats what all these ideas and concepts are, solutions to big pain points. ”

    I think that is the way to go. Evangelism implies faith, where as, talking about the solution implies demonstrating your ideas.

  • Henning Anderssen

    Thanks for your tips. There where a few things that I haven’t considered.

    Even though I’m hoping for the best, I always fear the worst when it comes to these things. Teaching people new ideas, even in other aspects of life, can and will most likely be a tough task, as you mention.

    The idea wasn’t to say “hey, this is something that is new and exiting, deal with it and use it”. As you say, people are rarely going to adopt new things that easily, so even if I just light a spark in their imagination I’ll be happy.
    Luckily there are a few people that I know are open minded. and are willing to try new things. The rest I’m a bit unsure about, so it will be interesting to see how it goes.

    Even though we sort of use “lean” and scrum methods, I feel we’re far from an agile shop. Hopefully this will be the first, and maybe one of the most important steps in converting to an agile shop.

    Should I mention DRY, YAGNI and SOLID principles, so they can start investing themselves? I think and hope that if I push them in the right direction, atleast some will start learning new things. Even though I’m learning alot of new stuff these days, and I evangelize about them all the time, I’ll never be able to explain it as good as the smart brainiacs here on teh interwebs :)

  • Andrew

    The biggest problem I’ve seen is there seems to be a bit of a holier-than-thou attitude out there. Not everyone displays it of course, so I don’t want to tar everyone with the same brush, but it does exist.

    A perfect example is a few months back when in his own blog Ayende/Oren said that he feels that the Repository Pattern is over used. For small ASP.NET MVC projects using NHibernate, he thought it’d be much eaiser to just use ISession in the Controllers, why bother with all that added complexity when NHIbernate can do it for you.

    Well, you’d think that he’d set Martin Fowler’s pants on fire and kicked Eric Evans square in the nutsack because people freaked. Of course, considering everyone and their uncle in Alt.Net has a blog, it turned into a “Read my blog to find out why Ayende is wrong!” sort of thing. Maybe we was “wrong”, but It was very off putting.

    I see a lot of petty bickerings about things that shouldn’t even really matter.

    Also, for what it’s worth, I doubt there are many “brilliant, talented and overall effective” C# developers out there who think SOLID, testing, et al is dumb. As a matter of fact, I assume most good developers adhered to the SOLID principles without even knowing it because they just make sense. Unit testing, even if they don’t do it, I’ve never heard a good developer argue that it was bad (just that it was time consuming).

  • Andrew


    To be honest, DRY, YAGNI and SOLID have nothing to do with Agile. If developers can’t see the benefits of not repeating themselves or not wasting time building something that might never be used, well then I’m afraid there isn’t much hope for them (from a learning standpoint).

    That might sound harsh, but it’s the reality of our profession. In our profession, whether we are qualified or not, we make too much money especially considering there is no real way to quantify success or failure.

    People like that, espeically those who are entrenched in a position that they’ve occupied for years, need direct instructions from above them on the food chain to change. I’m not saying it’s not possible (because it is), but it can be daunting to try and get people to change from the status quo.

    Good luck though.

  • len smith

    we’re not going to convert the masses, they don’t care about writing good software.

    dumbing stuff down so the masses can write bad software is microsoft’s job

  • Henning Anderssen


    I don’t think I’ve heard a developer say that testing is bad, but I have heard the traditional arguments against testing, such as “it will take to long”, “we’ll test after the system is complete”, etc. We all know that those reasons are unfounded. People may just be to ignorant to do anything about it, since they’ve never done it, hence it’s a big scary monster nobody wants to touch.

    I agree with you that those principles has nothing to do with agile, like many of the things in DDD has nothing to do with DDD. It’s plain old good OO. It may take a bit of self discipline at first to start using those principles, but once you’re used to it, you’ll never go back.

    I might be painting a darker picture than it really is, and I’m hoping I am doing so, because I really want people to learn and be open minded. However, I get a nagging feeling about it, so time will tell.
    I realize that I’m not be able to teach everybody everything, but if I’m able to nudge them in the right direction, and they start questioning things then I’m quite happy.

    I’m giving the talk tomorrow after work. I can tell you how it went hehe.

  • @Len

    Sorry Len but I feel that the attitude you’re advocating is the exact thing I’m trying to prevent.

    I do not think its “dumbing down” to be careful with dropping acronyms _all_the_time_ particularly with the uninitiated, or to focus on the actual _solution_ that these principles provide, instead of just assuming people will care when you say “you’re doing wrong try TDD instead”.

    I’m saying its high time we starting refocusing ourselves to solving a problem instead of living in an ivory tower where we say to ourselves “well at least we do it right”.

    From a self interest point of view its high time we do what we can to decrease the amount of crappy code that is out there, and that we have an easier time hiring colleagues that have no concept in their being a different way to code.

    Obviously one of us isn’t going to do it all by themselves so everyone that does have a clue, should not be hesitant or unwelcome of the concept to changing their _own_ approach .

  • @Andrew

    There is some truth to what you say, but the sad reality is there are statistically a lot more people coding making good money without using DRY< YAGNI than there are that are.

    We need to do what we can to show them they’re shooting themselves in the foot, if they really feel that DRY isn’t worth it, then increase their workload (even if it means increasing your own) so they have to feel the pain of their slow way of doing things. You’re right sometimes even that won’t work, but honestly we should be in the trenches trying to make gains where we can. Sometimes that involves getting help from on high, but ideally not.

    Also side note Ayende was also advocating a Query Object for complicated queries rather than a full repository which he felt was too coupled, so not only was he advocating simplicity where it makes sense (via ISession), but for the truly complicated queries, dropping them all in one place leads to a mess to maintain and test.

  • Andrew


    I fullly agree that there is statistically quite a few people making good money while outputing lousy software, the problem is many of those people don’t care to improve what they are doing. I really don’t think those people are worth preaching too, because frankly they’ll never read a Alt.NET site anyways. You don’t end up reading Los Techies, Code Better, et al by accident, you find them initially by searching Google for solutions to problems, but you keep reading when you find what they are saying make sense. Who you want to speark to is the younger developer who doesn’t really no any better than what Microsoft has told them, but who wants to improve their craft. In that vein, I think Los Techies does a great job in highlighting the “basics” on your main page, something other Alt.NET sites should follow. Also, improved examples would probably help too (I find most of the SOLID examples out there incredibly contrived, trivial and not very “real worldish”).

    Think of it as trying to pickup a girl a little bit out of your league at a bar, you really only have one chance to impress her before she just puts up the “okay, stop hitting on me” wall. Alt.NET sites might really only have one chance to capture the imagination of what is commonly referred as a “5:01 Develpoer”, but often miss the opportunity because the blogs are getting filled with, for lack of a better word, crap. Bicking Blog posts or long winded entries talking about fringe conditions are a huge turn off to most people.

    As for the Ayende situation, having a civilized discussion about the queries part of his “solution” within the comments of the actual blog posting would have been good, instead it turned into an excuse to write a pissing contest blog about abandoning the Repository Pattern on another website. Basically, it turns into something alienating to all but a small portion of the already converted, the majority of people really don’t care to see a geek fight.

    Again, I think Los Techies is definitely on the better side at introducing Alt.NET type philosophies to the masses, and I think its’s the other websites that are lagging behind.

  • Be careful when you try to appeal to the masses. In my opinion, Alt.NET stands apart precisely because its members don’t shy away from difficult concepts and terminology. It took me a few days of Googlework to learn concepts like inversion of control, dependency injection, domain driven design, etc., but the effort was worth it. It forced me to grow. Don’t water down the content; but make sure that explanations are thorough. Raise the bar, don’t lower it to the least common denominator.

  • @Ncloud

    Again not at all advocating watering down of content. But altering how it is introduced.

    I’m advocating we get back to the roots of why these principles came into existence in the first place. Focusing on the concepts not as theoretical benefits with abstract examples but as _actual_solutions_to_pain_points_ .

    If we are only talking to ourselves whats the point? Great now I’m a better dev, but now I have to hire other people because I’m too busy, let me just throw a crap load of acronyms at them and if they don’t just “see” why this matters well I’ll just get another wave of people and repeat the process, over and over again.

    If you cannot show “the masses” how this benefits them without concrete real benefits, then whats the point of the principles? We absolutely need better ways of approaching those without the knowledge than we often currently exercise.

    At my local user group we’ve had about 5 or 6 SOLID oriented talks since I’ve started and honestly most of them were fantastic and even I who’s done one of the talks learned something from each of the others.

    But we get lower attendance for those normally than when we do talks on Silverlight or some other MS technology. Wouldn’t it be more effective to do a Silverlight talk that happens to show a useful use of DI, YAGNI, etc. Jeffrey Palermo comes to mind as someone that did an ASP.Net MVC talk and littered it with examples of Composition, DI, IoC, etc. Thats exactly the approach we need more of.

    Finally, I think we have enough idealism in the community to not have to worry about being too close to the least common denominator. We have a long way to go before thats actually a concern.

  • @Ryan Svihla

    “Wouldn’t it be more effective to do a Silverlight talk that happens to show a useful use of DI, YAGNI, etc. Jeffrey Palermo comes to mind as someone that did an ASP.Net MVC talk and littered it with examples of Composition, DI, IoC, etc. Thats exactly the approach we need more of.”

    Yes, good point, I think that would be fantastic. Makes a lot more sense now.