+972 52-548-6969
What I don't like the Patterns & Practices efforts
The P&P groups has a lot of stuff that they release to the world, often with a lot of fanfare and people talking about that. I have reached the point that I no longer care about what the P&P guys are doing. Just having them release something, practically guaratees that this is not something that I would like to use.
This has nothing to do with OSS vs. MS or something stupid like that. This has to do with the following reasons:
- The P&P team doesn't work with their tools on real applications. Basically, these tools are created in vacum, not by having to solve real world problems. And going to a customer and asking about problems and then trying to give something that may solve that is not what I mean. I mean about having to work with a system day in and day out, and having the biggest incentive to smooth all the wrinkles.
- The stuff that they release almost always build on the naked CLR, it tries to build on top of that something to ease the pains of people who are working with that. The problem is that if you are doing that, you may be making great strides in making a developer life easier, but you are taking them in the completely wrong direction.
- Marketing. This is related to the next point, a lot of people are pushing this stuff, almost blindly. And Microsoft can dedicate a lot of resources to spread this around (evangelists, posts, articles, etc).
- Quality vs. brand name. This is a touchy subject, and I would really like to make it clear that I am not saying that the P&P is producing bad code. What I do want to say is that the P&P code does not goes through the same level of scrutiny that real products from Microsoft goes through. In other words, the CLR, for instance, has gone a thorough testing and design effort. The DAAB, on the other hand, has a much lower testing & design effort in comparision. The problem is that people are seeing Microsoft DAAB, and they automatically assume that this has the same quality.
I can push a code base fairly hard, and the CLR is pretty good about what I can do with it. When I tried to do the same to the P&P stuff, it literally fell apart.
When looking at the stuff that the P&P produce, I see things that are extremely complex to their purpose, hard to use and maintain, and don't really add any value to me from where I stand today. I am not speaking blindly here, it took me 40 minutes to repreduce the policy injection block.
Even if some of the stuff that they are producing has good stuff in it, it is usually in a form too abstract to be readily used. The CAB is a good example, I like some of the ideas there, but it comes with so much weight around it that it is not worth bothering. I can build on the same ideas in half a day and end up with a far more light wieght approach, easily testable and easier to explain to the next developer.
Comments
Seems like a lot of talk, you should back it up. I'm not disputing what you are saying, but you make a lot of claims without really much to back it up. Seems like a little bit of your own marketing :)
I agree with some of this...
P&P should do more pratical real world complex examples, and discover / evolve from there findings.
They do however raise awareness, which is a good thing.
Finally, each member of P&P should blog as much as you do :)
Good Post, gonna be a hot one.
I totally agree with you Ayende.
I've always found them to be overly complex and way over engineered just so that they could be used in just about any situation the designers could possibly think of. The library even has it's own configuration utility for crying out loud.
When I think of a "block" I think of something small, light-weight and easy to build with... The P&P team seems to think "block" means one of those 101 tool swiss army knives that people buy for the novelty of having a knife that's wider than it is long.
"The CAB is a good example, I like some of the ideas there, but it comes with so much weight around it that it is not worth bothering. I can build on the same ideas in half a day and end up with a far more light wieght approach, easily testable and easier to explain to the next developer."
I agree that CAB is awesome in concept, but is largely over complicated and TOO abstract for the use.
BUT, you took the same ideas and went with something that works for you, so didn't the P&P group succeed?
(and I'd have to say, that the P&P group probably isn't targeting you, they are targeting JoeSchmoe Developer who doesn't know how to separate database connections from the UI...)
Chris,
I think that I do back it up it. I gave a few examples, the policy injection block is an obvious one, and there are many other example just in this blog.
"The P&P team doesn't work with their tools on real applications."
Amen brother!
That's the trouble with any group going off on their own and churning out frameworks without serving the needs of a real application while the frameworks are being developed. They aren't based in reality and are more subject to YAGNI issues.
Ben ,
I didn't get any new ideas from CAB, frankly. I am using the same patterns in my own code, but it is not something that I got new from P&P.
Obviously I am not the target, the problem is that the people who are the target are led in the completely wrong direction.
This is absolutely true on all points. I've spent some time tearing through ObjectBuilder and the CAB to understand how they work, and there have been several times where I was aghast at decisions they'd made. For example, ObjectBuilder uses reflection to inject dependencies into instances that it's creating. Nothing wrong with that... except that it doesn't cache the results of the reflection in any way. Combine that with the fact that literally every object created in CAB goes through ObjectBuilder, and you've got a serious waste of resources -- at least for non-Singleton objects. Contrast that with Castle: once a ComponentModel is built by the ModelBuilder, no re-analysis needs to happen in order to create a new instance of the same type. P&P comes up with some great ideas, but they should be a little more active in the community in order to absorb concepts from existing projects as well.
Also... don't get me started on the whole concept of "software factories"... shudder
"Even if some of the stuff that they are producing has good stuff in it, it is usually in a form too abstract to be readily used. The CAB is a good example, I like some of the ideas there, but it comes with so much weight around it that it is not worth bothering."
Then don't bother. I don't think you really get the point of what CAB is by your statement. Yeah, there is a little learning curve but it is one of the better blocks out there and while there is some "weight" around it what do you expect for an application framework? My point is an investment in CAB is the smart choice from both a business and a career viewpoint. If you can't see that you're blind. It's a common application framework that if widely adopted already gets your foot in the door with a common vocabulary among prospective peers. Furthermore, from an business viewpoint a ready-made application framework of this caliber will save development time and therefore money. I appreciate your opinion, but it's just dead wrong.
"My point is an investment in CAB is the smart choice from both a business and a career viewpoint. If you can't see that you're blind. It's a common application framework that if widely adopted already gets your foot in the door with a common vocabulary among prospective peers. Furthermore, from an business viewpoint a ready-made application framework of this caliber will save development time and therefore money."
Your points, while accurate, have nothing to do with the technical quality of CAB, which is what Oren was talking about. I don't think you'll find much debate that frameworks are helpful for a lot of reasons, both technical- and business-oriented, but a lot of the stuff coming out of P&P just isn't of the necessary level of quality. While it's true that P&P efforts can get all .NET developers on the same page, it might not be the right page for everyone to be on. The real problem is that Microsoft is asserting that P&P's work represents the "best practices" of the industry, wherein reality that is far from the truth in some cases.
Also, not all frameworks need to be "weighty" -- my current open-source effort, Titan, is aimed at providing a core dependency injection framework in a single assembly at less than 100KB. (Shameless plug! :)
You're absolutely right that the quality of the P&P design/code is no where near the quality of the CLR. I haven't used P&P code for years. Where I work, we have better alternatives to some of their blocks, and the other blocks solve problems that we simply do not have.
Their written articles, on the other hand, seem reasonably good. (As long as you don't do everything they say - since due to their comprehensive nature they will always contain points that are not relevant to your particular situation.)
The P&P blocks certainly seem to polarise opinions. I've often heard they viewpoint that FredP expresses above, "It's a common application framework that if widely adopted ...". I never know quite how to respond, other than to point to the alternatives that my team is using right now. They do everything we need, and they take less work to set up and use.
In this discussion, a P&P team member did acknowledge some of the problems with the old UI block (and corrected my mistake in confusing it with the CAB): http://discuss.joelonsoftware.com/default.asp?dotnet.12.343481.10
I used the CAB on a project, I thought it was very heavy. We ended up dropping the parts that used the CAB though as it was not friendly and required too much upfront time to get people rolling on it.
My biggest issue with it was that the documentation seemed more about a 'hands-on lab'.
Some features were very rich.
I agree with above post about a 'block' being lightweight. I prefer lightweight solutions (ie. Windsor).
Lastly, I do think because it's called 'Microsoft' P&P then it gets a nice backing.
What I find interesting is that someone like David Hayden will say good things about, ie'. Windsor and then basically try to duplicate that in P&P. I think P&P would be fantastic if instead they took a project like Windsor and used that AS their DI/IoC, rather than create their own.
Same with the Web UI blocks I saw - why not take a good MVC like Monorail and build it up - ie. use the aspx aspect of Monorail.
This is where I probably struggle with Microsoft the most and P&P seems to follow the same 'party line' : re-create the wheel, slap a 'made by Microsoft' sticker on it and act like it's a new great idea that everyone should do (hmm, let's see - MSUnit? or now it's 'Linq over Sql' ?).
How about a DAAB that integrates with NHibernate ?
So, in two summaries:
I feel their implementations are heavy and complex. Trying to solve complex problems with an idea to make it 'easier', but to really do anything 'real world' means their tool makes it more complex. Not being easy to maintain and test is a downside to this heavy approach.
Stop reinventing the wheel. Use tools the community has used, they are simple 'blocks' already created for specific tasks at hand.
Gee, there's another Chris here - I better differentiate :-)
Yes, I think they were relevant a few years ago... but they haven't moved on from there. Definitely nowhere near as innovative in the architecture space as guys like Martin Fowler... although the good ideas seem to have slowed down lately.
CK
FredP,
Please take a look at what Entity Beans did to the Java world several years ago. Here you had a heavy weight standard way of writing things. People rebelled against that for the reasons that I am specifying above.
Having a common way to do something the wrong way isn't good at all.
"If everyone jumped off the roof..."
Oren,
I can partially agree with you here but I need some proof. Yes, the CAB/SCSF/EntLib stack is large. Spitting out a project requires many projects all interconnected, etc. And there's a lot to learn. Most of the smart client apps I'm developing are all CAB based because it gives me everything under one roof. Having said that, I know that you can get the same with Castle/NHibernate/Rhino but there's a big RYO aspect here. For example, to get something like the Event Broker I would need to setup some kind of message manager. True, I could probably slam it together with Castle or some code in half a day, but why do this when it's already there? It's like fast food. Yes, it's not the best thing for you but it's convenient. Maybe the stuff P&P produces is fast food and like the guy from the Super Size Me movie, it shouldn't be good everywhere. I don't subscribe to the hammer theory of software development. However am I just substituting one stack for another? If I was to start up a brand new project, could I hit the ground running with everything I needed (assuming I knew the frameworks). Putting CAB learning aside, I can do that with the p&p stuff. With the OSS stack (again assuming I know the APIs inside and out) I still have to build something to get me what I need don't I? If we can do a real side-by-side compare so that given a developer knows the API stack for any given approach, would it really be that different? With all the stuff out there these days, the last thing I want to do is have my developers building framework type stuff. Reuse always wins in a corporate environment over RYO IMHO.
Bill,
I was very careful not to name solutions from the OSS stack, because I don't want it to become a comparison of OSS vs. P&P stuff, that is not the way I want the discussion to go.
Because then you have something that actually fit your needs, and doesn't bring overly complicate architecture to the table. Then you can change and adapt the framework to your need much more easily.
Bill,
To address my main concern, you could hit the ground running, in the wrong direction. You then have to fight the tool in order to get what you want.
Although Ayende didn't want to compare, I think some are trying to pull him into a comparision. I think he was simply saying it's heavy. I can agree with him. I used the Winform CAB and felt it was heavy. A whole set of new controls, new attributes, new configuration, with not much more than a 'hands on lab'. I'd get an error and spend alot of time digging in to figure out why, etc... Granted, it could be a very very powerful toolset, but when I went to use the CAB to meet a unique solution, I felt I had to really twist the CAB around and spent alot of time wondering if that was the best approach.
So, I don't know what you want him to prove?
Bill,
"With the OSS stack (again assuming I know the APIs inside and out)"
How is CAB any different in that, now I have to learn the CAB inside and out? The CAB is an API, no different than any other OSS API right?
It's like because you have 'list more items' (rattling off OSS names) that all of sudden it's 'harder' ?
With P&P it's like you get a value meal with a toy you don't want, a side item you don't want - but because it's all in one package, you got it. All I wanted was a cheeseburger.
I'm not saying P&P is wrong though - it's just heavy weighted.
Perhaps a good Automation Guidance Package for your favorite OSS projects would be a good way to address these items:
you want NHibernate,? check yes - web or winform?
you want Logging ?- Log4Net, check yes
you want IoC/DI ? - Windsor, check yes
you get NUnit... (no option!! - lol) - checks to see the 3 above, creates the skeleton.
There, now you have a good happy meal ready to go :)
I just keep replaying in my head what I saw that web app block do, and then fired up Monorail and saw what it does. There is such a big difference here.
Well, that's not really smart to use CAB without SCSF, what were you planning to do with it anyway? Maybe you should have spend some time on reading about those and how people using them first.
We have used SCSF/CAB/EntLib from early betas and you are completely wrong on saying that P&P are making their product in the vacuum, I know lots of companies just like us using the CTPs and giving feedback, it influences the P&P development process and final version has some features that are required in the real world scenarios.
"The P&P team doesn't work with their tools on real applications" is the key. The principles used in CAB are mostly correct, but genericity of framework code leads to un-necessary complication and gives the developer a hard time making it fit specific applications.
Comment preview