How Do *YOU* Think About the Problem?

Every day I have a bus commute in and out of Manhattan from Staten Island that takes anywhere from between 45 minutes on the low side to about an hour and a half on the high side (well, that’s not entirely accurate—I’ve had some commutes that have taken over three hours, but fortunately only when there’s some kind of horrible auto accident that gums up the works pretty badly).

To make productive use of that time, I write code on my laptop, catch up on some reading, nap a bit sometimes (I’m getting old, you know!), and mostly listen to podcasts.  I also draft blog posts as I’m doing right now with this one 🙂  The other day I was listening to one of the many podcasts that I subscribe to in order to fill this 2-3 hours every day and I heard an interviewee say something that struck me as being both seemingly obvious and yet also profound:

In order to work effectively [in software development], its important to select frameworks written by people who think about the problem in the same way as yourself.

Shared Values –> No (nasty) Surprises

On its face, this seems like pretty obvious advice to me.  If the author of a framework you select to build atop shares a similar ‘technology world-view’ and mental model of the problem-space as yourself, then its also likely that you will share a similar value-system re: what’s important in good software and what’s not, how to extend and grow software atop a framework, the best way to implement solutions, and more.  All of this commonality of value-system brings with it certain intangible advantages, probably chief among them being a feeling of sort of ‘being in the head’ of the framework authors – a feeling of having found a kindred software development ‘spirit’ in the framework’s author(s).

When this happens, you often find that the framework behaves “the way you reasonably expect it to” and rarely will its behavior significantly surprise you (except perhaps pleasantly!).  Methods and classes in the framework are found pretty much “right where you would expect them to be” because that’s similar to where you would have put them yourself had you written the framework code.  The framework is extensible in just the right places (and in just the right way!) that you need it to be because you and the author share a commonality of values leading to similar design decisions in software.

I’m obviously describing the ideal case where you find a framework that perfectly suits you.  In the real world this rarely if ever happens in quite this way because the only way to ensure this to be true would be for you to have written the framework yourself of course.  But I bet we can all relate to having worked with frameworks and technology that shared our value system more than others.  And we can all also acknowledge that there is a significantly reduced friction when working with those frameworks authored by those who share our underlying value system and increasing friction from using frameworks and technologies whose underpinnings tend to diverge from our values.

Did I Ever Think My Choices Through This Way?

This certainly makes a lot of good sense to me (and hopefully you as well), but I confess to never having really thought about it like that on a conscious level.  Certainly there have been those technologies and frameworks that I have used in my work that come closer to ‘fitting me like a glove’ than others, but I never really stopped to consider that it might be an underlying difference of world-view that was at the root of much of the friction I have experienced with some of these things at varying times in the past.

So I began to wonder to myself whether I was perhaps applying this decision-making process on a subconscious level.

This Isn’t Another WebForms vs. MVC Post

No, really.  Its not.  I don’t think the choice between ASP.NET WebForms and ASP.NET MVC comes down to “A is better than B” or “A is for people who know WTF they are doing and B is for idiots who can’t program their way out of a paper bag” or “A is for people who care about the quality of their work and B is for people who want to just get the job done fast and go home”, and I certainly don’t think it comes down to “A is a car and B is a motorcycle” as has been suggested by others in the past (an interesting if somewhat confusing metaphor IMO).

If we look at the choice between WebForms and MVC through the lens of which one best fits my ‘world view’, then it becomes easy to see why I would say “I will never again (willingly) build another WebForms application as long as I live.  Period.”  Its got nothing to do with the commonly-offered decision points like some or all of the following:

  • Is the project something quick as a proof-of-concept vs. something that I (or anyone else) will be maintaining long-term?
  • Is it forms-over-data vs. something with a richer UX than just query-update-save (with an occasional delete sprinkled in there for fun)?
  • Is it a small departmental app vs. an enterprise or public-facing site that needs to scale?

None of these ‘pivot-points’ are remotely useful to me in deciding which of these two frameworks to choose because both WebForms and MVC have perfectly capable and arguable reasons why they are the best answer to each of these potential decision-points, making these criteria useless to me as discriminators.

WebForms Through Different Eyes

But looking at WebForms through the eyes of thinking about the people behind it either sharing my value system or not makes it immediately obvious to me why I have never liked WebForms, always found the interminable Page-Postback-Lifecycle craziness opaque, dense, and impenetrable, and constantly struggled with it (even in later years when prevailing wisdom took hold and most reasonable people began to find ways to shoehorn WebForms into semi-manageable Model-View-Presenter patterns to alleviate at least some of the pain of the platform).  Put simply: ASP.NET WebForms is the brainchild of people who do not share a similar value-system/world-view as do I and this mismatch is at the core of why I always found that platform so frustrating to work on.

This isn’t a value-judgment about WebForms in any way.  No, really.  Its not.  Whatever I feel about the frustration that I have experienced in interacting with the WebForms platform over my career, the software engineer in me absolutely has to marvel at its technical implementation even as I try to keep myself as far away from it as possible for the foreseeable future.  Finding a way (any way!) to (semi-)effectively project the appearance of statefullness in an inherently stateless context (HTTP request/response) is an amazing technical feat (imperfect though it is in its implementation).

But at the same time, it doesn’t align with my mental model of the web at all.  And that inherent difference of world-view is at the core of my troubles with working with WebForms.  Yes, I can (and have!) learned the WebForms framework, but the underlying feeling of “something just ain’t right here” never goes away, no matter your knowledge of how something works.

MVC For Me

While there are probably all kinds of things I would do differently were I building the ASP.NET MVC Framework for myself, those technical differences don’t matter to me in the end.  Because in the spectrum that runs from ‘shared mental model of the problem and the way to build a solution’ on one end and ‘completely different set of values at the core’ on the other, MVC is much, much closer to aligning with my own mental model than WebForms could ever be.

This is fundamentally why I don’t care if the MVC Routing engine has been ported to WebForms so URLs needn’t any longer end in .aspx or reflect their folder paths on disk.  I don’t care if WebForms has introduced ‘deterministic client id values’ for DOM elements to make it easier to work with javascript libraries like JQuery and others.  None of these are remotely appealing to me because I think the underlying problems for me with WebForms still remain after all of these ‘bolt-ons’ are added to the platform: the friction between my own mental model of the problem (‘writing web applications’) and that of the authors of the WebForms platform are still just as front-and-center as they have always been.

Contrast that with the approach used to build the ASP.NET MVC framework and you see a preference for interface-based contracts between classes, extensibility hooks at many, many more locations (though still perhaps not all), an explicit INTENT that someone would wire an Inversion-of-Control Container into the MVC infrastructure, and all kinds of other things that just fit more closely with my own mental-model of the problem space and the value-system that I bring to engineering my own software solutions.  Again, ASP.NET MVC is hardly perfect, but its much closer to my value system than WebForms (even if implemented in an MVP pattern) could ever hope to be.

This isn’t an Entity Framework vs NHibernate Post Either

No, really.  Its not.  Honest.  But the reason I would choose ASP.NET MVC over WebForms is the same reason that I would choose NHibernate over the oft-maligned Entity Framework: one of those O/RMs matches my own mental-model of the problem space better than the other.  And just as with WebForms vs. MVC, this choice isn’t really made based on having performed the kind of feature-by-feature Pros and Cons comparison that Ben Franklin (and, later, others) typically champion as a way to make an informed, logical decision.  This choice transcends just about any feature or capability that Entity Framework might have to offer me at this time (or for the foreseeable future).

Notwithstanding some of the very valuable and powerful features coming to light in EF4 (really just v2 of course), EF was built by a team who seems to believe strongly in the following value system (admittedly reverse-engineered and inferred by me from the various design choices they have made along the way):

  • applications exist primarily to manipulate data (CRUD is the purpose of much enterprise software systems and most business rules can be expressed as database constraints)
  • a consistent enterprise-wide data dictionary is the best way to solve enterprise-wide software challenges (e.g., with enough tooling, foresight, and upfront planning its possible for the enterprise to agree on the definition of “the one, true customer entity” that can be reused across the company in multiple software systems)
  • the best way to manifest that enterprise-wide agreement on data/entity concepts is in an abstract entity model that can be reused and projected across many different software projects and for many different purposes
  • the long-term value of enterprise software is in its data rather than its codification and enablement of business process, rules, and constraints that govern legitimate interaction with that data
  • data in a database retains its value long after the software that understood how to interpret that data and enforce consistency rules around it has been removed from the scene over time
  • the value of data is given primacy over the value of the software that interacts with it

Those Just Aren’t My Values

Notice none of those above statements about EF are about any specific feature EF might have (or not).  Its not about whether it supports transparent vs. explicit lazy-loading.  Its not about whether Foreign Key values are exposed by the model or not.  Its not about whether (or how well) it supports POCO classes and persistence ignorance (let’s not mention the whole IPOCO interface and the hilarity that ensued).

Instead, its about the mental model of the problem space that was in the heads of the software engineering team that built it.  When they were making high-order design decisions about the framework, what principles guided their decisions and trade-offs when they had to make them?  And the differences there are the root of the reasons that I have experienced such friction with trying to leverage EF in my work.  My perspective just comes from the far other side of the known universe from where the heads of the EF designers were when they built their ORM.

To be clear, those values listed above that I ascribe to the EF design team are entirely defensible and I know many software developers who share them.  But for the most part, they don’t reflect my view of the problem space (how to build enterprise software solutions that need to interact with data to do work) and so even with the many additional features in v4, EF doesn’t suit me well in re: solving the kinds of problems I face.  It’s not built by people who share my world-view or my value system or my mental model of the problem of building software solutions that must interact with a database.  EF just isn’t for me (or the kinds of problems with which I want to work).

Just as this mismatch between myself and WebForms doesn’t make WebForms a terrible technology, neither does this same mismatch make EF a terrible technology.  But also just as with WebForms not matching my view-of-the-world, neither does EF and that’s the real reason that I choose something like NHibernate over Entity Framework.  Its actually got much less to do with features, pedigree, support, or any other ‘technical’ aspect and more to do with how well it aligns with the way I think about software systems.

But Don’t Features Matter?

Of course they do.  Any framework that matches my mental model of the problem space but lacks necessary features obviously won’t cut it and needs to be eliminated from contention as choice.  But similarly, the framework that does have all the needed features but fails to match (well) my mental model needs to be strongly considered for elimination as a candidate as well (unless of course there is no other choice given other constraints within which you need to make your decisions – in which case I suggest you suck it up and get moving ‘cause crying about it isn’t going to help much).

Don’t underestimate the negative repercussions to productivity, sanity, and (eventually) profitability of selecting a framework that doesn’t match well your view of the world.  Compare features, but also compare what can only be called ‘the driving philosophy’ behind the software you are considering adopting.  Try to find something that both suits your view of the problem space and has the features you need to complete the job.  Otherwise, you’re going to find yourself getting increasingly frustrated as you become decreasingly productive and in that scenario nobody wins.  So choose wisely.

Happy Coding~!