You’re Not Your Data Access

Seems I touched off a bit of a “swirl” with a comment I made on my last blog post:

I think, in general, the .NET crowd overthinks and over-engineers just about everything

I said as much in my MIX presentation, where I basically challenged ASP.NET developers to “embrace their inner scripter” and stop building rockets. I have a fairly strong opinion on this – and I’ll save that for another time – but I think it’s high time to remind folks that there’s a lot more to an application then how you get your app gets it’s freak on with your database.

Good Morning!
I remember watching Fight Club for the very first time back in the thick of the very first DotCom bubble. I was feeling pretty ill that day so I stayed home and watched the DVD, and was pulled in pretty dramatically. One line still resonates with me:

You’re not your job. You’re not how much money you have in the bank. You’re not the car you drive. You’re not the contents of your wallet. You’re not your f******* khakis.

I feel the same way about building software: You’re Not Your Data Access.

When I watched that movie I had just bought a nice pair of $180 Kenneth Cole shoes to wear to a client’s VC meeting, to go with my groovy business-casual Cornflower Blue button down shirt. I clearly remember looking over at my closet – the feeling of fashion sobriety coming over me – wondering what I had turned into (if you knew me then you’d know I don’t like wearing that kind of stuff. I’m happy in a white t-shirt and shorts).

I had this same feeling when I popped my head out of the .NET community just 4 years ago (before I worked at Microsoft) to see what this “Rails thing” was all about. I remember the feeling well – and it was very, very sobering and inspiring at the same time. I remember creating an application in fairly short order with all the requisite pieces put where they needed to be put, with every tutorial urging me to “stop thinking – just build”.

Camaro Programming
The .NET platform is pretty dang powerful. It lets you build your own personal Tower of Babel if you so choose, and it can abstract away the very fabric of space-time if you let it. In short it’s a killer set of tools that any mechanically-inclined tower-of-bableperson would love to use. So naturally it can be very easily abused!

Consider my good friend Eric. I’ve written about Eric a few times before – but in summary he’s my token wrench-head friend that loves his engines and American cars. I lived with this guy for years and he rapidly  filled up our garage with parts and *crap* from every car he’d ever owned. And he could dutifully tell you which part went to which car and what that part did – no matter if it was useless.

Eric built and maintained a hunk of junk 1968 Capri which we used to call “The Crappy”. This thing could drive – and I mean really drive – I think Eric pushed it to 180 mph once on a closed race course. It had that sound that all muscle cars make – the sound that makes your ribs shake and your inner 16 yr old say “coooooolll!”.

The problem was that no one ever wanted to drive in it. It smelled, it was ugly, and it absolutely sucked the gas down. Eric would steadfastly defend his Crappy because “it was the easiest car in the world to work on” and “could blow doors on any production car from any country”.

“Yah but when do you really need to go 180 miles an hour man?”

“When I race dammit”

I don’t need to draw the parallels here. I think you get it.

Let it Go Already
I want to be perfectly clear about what it is I’m saying here, and that is that it’s very, very easy for the geek inside us to whisper sweetly in our ears, saying “this Super Massive Paradigm Shifter will be the biggest application EVAR… don’t mess it up!”. I felt this very sensation when starting … well every app that I ever made.

I don’t like being wrong – no one does. So defensively I’ll be sure to include patterning where I can, making sure to separate out my projects whenever it … seems like I’ll crap for not separating out what I’m doing into another project.

I’ll use enums instead of boolean parameters.

Oh wait, no I won’t.

I’ll be sure to avoid Singletons

I’ll absolutely never use Stored Procedures, I mean seriously never, ever, ever (unless Rob Howard tells me to). Or maybe unless my boss tells me to. I’ll let Jeff decide.

I’ll always use Stored Procedures.

I won’t use NHibernate

I won’t use any ORM for that matter. Seriously – Never.

Well I might use both

I won’t use Code-coverage to tell me anything.

I’ll be sure to use Code-coverage data to tell me everything.

I’ll make sure my method and variables are named properly on Fridays.

Reflection? Not a chance. Unless Rick says it’s OK.

I won’t use Extreme Programming (I’ll be sure to use Lean… whatever that is)

I’ll be sure not to have scrums.

I’ll also be sure not to multi-task.

I won’t use configuration either – hard-coding FTW!

I won’t use static methods

I won’t use extension methods

I’ll keep Native American stereotypes out of my code.

I’ll make sure that all my methods are public and never sealed or internal

I’ll check twice before I use any of these evil keywords.

I’ll also make double damn sure not to use regions in my code – ever.

I won’t use VB (who would?) and I’ll be sure to use C# with great care.

I won’t use Composite Keys in my database

And I’ll be very, very sure to keep away from Norway.

You wake up at Seatac, SFO, LAX. You wake up at O’Hare, Dallas-Fort Worth, BWI. Pacific, mountain, central. Lose an hour, gain an hour. This is your life, and it’s ending one minute at a time. You wake up at Air Harbor International. If you wake up at a different time, in a different place, could you wake up as a different person

Let.

It.

Go.

Summary
Simplicity is beautiful. Simple doesn’t mean hard-coding, it doesn’t mean cutting corners or being sloppy – it means building what you’ve been asked to build, not a rocket to Saturn and most of the time it’s a skateboard to the corner store.

Not every application needs to be stitched together from Codebetter posts and Twitter rants. Focus on what’s important – the experience, not what’s under the hood. You’ll change that quite a few times no matter what you think :).

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

34 Responses to You’re Not Your Data Access

  1. Eric Sabine says:

    The last two paragraphs are brilliant.

  2. dp says:

    Rob,

    You’re right, and my tongue in cheek post is not intended to poo-poo those topics in the slightest. They are, indeed, best practices. I submit for your consideration that, possibly, some over-engineering could come from a “this is how it’s done” response, possibly elevating the dogma over the delivering of business value.

  3. Derek Greer says:

    I tend to agree with your perspective, but I’m not sure its one that can be adopted by most without learning it own their own.

    I think that for many, the road to maturity has to include the phase of over-obsessing and over engineering everything. It is through these experiences that many of us learn what’s worth the effort and how to effectively design applications which are both simple and maintainable.

    Perhaps achieving the ultimate balance can only be achieved by finding a balance relative to where each of us are on our own road to maturity.

    I’m unsure though, I’m still on that road :)

  4. robconery says:

    @dp Loose Coupling, DI, xDD – these are Good Things (most of the time) and come down to practice – not architecture. My post isn’t an excuse to not learn and do your best – it’s more about “keeping it real” and challenging yourself to YAGNI everything – not just your code.

  5. dp says:

    See, this is why the RobCon must be allowed to flourish and flower. I loved this post. It harkens back to Spolsky’s Hammer Factory post: http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12

    So, with this newly found, inspiring information…namely, me not being my Data Access, may I please take it a step further, and suggest that maybe, just maybe, I’m not my Loosely Coupled, Dependency Injected, Test Driven, Behavior Driven, Domain Driven, ALT DOT everything driven practice either?

  6. Fregas says:

    I agree with everything except this statement:
    “stop thinking – just build”.

    This is not good. Writing software IS thinking and requires thinking. Knowing how NOT to over-architect is part of good thinking. In buddhist terms, its the “middle way”, not over designing, but not under designing either. Building stuff without thinking isn’t the answer. I know you weren’t promoting spaghetti code or developing without any attention to design, but that statement makes it sound that way.

    Other than that I agree we get hung up on data access and other types of plumbing.

  7. fregas says:

    I agree with everything except this statement:
    “stop thinking – just build”.

    This is not good. Writing software IS thinking and requires thinking. Knowing how NOT to over-architect is part of good thinking. In buddhist terms, its the “middle way”, not over designing, but not under designing either. Building stuff without thinking isn’t the answer. I know you weren’t promoting spaghetti code or developing without any attention to design, but that statement makes it sound that way.

    Other than that I agree we get hung up on data access and other types of plumbing.

  8. mark says:

    do you sell soap?

  9. Andrew says:

    I had the same “Rails” moment a few weeks back when I decided to spend some time with it for the first time.

    In the .Net world it seems that we over complicate whatever we are building about 99.9% of the time.*

    Stepping away from .Net was one of the best things I ever did, because I think it’s made me a better .Net developer. I’m not so caught up in the process anymore, I’m more concerned with the end product. I also fully agree with your summary about simplicity not being about cutting corners, I think that’s the thing most people forget.

    *WAG brought to you by my butt, which is where I pulled the number from

  10. Jason says:

    I like the point of the article, my only concern is that people “who are their data access” won’t be convinced to change their ways. Yes, simplicity is beautiful, but where is the evidence to support that?

  11. Mark Nijhof says:

    Hmmm I live in Norway, what to do? What to do?

    -Mark

  12. James says:

    Excellent point well made. Obsession with technology is boring; clarity and focus on solutions is much more interesting.

  13. Nick says:

    Thank you Rob – I often read you and a lot of the people you quoted and have never commented until now.

    Thank you for the perspective.

    You are a breath of fresh air.

  14. Harry says:

    I am totally confused. Should we all write PHP code. If we re-write StoreFront using PHP, it will probably even more fit to your arguments here.
    I hope there is a way to write PHP as frontend, and talk to my backend (over-engineered) code.

  15. Ezequiel says:

    Very funny, great post… the best part “not a rocket to Saturn and most of the time it’s a skateboard”

    :D

  16. Robert Kozak says:

    Rob,

    Wow! I mean WOW! Words fail me. Amazing post.

    I’m speechless.

  17. Melford Frich says:

    Thank you for writing this.

    Sometimes I find the .NET community maddening, though maybe my mistake has been in presuming a single cohesive community.

  18. Phil says:

    Our reasoning behind over-engineering a solution is probably pretty similar to the reasoning your mechanic friend had for going overboard in fixing up his capri, it is challenging and enjoyable. Unfortunately, these aren’t very good reasons to apply a practice or framework to a project for a client or employer. Being a great programmer is about using the right tools for the job and staying within the constraints that you are given. Rob’s approach for the Storefront project was perfect, he had an opportunity to explore the new techniques and technologies that he has learned, and it was on a project where it was approprite to do so. I don’t think the goal of the storefront project was to make yet another ecommerce solution, it was to learn and to teach about the latest trends in software development. It was to add more tools to our toolbox so that we can use them when it is appropriate to do so.

  19. wekempf says:

    Agree or disagree with this post or any of the posts it links to, this one is a classic that everyone should read!

  20. Parag Mehta says:

    @Peter

    “Summary: balance.”

    That’s the key. Neither Over Architecture, nor Under Architecture.

  21. Peter says:

    It’s a subtle point, but finding the exact balance point between learning new things, and for lack of a better way to say it, “choosing to not learn,” is difficult. While I agree with the point, I just want to say that it’s really tough to figure out when you don’t need to learn something. I prefer to err on the side of caution and go overboard on learning. Then, AFTER I’ve tried something out (e.g. learning OO right now and trying not to use singletons/statics, it’s pretty rough,) I can make the decision as to when to follow the rule. But not BEFORE I’ve tried it out.

    If I don’t follow this rule I’m scared I’ll (unintentionally) end up like the DBA advocating stored proc usage for performance gains in mid-2009. Or the guy who asks if using all these extra objects when switching to OO-style programming will affect performance. Or the guy who gets angry when you use ‘advanced C# language features’ like generics because he doesn’t understand them. Or the guy who gives you a blank look when you suggest he take a training course or read a book on a specific technical/framework topic (yes I’ve gotten this look.) Or the guy who is set on any number of small or large dysfunctions. I’m deathly scared of becoming that guy, on the slow, long slide into Mort-dom.

    So for all of you out there reading Rob’s post, ask yourself: are you in more in danger of becoming the metaphorical mechanic guy with the hot rod that smells like burnt grease, or are you in danger of becoming Mort? If you’re in any danger of being described as Mort, think twice before congratulating Rob on “sticking it to those other guys with those crazy ideas, just ship product and anyway, I’ve only got 7 years left until I retire.” His post probably wasn’t written for you, you probably need to study up.

    Summary: balance.

  22. pete w says:

    Thank you Rob!

    I dont know how many hundreds of “best-practices” articles written by .NET zealots!

    Our job is to use a computer to make someone’s life easier. By constraining yourself in to a specific way of using that computer, youve now limited your abilites to do your job.

    .NET is a great option when I need to integrate with a microsoft infrastructure, but I challenge and .NET web developer to build a standalone web app faster than I can with rails and heroku :)

  23. robconery says:

    Fair point Dante :). I thought about that a lot while writing this – and Kona was defnitely going the “make this SIMPLER” route – and I think that’s OK, the Storefront was a lot about learning patterns and approaches.

    I’ll have more to say on the Storefront stuff in a later post :)

  24. Dante says:

    Thaaaaank you! Finally, someone realistic.

    But isn’t this a case of “do what I say, not what I do”? I have to think about your StoreFront, with the delay to release because of some paradigm shifts to make it cool and hype; or also the *new* ASP.NET MVC thingy, requiring a new shift for ASP.NET devs?

    Still, glad to know there are people like you out there, not only dreamers…

  25. cc81 says:

    Maybe I did try to project some different issues on this post. What I primary meant that to be able to identify the things that does not matter you need to have a certain skill level, you probably have to go through the phase where you over-engineer and fret about the tiny things.

    Because there are things that DO matter a lot and one need to be able to identify them and not mistake them for things that does not matter. So I guess I was mostly talking about those who force a rewrite way to soon because they thought it did not matter really to just put data access-logic in the UI.

    I do know you did not mean that though, you wrote the post on the context of the CodeBetter crowd.

  26. Frans Bouma says:

    Too bad I’m linked in the article as I agree with you completely. (so some perspective about the link about procs: it’s not that I wanted to say I never use and never will use procs, it’s that one should think about why one wants to use them as with every technology used. )

    I find it refreshing that someone wrote an article like yours, thanks for that. :)

  27. robconery says:

    “Burned” by having to rewrite it? Let’s be honest – you’d do that anyway – most geeks do. They look for a reason which is usually “lame data access – dude this guy uses sprocs!” and boom we rewrite it. We *want* to rewrite it because “OMFG this guy wrote this using [currently lame pattern]” which is only currently lame because we dubbed it as such so we could rewrite applications using the new framework coolness.

    “Burned” means you get dropped by your girl/boyfriend for your roommate. “Burned” is when you get fired for a lame Tweet. “Burned” is not upgrading software and getting paid for it – especially when you have a job because of it.

  28. cc81 says:

    I guess a lot of us have been burned by maintaining apps that has been thrown together by people who “just did it”.

  29. Parag Mehta says:

    Excellent Article. While Good Architecture is very important it’s not everything. I am from Joel’s Camp, mostly make it work first then Refactor and apply architectures to it for making project more maintainable.

    I would like to refer this article in the context :
    http://www.joelonsoftware.com/articles/fog0000000018.html

    Although the article is 8 years old, it is still relevant. If you worry too much about architecture you will not get anything meaningful done.

  30. Simon Farrow says:

    I’m know from personal experience that sometimes it becomes more about the new toy than the project. The downside is while the learning at the from of the project is good, the misery at the end of overcomplicating things is awful.

    The simplest appropriate solution.

  31. Bil Simser says:

    Great post, lots of interesting references there. It pinged me with a trackback to the post I wrote in 2004 (gulp) that I really liked spocs. That position has completely changed since being engulfed in the NHibernate Mafia. However, I still think regions are absolute and pure evil (maybe more evil than VB 9 and XML but not sure yet). Thanks for the trip down memory lane!

  32. As always you are here to tell us we are all dumbasses. :-) In your usual down to earth way.

Leave a Reply