There are Two Types of Developers

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).

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • amita sexana

    MS Access Repair Software
    access password recovery
    Access Password Recovery Tool
    MS Access Password Recovery
    Excel Recovery
    download free key logger
    Access Password Recovery
    Chat Archive Recovery
    Database conversion software
    Excel file repair
    Data Recovery Tool
    Web Hosting
    Data wiper software
    Digital camera photo recovery software
    Disk Recovery Software
    Data recovery software free download
    Database Converters
    Free Keylogger
    Excel Files Recovery
    MS Access Password Recovery Tool
    Excel Recovery
    free keylogger software
    Floppy Recovery
    Excel Repair Software
    How to Repair Corrupted Excel Files
    recover msn password
    Excel recovery Software
    Floppy Disk Recovery
    Windows Data Recovery
    Keystroke Logger
    Hard drive data recovery
    Recover My Excel Files
    Windows Recovery Tools
    IE Password Recovery
    IPod Recovery
    Key logger
    Excel Recovery Tool
    download a free keylogger
    keyloggers free
    keylogger freeware
    Keylogger Spy Software
    keylogger software free
    keystroke capture
    Keylogger
    Recovery Password
    free keylogger downloads
    best keylogger free
    msn password recovery
    Free Download Outlook Express Password Recovery Software
    password finder
    Keylogger Software Download
    Password Recovery
    password recovery software
    password recovery software free
    pen drive data recovery software
    Pen Drive Recovery
    PowerPoint Repair Tool
    Chat Recovery Software
    Recover Excel Software
    Fix Excel files
    Email Recovery
    Mobile phone data recovery software
    recovery for excel
    Repair Excel Files
    Advanced Excel Repair
    Data Recovery Software
    Sim Card Recovery
    SIM Card Data Recovery
    Key logger software
    downloadable keylogger
    download keylogger freeware
    free invisible keylogger
    data recovery
    Download Free Keylogger
    keystroke recorder
    software keylogger
    remote key logger
    SIM card recovery software
    SIM card data recovery software
    Backlinks Checker Tool
    remote keylogger free
    Spy Keylogger
    USB drive data recovery
    Free Backlink Finder Tool
    datarecovery
    Recover ZIP files
    keylogger
    Data recovery software for NTFS
    Recovery Format Data
    Partition recovery software
    SEO
    Backlinks Checker
    Mobile Phone Sim Card Recovery
    Word File Repair Tool
    data recovery services

    Thank you for you to tell us more interesting information, Thank you

  • Matt Poland

    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.

  • Christian Duhard

    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?

  • IgnorantUntilQuestionIsAsked

    Excuse my ignorance here, but what is NIH?

  • http://www.codebetter.com/blogs/glenn.block Glenn Block

    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.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @Glenn,

    If you’ll get over the fact that I implicitly criticized Prism, you might see that I did cast doubts on the viability of my NIH approach.

    @John,

    Ditto above.

  • http://codebetter.com/blogs/glenn.block Glenn Block

    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

  • http://devlicio.us/blogs/christopher_bennage/ Christopher Bennage

    “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).

  • http://johnpapa.net John Papa

    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.

  • http://www.neverindoubtnet.blogspot.com/ Ward Bell

    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, http://neverindoubtnet.blogspot.com/2009/09/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.

  • woan

    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…

  • http://www.commongenius.com David Nelson

    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?

  • http://www.blogcoward.com jdn

    “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?

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @David,

    If you have any, and I do mean any repetitive code in your model classes to call “propertyChanged()”, I call that an unnecessary headache and noise code. I did it by making the binding itself more intelligent to know to message the other bound elements when there’s a possible change. My properties turn into just a straight up get/set.

    I would allow you to argue with me that an AOP solution might be fine, but a base class or helper? Not good enough in my book.

  • http://www.commongenius.com David Nelson

    “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?

  • http://www.thefreakparade.com Nathan

    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.

  • http://theruntime.com/blogs/JayKimble Jay Kimble

    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

  • Jeffrey Odell

    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.

  • http://wekempf.spaces.live.com wekempf

    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.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @Tony,

    Good point, but the difference is as developers we have more ready options to drop kick something we don’t like and build our own stuff or at least go looking for other things that fit our vision of how it should be.

  • Tony

    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”.

  • http://www.chrisholmesonline.com Chris Holmes

    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.

  • http://www.bluespire.com Rob Eisenberg

    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.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @Brad,

    StoryTeller is very atypical in terms of its screens. I’m using it for sample code for the shell and screen navigation, but not so much for typical MVVM type stuff.

  • Brad

    @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. :-)

  • http://chadmyers.lostechies.com Chad Myers

    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.

  • Stephen Smith

    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.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @Brad,

    I have my own hand-rolled tooling for screen synchronization that gives me data binding like functionality without the INPC headache. It isn’t that hard to bypass a lot of WPF and inject some testability. The biggest thing I need to stop messing with is trying to avoid XAML.

    The layout system in WPF rocks, that’s enough reason to use it for me.

    How’s that for some serious NIH?

  • Brad

    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.

  • JustAnotherDeveloper

    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 :)

  • Steve Py (Squab!)

    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.