When you read this please keep in mind that I’m trying to make an observation more than a judgement – and even though I obviously fall in one camp I have a sneaking suspicion that my approach might not be right sometimes.
Here is an interesting taxonomy of developers that I’ve observed for years. Developers fall into two different extremes — or maybe it’s just two different modes of thought (I’m not saying that a person is always one or the other). Some developers can jump right into any technology and find out how best to use it and new ways to twist it and apply it without really questioning the “goodness” of that technology. Others look at a technology with preconceived notions of how it should work and are quick to drop a technology when it doesn’t fit their vision of “good.”
I’ve been thinking about writing this blog post for a long time. What finally kicked it off is that I’m drafting out a book chapter this morning and I’m thinking about how I have and would solve a certain common application dilemma. At the same time I was doing the normal research and found a blog post explaining a solution to the very same problem – but the mechanics involved are somewhat different. Reading the other guy’s blog post at face value and knowing myself, I can easily understand how we came to two different conclusions.
This is what I have. The other fellow started his solution by asking himself “how do I use the existing infrastructure in Prism to solve this problem?” He restricted himself to the patterns and mechanisms in Prism and used a pretty idiomatic WPF type of solution that would be pretty familiar to most WPF developers (a major point in its favor). Actually, “restrict” is the wrong word. What he did was simply to take the tool he had and figured out how to solve the problem using that tool. Quite reasonably.
This is how I want to work. I started by thinking “how do I want to divide responsibilities and how can I make the auto registration of listeners as easy as possible?” I built my own solution and infrastructure that worked the way I wanted. I knew that what I wanted to do was outside the scope of Prism, so I didn’t really consider Prism any farther. I think my solution is arguably simpler and requires less explicit code – but I had to build it myself and while it would be perfectly usable by an ALT.NET developer, would fall outside a mainstream .Net developer’s experience.
I think that I came out ahead in this particular case, but maybe not always. Sometimes the unwillingness to restrict your solution to an existing toolkit can actually hurt you. Maybe your solution turns out to be better, but your investment in the custom solution doesn’t outweigh the gains you made. And quite possibly, your own solution sucks and you should have given in a long time ago. If you look at my StoryTeller code you’ll quickly notice that it is definitely not idiomatic WPF. I absolutely detest the idiomatic WPF way of building applications (data binding, INotifyPropertyChanged goup, bloated XAML, view first, etc.), but I’m coming around to giving in and doing WPF the way the team intended because I’m tired of fighting with WPF and maybe it’d be nice to have other people involved.
On the other hand, sometimes the existing toolkit or out of the box approach just isn’t the best way to do things. At Dovetail we looked at the ASP.Net MVC early on, decided that we didn’t like the way it worked (still don’t), and went off on our own approach which spawned FubuMVC (we did consider Rails and MonoRail as well). Considering we’re working on a long-lived project I think our investments are paying off just fine because I feel that it gives us a productivity boost over idiomatic ASP.Net MVC. In other cases we’ve looked at a third party tool off the shelf and said “we hate this thing, but the timeline is short so let’s just live with it.”
In a future blog post I’m going to answer an email question by thinking about how you make a decision on using an off the shelf component versus rolling your own (hint, it’s not the slightest bit black and white either way).