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.
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:
- What does he know that I don’t know that leads him to that position?
- 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.