A Train of Thought: January 2010 Edition

One of my New Year’s resolutions was to resuscitate my blog.  It’s very obvious that the “conversation” has moved onto Twitter in the last couple years and my blogging output among many others has fallen off dramatically.  Instead of pushing little throwaway blurbs to Twitter and forgetting all about it, I thought I’d try the old way.  So here’s a bunch of throwaway blog comments…

On Entity Framework 4

I think EF4 looks worlds better than EF1 did.  There, are you happy Keith?  I still don’t like EF4 in comparison to you know what, but the remaining issues are much smaller than with the very seriously flawed v1 release.

At this point, from the outside looking in, it looks like something that I could use if I ever got into a shop that couldn’t use OSS tooling or if it’s a project that doesn’t really need a rich domain model.  EF4 is still missing too many important features that my team depends on with NHibernate, but that gap has closed dramatically.  Specifically, if EF vNext supports “rich” POCO model (EF4’s “POCO” support only does anemic domain models and that is important to my team), closes the gap with Fluent NHibernate’s conventions and auto mapping support, and has the right plugin points for interceptors and NH’s “UserType’s,” then I have a real decision to make going forward in regards to persistence.


Context Matters

Well, duh, Jeremy.  I’ve been in a lot of discussions over the last decade about the “best” way to develop software.  I think a lot of heated discussions could be headed off if we’d first lay down the context in which we arrived at our own opinions – and probably stop using absolute terms in any case.  If you’re arguing with me that NHibernate is the wrong tool because you’re writing reporting applications, just say “I write reporting applications.”  And when I say “I think NHibernate is the best tool for persisting domain models,” I should probably talk about that specific context.  And definitely, when you say “Linq to Sql rocks!” you better follow that up with “for applications with simplistic domain models.”

I apparently work in a magic fairy land where my development team is free to choose any tool that we deem best for us regardless of whether or not that tool is bundled into Visual Studio or not.  I also work in a very small team that’s perfectly co-located and mostly staffed with experienced developers so I can happily consider introducing new concepts.  Many of you labor in a world where your choices are are circumscribed by corporate policies or the infamous centralized architecture team.  The point is that what’s best for me may be radically different than it is for somebody working in a typical large corporate IT department that doesn’t allow any non-Microsoft tools.  It’s to the point where I want a new rule in place for any new debates – “are we talking about the best way to do things or the best way we can do things within your specific set of constraints.”  Both topics are interesting, but let’s get the ground rules out first. 

You obviously need to limit your technologies and approaches to your existing context, but don’t forget that can also change your context to better fit the way you want to work.  My friend Rod Paddock wrote an article a couple months back called Can a Fish Use a Bicycle? about how Agile techniques and philosophy are independent of tools and universally applicable.  Rod specifically mentions some technologies that are not normally associated with Agile development.  I’m not going to directly disagree with Rod, but let’s just say that I think Agile techniques work much better in some contexts than others.  Agile techniques work best when the lines of communication between team members are better, so co-locate the team whenever possible and tear down the cubicle walls.  TDD/BDD works best with technologies where it’s easier to isolate little bits of the code – so choose those technologies when you can.  Incremental delivery works best when you’re using technologies where it’s efficient to make a series of small changes to the existing codebases.  If you can, change the way you work to better utilize the tools and techniques.


Oh, and even if you do work within certain constraints, I still think it’s a good thought experiment to consider how you would solve problems if you could use anything.


My tool is better because it has feature XYZ and your tool doesn’t!

Here’s an embarrassing moment from my career.  Like many, many VB6 developers I had a big inferiority complex towards the “grown up” Java developers and was studying at night to learn Java.  I immediately saw that Java didn’t have an equivalent to the old ADO Recordset* object and I couldn’t imagine how you could possibly code efficiently without it.  I even tried to write a Recordset equivalent for a couple nights.  Sounds pretty silly, doesn’t it?  I equated “productivity” with using that stupid old RecordSet object in VB6 and didn’t pay attention to the idiomatic ways that the Java guys got things done.  I should have been learning (early) Hibernate or TopLink and putting time into grokking OOP instead of complaining that I couldn’t do the old data centric style of development I knew from VB in Java.

I see the same kind of shortsighted comparisons coming out over the past couple years.  The Entity Framework people are saying that EF is better than NHibernate because it has a designer cooked into VS.Net.  I would completely scoff at that because I don’t believe designers offer any productivity gains over the code centric way that I model and configure persistence.  On the other hand, I’d say that I think NHibernate is far superior to Entity Framework because Fluent NHibernate is far more powerful than EF’s new Code Only configuration model – but the mainstream .Net world still equates productivity to visual tooling integrated into Visual Studio and wouldn’t buy that argument.  Either way, there’s danger in comparing two tools that use different mechanisms to achieve the same ends.  Same thing applies to the “but MVC doesn’t have controls / data binding!” line of thought.


* For you young’uns that grew up with .Net, in the VB6 days we didn’t have ORM’s or anything like the System.Collections namespace and we used the ol’ ADODB.Recordset class as a Swiss army knife in our code.  It worked as well as you’re imagining it did.


What is it that they know that you don’t know?

When you see somebody clinging hard to a position that you think is absolutely nuts, and you don’t think the other person is a bozo, you have to find out two different things:

  1. What does he know that I don’t know that leads him to that position?
  2. What doesn’t he know that would change his seemingly crazy position?

Note to self, I should probably follow this one a little bit more.


“Same ol’Stuff, Different Name”

Last year my son and I went up to Ft Worth to visit my favorite uncle who’s spent thirty odd years working in software as a systems analyst.  He said something to me that absolutely shook me to the core.  Paraphrasing, he said that “the problem with getting older is it’s harder to grasp new ideas.  More experienced people will tend to try to understand new ideas by their similarities to their old ideas, and by doing this they completely miss the parts that *are* different.”  Think on that one for a minute. 

I’ll give you a couple examples.  I, and many other experienced TDD practitioners, blew off Behavior Driven Development for a few years because it really just seemed to be “Test Driven Development done well, but with ‘should’ instead of ‘assert’ in the tests.”  I was wrong.  I only saw the similarities to what I already knew and not the very important, but subtle, differences that make BDD shine.  I don’t particularly follow BDD to the letter, but the way BDD shifted test/spec organization to “context” instead of TDD’s class/method-centric organization is hugely advantageous in practice.  My development work has gone better since I finally saw the differences from TDD to BDD.

Another example.  I worked with an older fellow several years ago who told me that he finally got TDD when he realized that “it was just what I’ve been doing all these years with a new, fancy name.”  I don’t know what “the way he’d always done it” was, but he most certainly was not doing Test Driven Development in any way that actually helped him build software.  He was not using tests to drive the design.  He was putting a pretty elaborate design together first, then trying to retrofit some integration tests on at the backend.  It worked as badly as it always did.  He completely focused on the word “test” and missed the “driven” part that would have helped him design a better code structure.

I came behind this guy and tore my hair out trying to extend and reshape that codebase for the next year.  My team’s efforts were very clearly frustrated and retarded by the poor design that could have been prevented if the previous team had understood Test Driven Development.  I wrote about my experiences with this system and the very real pain points we hit as the basis for Orthogonal Code


Why you should learn “Shiny Objects”

There’s a huge undercurrent of cynical grumpiness in software development about new things.  You know what I mean, the ol’ “bah, that’s just the new shiny object the ‘cool’ uber elitist geeks are playing with.”  You can’t learn everything in software and we’re terrible about self identifying way too much with the tools we do use, so it’s easy to get defensive when people start to get excited about something that you don’t use.  While chasing every little fad will definitely make you tired, I think you really, really need to pay attention to the new shiny objects – especially when smart people you respect are the ones being excited.  My point is, if you see a lot of people speaking very favorably about a new thing, pay attention to it because it might be something that’s advantageous to you. 

I’ve largely ignored Git and distributed version control systems over the last couple years.  After all, Subversion wasn’t really my pain point and I still don’t think the move from SVN to Git is fractionally as big a deal as moving from VSS or CVS to Subversion was 5 years ago.  However, we started using it for FubuMVC development and now that I’ve gotten just a taste of Git’s branching workflow I can see obvious advantages.


Lots of Useful Systems have been built without your “Shiny Object!”

I see some derivation of “lots of good, useful systems have been built without TDD/SOLID/CI/BDD/DDD/XP/OOP/Mock Objects/etc!”  Well, yeah.  You can build a system with almost any Turing complete language, but so what?  Do you still use Fortran?  Using that line to blow off a new or different idea is completely unproductive.  The real question is “could using this new thing help us do even better?”  The most successful project I worked on did not use any of those acronyms, but I fully believe that if I had to do that little project again today I could build it much, much faster with fewer resources and much less stress.  Success was good.  Success with lower stress would have been much better. 


Aha!  Your Shiny new object is not a Silver Bullet!

“Silver Bullet” is the most overused phrase in all of software development.  Ha, ha, you use TDD and you still have some bugs/design flaws, therefore TDD isn’t a silver bullet and I won’t use it!  No, you’re not going to get a 10X productivity gain from any tool or technique, but a 5-10% increase in productivity is a worthwhile investment in my book.  At this point, if you use the phrase “well, it’s not a Silver Bullet” you’re either being sloppy in your thinking or just very cliched.


Diversity in Our Ecosystem is Good

I’m seeing a lot of people in the .Net community moaning the fact that there are just too many darn tools out there that seem to do the same thing.  Our FubuMVC project in specific has been blasted as just “Not Invented Here” syndrome gone amuck.  IoC tools are everywhere and they *do* have a lot of overlap (for the record, StructureMap was released before all the others – but I mostly neglected it for years).  It’s an absurd argument.  Diversity is good.  I’ve taken features from AutoFac and Ninject before and even one from Unity a couple years back.  Windsor is adding a pretty significant diagnostics feature inspired by StructureMap.  Diversity is a good thing.  More people innovating means more innovation.  Bad ideas get junked when better ones appear.  Not every system is exactly the same.  Different approaches to the same old problems can frequently lead to new opportunities. 


Why don’t you just jump ship to some other platform?

I hear this one all the time and it’s a good question in a way.  I like and/or use very, very little of the tooling from Microsoft beyond the CLR, C#, and the bare bones of Visual Studio.  I’m unapologetically a “Fowlbot” (arguably “ALT.NET” is simply the moniker for people who share roughly that same set of preferences and happen to work with .Net) and I have a certain aesthetic to software development that’s completely different than the prevailing philosophy of mainstream .Net.  I started this section, but I don’t particularly have a great answer other than inertia.  Switching to Java isn’t an answer (coding in Xml) and I haven’t particularly had opportunities to move to Ruby or Python.  I’m very entrenched with OSS development in .Net and our customers really want tooling in .Net as opposed to Ruby.  I do think there’s been a lot of improvement in the .Net space over the past three years that’s even unique to .Net.  Our OSS tools are improving dramatically (finally) and it’s kinda fun to be a part of that. 

Okay, how about this one:  I’m very happy with what I’m doing at the moment.  Let’s call that good enough and move on…


Let’s shelve WebForms v. MVC for now

I think the WebForms vs. MVC (paradigm here, not ASP.Net MVC) argument has exceeded its usefulness.  I think there’s plenty of misconceptions from the WebForms world towards MVC that could be dispelled (how to do screen synchronization without databound controls, why it’s more than just the testability concern where MVC shines), but all of the real arguments both pro and con are out there for anybody who cares enough to use Google to find them.  We’re at the point where I think everything’s been said and written.  I really don’t see people with entrenched positions changing their mind at this point, so can we put this argument on the backburner permanently and just agree to disagree?  Let’s put the energy we’re wasting arguing with the pro-WebForms folks and put it into making a better MVC ecosystem for .Net.  Besides, there are so very few examples out there on the web that even show how MVC can be productive.  Go fill that gap and leave the WebForms people alone for now.


“Lazy loading can destroy performance”

Saw this statement while doing research for this post from somebody in the pro-EF camp who was apologizing for EF1’s insane strategy for “lazy loading.”  Guess what?  Sometimes not doing lazy loading can destroy performance.  Case by case basis, folks.  To all you EF folks, you’ve just entered a brave new world.  You might want to learn from the experiences of the previous ORM tools – and understanding when and where to use lazy or eager fetching is key.

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 Ranting. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller


    That’s MV “P” with WebForms, and I’ve been there, done that. If you absolutely *have* to work with WebForms it’s the best option you’ve got, but it’s nothing but a fancy hack.

  • http://gaiaware.net Stian Solberg

    Here’s another viewpoint on the WebForms vs MVC discussion:

    “MVC on ASP.NET without ASP.NET MVC”

  • Brian H

    The part on context is KEY to any discussions and I am glad to see that people are recognizing it.

    RE: Visual Tooling
    Again, I think context here is important. Visual tooling helps with the learning processes. It makes it easier for noobs to grasp the larger concepts without getting wrapped up in the details. Eventually once we have grasped the larger concepts and are ready to be concerned with the details we can drop the visual tooling as needed.

    Visual tools make it easier to start using productivly (not necessarily optimally) more quickly. That is important to me when I want to learn about a “new shiny object” but still need to balance that against business deadlines.

    The lack of visual tools doesn’t mean I won’t ever make it to something like nhibernate, it just means it will have to wait until my “actual pain” with the current solution is greater than the “perceived pain” of learning a new solution.

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


    I’m very clearly challenging the idea that visual tooling is the most productive way to do things. Yes, I think you should use the right tool for the job, but that tool isn’t visual tooling for me.

    It’s not a split dichotomy between “use a generator to make it all for me vs. write reams of tedious code by hand.” You *can* choose coding techniques that require less effort.

    I’m certainly not advocating any kind of “real developers code in NotePad without frilly toys” masochism.

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

    Overall a good article, and the kind of balance thinking that we need a lot more of. However, I do have one bone to pick.

    You encourage others not to dismiss “Shiny Objects”, especially not just because they are not “Silver Bullets”. Yet you have dismissed virtually the entire realm of designers and other visual tools, and in quite a derisive manner. You assume that “the mainstream .Net world still equates productivity to visual tooling integrated into Visual Studio”, which is essentially equivalent to “visual tools are not Silver Bullets so I won’t use them”. No, most visual tools will not give you a 10x productivity gain, but even a 5-10% productivity gain is a worthwhile investment, don’t you think? If a designer or other tool can write code faster than I can, that’s worth something; even IF the output is not exactly what I want, there is a good chance that I can fix the output of the generator faster than I can write the entire thing from scratch. Obviously this is dependent on context and the particular tool we are talking about. But I will say that, although I am perfectly comfortable coding LINQ to SQL or NHibernate mappings or even WinForms code by hand, I would be foolish to deny myself the use of the available tools that can make me even more efficient with those technologies. I thought that’s what ALT.NET was all about: using the right tool for the job regardless of where it comes from or whether or not it is endorsed by anyone.

  • http://www.corebvba.be/blog/post/The-advantage-of-using-BDD-over-TDD.aspx Tom Janssens

    “The advantage of using BDD over TDD”

    Hey Jeremy,

    Nice article… IMHO you might have missed a few vitals on BDD, so I started writing a comment, but since it became to big, I just posted an article on my blog about this (see the link above).

    Keep those articles coming please !!


  • chris

    nice one….hope the positive comments here spur you on to start blogging more again. it’s always a good read

  • Doug Wilson

    Much appreciate your return to Blogging! I haven’t really been able to embrace twitter’s real-time nature and thus haven’t been able to see the value others seem to be getting out of it.

  • Alvaro Oliveira

    Very nice and clean post.

    I do agree with your point of view.

    I like the idea of doing what you know and try to improve it, as opposed to, criticize what you don’t know, just because.

  • http://kevinrodrigues.com Kevin Rodrigues

    “More experienced people will tend to try to understand new ideas by their similarities to their old ideas, and by doing this they completely miss the parts that *are* different.”

    I suppose this is a natural human tendency. When we have experience, we tend to become more rigid in our understanding. When a new idea strikes us, we tend to compare it with the old and ignore a lot of the features in it.

  • http://jarrettmeyer.com Jarrett

    As long as you don’t fall into the trap of… mocking is bad because I don’t want to learn it; TDD/BDD is bad because I don’t want to learn it; DDD is bad because I don’t want to learn it; MVC is bad because I don’t want to learn; unit testing is bad because I don’t want to learn it; NHibby is bad because I don’t want to learn it… I feel like there’s more of those barriers to break down than anything else.

  • http://awkwardcoder.blogspot.com/ Awkward Coder

    Good to see you back…

  • http://sharemyp0int.blogspot.com Moutasem Al-awa

    One thing only makes me always read the posts in this blog, its all about simplicity. Man its very important always to get everything to its basics and all of the arguments in your post says at the end there is no wrong and right cause it depends on your case and project and constraints, so too many factors would judge whether you are doing the right thing in the right situation.
    Bottom line is try to know as much alternatives and technologies as you can so when you are at particular situation you can chose the most fitting thing.

    Thanks for the post :)

  • http://petesbloggerama.blogspot.com Peter Bromberg

    This is insightful since it seems even “Mr. Asp.Net” Scott Guthrie recently felt the need to weigh in on his blog ab0ut the WebForms / MVC controversy.

    But the bottom line for me is that if you have an open mind, its not a controversy. It’s about measuring real world developer needs (get the job done, get paid, and go home to your family) against the desire to improve one’s coding paradigms. Your sage comments are appreciated.

  • Shane Courtrille

    Thanks for this one Jeremy. I for one do not welcome our new Twitter overlords. If I had seen those individual lines from you I wouldn’t have gained anywhere near the insight I did by the follow up you did here.

  • http://www.codeofrob.com Rob Ashton

    This is a blog entry I can get behind – delightfully neutral, balanced and well thought out :)

    RE switching platforms – pretty much sums up how I feel at the moment, loving what I’m doing and so what if I’ve ended up using pretty much every alternative tech there is in my quest for better code, I’m loving the platform and until that changes I won’t be jumping ship.