Too often the internal conflict comes well before we've even "tried" the technology. How do you know you don't like it if you haven't tried it?

However also in the build vs. buy scenarios another key factor is fostering and encouraging creativity. I loathe discussions with "managers" sometimes when they talk about integrating product X with technology Y to make a solution where you don't need to really write any code anymore. That's BORING! Why would I, a software developer, want to give up writing software and creating, to become an application support specialist figuring out how to pound square pegs into round holes?

On a side-note:

I hate data-binding, I hate code-gens. I spend 75% of my time thinking about the problem domain and 25% writing code. I *don't* want tools that shave my 25% down to 10% because the time I spend writing is time I spend *not* thinking so that my mind can start fresh on the next challenge.

Not sure I find fault in either approach.  If the first person used the existing patterns to accomplish and solve the problem in a suitable manner, then I understand him working within the given framework established by the team he is working on.

I had to dig into NHibernate today to learn to create a custom TableGenerator that solved our 'append only' solution.   I worked within the extensibility of the NHibernate framework to solve the problem.  

This was the framework we choose to use because we know the tool has extensibility and a good following to get questions answered, etc...

I would prefer to work within the framework first.  If the framework I'm using in the end doesn't support the requirement, then certainly I'd roll my own.

It's a catch 22 here I believe.  Now.. what I don't like is to hear crap like 'well, we have to use EF and not NHibernate because we can only use MS regardless if it's the best fit or not'.

That makes me cry   :)  

You don't use Data Binding with WPF apps? Wow...

IMO, There is no point in using WPF unless you use data binding. INPC can be a pain, but this small inconvenience is outweighed by the great benefits WPF can bring.

Sure, I would love WPF to be more adaptable to DI, testing, and other things we take for granted with technologies like Rails, ASP.NET MVC, etc. However, WPF is a great tool if you use it how it was designed to be used.

My advice - don't try and put a square peg in a round hole.

Does the discussion of the different approaches form part of a larger discussion of typical project methodology? Would an Agile approach/Alt.NET team's primary focus be on the methodological practices and relationships that will deliver the most business value, early and often, and then given these would then ask the question what is the toolset that will best support those practices? Whereas would a more typical Microsoft/MSDN approach be what are the most powerful/visual toolset available as the primary focus and then we will work out practices permitted by the tools?

I believe it is so much more important to use tools more powerfully than to use more powerful tools.

I have also noticed a 3rd type of developer, or perhaps an archetype that spans both other types:

The "I hate you and I'm going to let you know it in your comment box" developer. There seem to be a small, but vocal minority of these.

@Jeremey wrote: "I have my own hand-rolled tooling for screen synchronization that gives me data binding like functionality without the INPC headache."

Ahh.. very interesting approach. I probably should check out StoryTeller in more detail..

And you're right - the layout system does rock.

I guess the important thing is to find something which works for you and your team. :-)

And one of these days you might even like Caliburn ;)  Seriously, I want to talk with you after I RTW v1.  I want to get feedback from you on what would make v2 better.

Interesting post Jeremy. I know in the last 18 months or so I've gone from "This is what I have" to "This is how I want to work". Driving force: simplicity. Too many tools are just overly complex and make development a chore.

Is this categorizing developers or users? In my experience users react the same way. Some think, "How can I solve the problem with the software as is?", and others think, "Let me file a support request to get this feature implemented".

Your first group is suffering from "If you have a hammer, everything looks like a nail", while your second group suffers from "not invented here". A good developer is going to have to fall into one group or the other as far as his first tendencies are concerned, but he won't let that stop him from exploring the other side and picking the proper solution only after doing so. Like all things in our profession, there's trade offs to be weighed, and no universal answer exists.

Excellent post - although there are, I think, other factors:

1) Are you working "on your own" or in an existing environment?  I'm a consultant and there is value in adopting frameworks and patterns at the client even if I can see rolling my own might be a little faster.  I have to weigh that against the familiarity and comfort level of the developers at the client.

2) What is your history with the framework?  Look - you use frameworks all the time.  One is called .Net 3.5.  You buy into the configuration framework, the collections framework, etc. and, at a lower level, the language implementation.  This is a basic cost/build comparison.  It is the same when you decide to use the Prism pattern for your particular project or not.  Bt if you used Prism 5 times before that make vs. buy decision is much more informed.

3) In a client situation, the backup of documentation like that provided with Prism can be an important deciding factor.  Otherwise you better be prepared to document your approach.

I'm not arguing for one side over the other in all situations.  I've gone both ways.  I’m just pointing out some factors that weight against the ever so slight leanings of the post.

Thank you for submitting this cool story - Trackback from DotNetShoutout

I came here expecting this post to be something totally different than it was (thanks for surprising me).

As we represent the opposite sides of the coin (often), I've wondered what would compel you for instance to build something like FubuMVC..

That said, Im not always the opposite of you.. I do toss out third party solutions ends up having some glaring issue that I just can't deal with.. the diff is that I will probably be more invested than you in the product (although as I am becoming more SOLID in my approach, I'm finding it easier to turn on a dime and scrap something a little easier)

Jay

An interesting question we all struggle with, but it is as subjective as they come. We like to believe that we're always striving for the metaphysically perplexing goal of maximizing return on investment over time where the 'better' approach to any task ultimately provides more (financial) value for a lower cost over the life of the investment than the alternatives. We talk as if our job as programmers in this situation is to apply our hard boiled analytical minds to the hopelessly complex task of predicting which mix of build vs. buy will maximize profit over time for our sponsors, i.e. customers, based on maintainability, developer productivity, etc. And to some extent this is exactly our job if we want to continue to earn a living playing with our magic Legos, but how to strike the balance between the extremes of gluing together standard components with a smattering of boilerplate and writing your own frameworks from scratch is as mysterious and complex a task as writing software itself and has just exactly the same number of ‘right’ answers. The number of factors is immense and depends heavily on the personal values and the creative and technical capacity of the person/people making the decision. Even the relationship of the programmer to his employer is significant. We like to think it shouldn’t be, but it is. I think a fascinating discussion would be about what ‘better’ means to us, admitting we are selfish in our decisions *and* that we honestly attempt to deliver financial value at the same time. Maybe, ultimately, maximum value requires I the programmer take a technical detour to satisfy my OCD need to have things ‘just right’ in this case or that, so that I will be interested and engaged in building this stuff until I’m too old to do so. But how do you decide how far to take that? Utterly unanswerable, of course, but as likely to bear fruit as the original question. As left brained programmers it isn’t always easy for us to admit our approach to our decision making is subjective, and we like to fabricate algorithms to help us decide…  build or buy?  Take this quiz to find out. But algorithms won’t really help, as we will always bend them to shape our predilections in the end anyway.

"I have my own hand-rolled tooling for screen synchronization that gives me data binding like functionality without the INPC headache."

This is so odd to me. In what sense is INPC a headache? Usually you implement it once in a base or helper class and you're done. It actually pretty straightforward to me. What approach are you using in your hand-rolled solution that is less of a "headache" than INPC? Don't you have to end up with an INPC-like mechanism at the end anyway?

“how do I use the existing infrastructure in Prism to solve this problem?”

If you think about it, this is just a 'technology-based' version of 'convention over configuration.'  Given the accepted convention that you use Prism, how do you do X?

Technology Driven

DotNetBurner - burning hot .net content

Zmodyfikowany ListItemFieldMapper z SPG

As a matter of fact I don't have any repetitive code for calling OnPropertyChanged. I created a system which is loosely based on DependencyProperties but without the requirement to inherit from any particular base class. Properties are registered and automatically raise the appropriate event when their value changes. I actually created the system so that I could define read-only properties using expression trees and have them automatically watch the properties on which they are dependent so that they could raise the necessary changed event without the dependent property knowing anything about it; this was something that I felt should have been built into DependencyProperties in the first place.

But the entire solution is still INPC-based. How do you make your bindings "intelligent" enough to know when something has changed without any notification, without introducing unnecessary coupling?

I think there is the third type of developer that just leaves SOLID on the floor altogether and hand rolls a tightly coupled all code behind implementation that looks like old school PHP and calls it a day.

This type also tends to think if it didn't come in the VS box, it isn't worth considering...

I do not think your dichotomy is helpful or fair.

It fosters a smug self-satisfaction among those who imagine they are immune to difficult choices and charter members of an imaginary elite.

Recognize them by their always-pat dismissal of MS technology and their OSS idolatry.

I take your essay to task in a post on my site, neverindoubtnet.blogspot.com/.../man-and-superman.html.

You know how fond I am of you and your intelligence. This essay is not up to your usual high standard.

I don't like the nor agee with that thought there there are only 2 types of developers. I also don't agree that it is better to write your own solution from scratch that gets you exactly what you want when you can simply extend existing frameworks that are commonly used. I am often thinking about who will support the software when I am long gone. Using common practices, technologies, good patterns, and common sense makes a big difference in maintainability.

That said, if the battle is around trying to make a square peg fit in a round hole, of course, go another route. In your example if Prism is not solving the problem and cannot solve the problem even by extension, then go another route.

I don't have an issue with the choice of framework, however I do have issue with the categorizaiton of developers and the idea that one way is far superior to the other.

While I respectfully disagree with you Jeremy, for those who don't know ... I have a lot of repsect for your practices. But I don't see the light in this blog post.

"How can I solve this problem with the tools I have?"

One difference in how we answer, is how broadly we define 'tools': WPF, the .NET framework, my computer.

I think starting out with that question, and taking a narrow approach to what 'tools' are, is often the 'simplest possible thing'. HOWEVER, the next step and the one that was hard to drill into my habit-driven brain is this:

Is this causing me friction? If so, where? Is it the tool? Frequently it is a generalized approached that the tool restricts me to. That leads me to seeking alternatives.

Asking this second question is characteristic of ALT.NET (methinks).

Not to beat on you but I have to agree with some of the sentiments here. I have no issue with critiqueing different approaches and arguing the merits / demerits of each. Fowler is the master at doing this, he doesn't cast blame, he states what he sees as 'Just the facts'

I have a BIG problem with classifying developers into one big pool, and putting thyself on a pedestal. That may not be the intent, but with all respect, it comes of that way. A true educator is not out there to point out misgivings but rather help people aspire to greatness and move to the next level. This is a big problem we have in this industry.

Ask yourself this, what value in this post would be lost if instead of focusing on the negative things you perceive others doing, instead you focused on the merits of your approach.

In short, you get more bees with honey

Something to chew on (or discard)

With respect

Glenn

Jeremy, first to be clear, I am not at all concerned about criticism of Prism. I personally have critiqued the way we did EventAgg and think removing the noise is a good way to go.

My feedback was completely at a meta-level, it would not matter if it was talking about JQuery, Mono or Entity Framework :-)

My critique was on the manner in which you went about addressing your concerns.

Excuse my ignorance here, but what is NIH?

A little late getting here.

I think you know which method is superior Jeremy.

The fact that the first approach may end being better in a particular case, doesn't make it the better general approach to solving problems.

The second approach leads to improvement , and development of better ways to solve future problems. At times, it will lead you astray, but it I believe its the only way to evolve, as a developer, and as industry. Constraining solutions to specific toolsets and technologies, usually artificially, is a dead end road. Isn't this why people are using tools such as Entity Framework over far more mature and sophiticated ones like NHibernate?

I agree with John.

I think the entire crux of the scenario is less about a contrast of being willing to go outside a convention versus being too narrow sightedness to observe an alternative.  I see it more about being disciplined enough to undergo some level of evaluation before you pull a make an important decision.  The maturity of a developer, in the context of being authorized to architect a solution, involves aspects including the ability to understand the essence of the requirements independent of technology and then doing a formal or informal evaluation of the technological approach that best meets the needs.  

The article also hints at some of the considerations that evaluation should incorporate such as: cost to implement, cost to maintain, cost to upgrade, cost to customize, readiness to meet the solution, readiness of industry resources to leverage the technology, etc.  This evaluation should make obvious whether you should buy a product, buy a platform, use a common approach, use an alternative approach, or just build something from scratch.  

I see this less about pigeonholing developers into a certain type and more about the processes maturity of an individual or development shop.  In some cases, this type of decision is not even authorized to an individual developer.