imagine you have an Enterprise-level project, with 100 developers, how many of them are likely to grasp what IoC is?
There are two reasons that I disagree, let us start with the one that had forced me to sleep on this post rather than send it immediately. The underlying assumption here is that "Morts can't take this stuff". It annoys me a great degree, because this is both arrogant and baseless. Those "alternative" concepts that we are talking about are not born of thin air, they are the de-facto standard of operation in many shops.
Let us focus for a second on the Java camp, shall we?
I would be greatly insulted if anyone tried to claim that Java developers are intrinsically better than .NET developers. But for some reason, those concepts - IoC, MVC, OR/M - that Morts can't ever figure out, are not only popular there, they are they default choice in many cases. And they are the choice for large, Enterprise projects.
So, what is the difference between the two? Why can Java people scale those concepts to large teams and .NET people can't?
The answer is that there is not real reason except a common misconception about the capabilities of developers to learn & grow. By assuming the "they can never understand that" attitude, you are limiting what you can do and form an elitist view of your developers.
I am pretty sure that this isn't what Simone intended, but this is how I view the general sentiments in that direction.
Now, I mentioned that I have two reasons to disagree. The second part is my own experiences working with those tools & concepts. All my projects for the last 2.5 years or so have been using IoC and OR/M, the last two are using MVC as well. I don't work alone, and I work with people of varying degrees of knowledge and interest in the technology for the sake of technology.
The reason for doing that is simple, it works, and it helps produce successful projects. I have an answer to "How does it make my job easier?" and I have successful projects to back this up.
You can see what kind of code we are writing right now, IoC, OR/M and MVC are easier than the other way around. And it is my responsibility to make sure that (a) the developers understand what is going on but (b) they shouldn't have to deal with it on a day to day basis. Properly used, IoC is completely transparent to the application. OR/M is not transparent, but it is very easy to use, and I want to split the code between the controller & the view.
So yes, you can scale this up to hundreds of developers. In fact, I can't really imagine other ways to manage this complexity without using those concepts.
Just as I find it pointless that you’d go to a conference to discuss the stuff that everyone there already knows. DDD, BDD, MVC - these aren’t things that will be unknown to people attending the ALT.NET conference.
ALT.NETter A: so… heard of that new BDD business?
ALT.NETter B: Yep.
ALT.NETter A: Oh, well there’s this great new idea called DDD!
ALT.NETter B: Yeah, right into that too.
ALT.NETter A: Oh.
And so on. But wouldn’t that conversation have been a whole lot more interesting if the second developer hadn’t heard of those ideas?
I am eating myself up because I wasn't able to go. Because those are the kind of discussions that I would really like to have. Not to be in a comforting echo chamber where all my ideas are confirmed, but because then I can continue the discussion forward, and say:
ALT.NETer B: So, we are using DDD in this scenario, and we have run into conflicts between...
ALT.NETer A: Hm, I think that I have an idea, do you have a laptop so we can discuss this over code?
When you are on a level plain field, then you can start advancing. That is important, and a reason enough for the conference as it is. But while that compromise a significant percentage of the people that were in the conference, it is by no mean all of them. And that certainly wasn't the main topic of discussion.
And in order to address that imbalance, the ALT.NET mob organise an enormous desert circle-jerk, and I call bullshit. If they really wanted to change things then they should be writing about their techniques in detail, coming up with introductory guides to DDD, TDD, mocking, creating screencasts, or giving talks at mainstream conferences, or producing tools to make the level of entry to these technologies lower than it is.
Um, I thought we were doing that?
From Jeremy Miller's WinForm Design Patterns to your own screen casts to Scott Bellware talking in DevTeach about BDD to building efficient tools. I don't think that this is a fair statement to say, frankly.
Those are courtesy of Jdn's post.
If you don't, you are stupid, a Mort, or, god forbid, an architect.
Oh my, I am not sure if this was intended to be amusing, but I certainly find it so.
Similarly, it is okay to use a Visual Studio designer. It is even okay to use drag and drop. There, I said it. Let me say it again, with feeling: IT IS OKAY TO USE DRAG AND DROP.
This comes at a very appropriate time, since I just spent a few hours wresting with a drag & drop code-gen solution. I got it to work, even. But the end result is not what I want or need, so I am going to rewrite it by hand tomorrow. So there, it is perfectly OK to use Drag & Drop, and I would probably never do anything in WinForms without the designer.
Note, this is a partial (and the final) response to Sam Gentile post about ALT.NET.
Now to the part that actually talks about ATL.NET:
ALT.NET is a divisive thing. No matter what they tell you, they are full of negative energy, they sneer at others that don't buy into their view and sneer at the "enterprisey" folks.
ALT.NET is divisive, of course. Like any idea, it divide people into those who agree and those who don't. The ALT.NET doesn't include a value statement about those who don't agree, I am feeling forced to point out. And I am not sure that I know how to sneer, as a matter of fact. Perhaps I need to start taking lessons.
I believe that I stated before that I believe in the option of respectfully disagreeing with someone. Me & Roy often end up there, so I know that this is possible.
Viewing ALT.NET as a movement about rejection is a mistake, it is about accepting more options, about keeping your mind open.
The underlying issue is that like all people, I am lazy, and as such, I would really like to be able to just use the off the shelf, standard stuff. Unfortunately, I have found that fairly often, that doesn't do what I want, and to make it do what I want would be more costly than doing it from scratch. As you can imagine, that came as a shock.
At first I dealt with it with denial, there is no way this can be, that is what everyone is using, no way that it has this problem, obviously I am missing something. I went and did my research, and discovered that indeed, everyone who tried to do what I wanted run into the same problem, and had to solve it using the same wahonie shaped solution. That was the reluctant compliance stage, a lot of people stay there.
Finally I accepted that this is indeed a problem, and I set out to find other means to achieve my goals. They were not standards when I started, but they certainly moving in that direction for a while now.
ALT.NET, in my view, is about accepting that there are better ways to do things, and you should go and find them if your current way is painful.
Don't miss the last part, it is important. I hope that I am practical, and good enough solution is just that. If the current way you are doing things is not painful, there is no reason to change anything. If it is painful, then accept the fact that there are other ways and find them.
Note, this is a partial response to Sam Gentile post about ALT.NET.
One of the things that Sam said that I fully agree on is this one:
...walking into a Fortune 50 bank with 200 systems, using 20 different technologies, totally non-integrated, and listening to the business needs and using solution technologies like BizTalk, Neuron, WCF, MOSS, Sharepoint and such putting together a solution that requires me to have intimate knowledge of the business as well as single sign on, multi-domain security trust domains, asynschronous message brokering and lots more
Solving this kind of problems is non trivial and requires understand both tech and business issues. There aren't a lot of problems like this, however. In fact, most of the problems that I am dealing with aren't at all similar. Which leads me to the parts that I don't agree with:
It comes from that community's [ALT.NET] inability to see beyond the code level, something I refer to being constantly in "the weeds." They refuse to work on back-end systems as beneath them, everything "enterprisey" is beneath them. Being in the weeds means you only look at everything as code and can only see code.
No, actually, it does not. If I can solve something easier using capabilities of BizTalk out of the box, I will use that. Hell, I am using BizTalk in my current project, precisely because of that, it makes talking to non reliable sources fairly easy, so I don't have to write this code. BizTalk is not enterprisey, but a lot of the solutions that utilize it are.
There is a reason that I don't like to hear about web services, ESB, etc. I understand and even approve the basic ideas, I don't like what happens when those ideas are turn into buzz-wards. The problem then is that you start the process of understanding the problem with "Assume that we have an ESB...", simply because this is the thing to do right now.
Sam calls my approach "being in the weeds" (I don't agree, but let us get to this in a minute), the other side for that is the Architect in the White Shiny Tower, handing Architecture to the masses.
Now, let us get to the "being in the weeds" and "refuse to work on back-end systems as beneath them". My statement to this is simply:
I will refuse to work on a back end system if using it will make my life harder than using another system/library or rolling your own, period.
SSIS comes to mind very clearly in this regard. It is not a blind refusal, it is an educated one, based on (painful) experience. Yes, I do have a prejudice against big back end systems, that came from seeing all the enterprisey solutions that where built on that. After seeing so much time going down the drain making a back end system behave the way you want (which I would have think was the natural way to handle), and comparing it to the amount of effort that it would take to just do it on my own...
I believe that I have a good basis to my prejudice. That doesn't mean that I will roll such systems completely, but that I will evaluate each case independently.
What Sam calls being in the weeds I call confidence. I am confident that I know what I am doing, that I understand both the business requirements and the technical ones, and I am capable of solving the problem without taking a preconceived dependency on a back-end system.
The problem with the approach that Sam depends is that it is too often so high you never sees any of the details, ending in an enterprisey result. One too complex for the job required, and costing more than it should. I never worked with Sam, so I have no idea about how he actually work, so keep in mind, this is not about Sam. It is about seeing and hearing about quite a few designs that are totally wahonie shaped, just to fit a preconceived notion of how Things Ought To Be.
And that is the approach that I would reject.
Note, this is a partial response to Sam Gentile post about ALT.NET.
Enterprisey - This is a derogatory term, used to refer to a system whose design or implementation is overly complex compared to its supposed function. Often the term refers to the usage of anti patterns such as Everything is configurable, Executable XML, etc. Those systems are consider bad because a simpler design or implementation would have achieve the same purpose, at far lower cost, with greater maintainability overall.
Enterprise Software - A common term used to refer to systems that usually run a core part of a business. Often those are mission critical systems, which interact with many other systems in the organization in many interesting ways. Enterprise software is considered hard because it often need to mix technological capabilities with the business logic, and be flexible to handle changing conditions as the business evolves.
Enterprise Software done right - A system that handle those complex issues while keeping complexity to the minimum necessary to handle the actual requirements.
Enterprise Software done wrong - see Enterprisey