I’m breaking a personal rule by using a banned phrase in my blog today, and I’m going to compound that by quoting an ex-president that this particular amateur historian ranks as the worst American president of the modern era. It’s just like Lincoln temporarily dropping the Writ of Habeas Corpus during the Civil War;) I’m not angry as I write this post, and I’m somewhat sincere about my assertion here. I’m sarcastic about the stored procedure argument only because it’s an annoying broken record argument.
I had an interesting lunch last week with some of my Austin software development buddies. The poor fools, I mean, my friends, were sucked into one of those repetitive arguments on Twitter over the importance or utter uselessness on Twitter the evening before. You know, the one where the anti-sproc guys repeat the old Frans Bouma post (it’s 6 years old for crying out loud) verbatim and maybe throw some extra points in about how sprocs are a huge PITA to TDD or even just test at all and add extra baggage to configuration management? And then the pro-stored procedure guys repeat all the old performance cargo cult stuff and say “I’ve always done it this way, and dadgummit I’m not going to stop now!,” or pull out the old nonsense about how they can much more easily deploy sproc changes instead of recompiling code? (Dude, if you’re scared to redeploy code, you need to improve your software engineering practices in a big way instead of independently modifying your database underneath your code).
My friends wanted to talk about how to be more effective in communicating to other developers about why stored procedures aren’t the best approach in most situations. Specifically, they wanted to know how to reach the developers who were staunchly pro-sproc. My response was simply to say that we should stop arguing with people who don’t want anything to do with what we’re peddling and just worry about the “Coalition of the Willing.”
My opinion here: If you seriously want to continue to place business logic in stored procedures, eschew OOP in favor of procedural code, stay with the Waterfall lifecycle, and refuse to adopt software engineering practices like continuous integration and Test Driven Development – it’s your business and none of mine. I refuse to spend any more of my time arguing with people that don’t want to change the way they do things. I’ve built software with stored procedures, RAD tools, procedural code, data-centric thinking, and labored inside the waterfall lifecycle. I’m completely done with that, and I refuse to work in any company that still insists on building software like that (unless it’s a matter of putting food on the table, in which case I won’t care ‘cause I’ll just be grateful for the job).
Do we really need to waste any more energy engaging with people who just simply don’t want anything to do with the techniques, practices, and principles that fall under the widespread ALT.NET banner? What’s the point? Is it important to convert the greater majority of the .Net development community who frankly doesn’t give a damn about Agile development, Domain Driven Development, or better testing practices? As long as we have a big enough population of developers that we can hire to work in an ALT.NET type of environment and Microsoft doesn’t do anything absolutely horrible that plunges us back into the dark ages, I say it’s enough.
Looking back on 2008, here’s my personal software development lows and highs:
- The EF Vote of No Confidence wasn’t useful, and I’m very sorry in retrospect that I had anything to do with it. Yes, a few good conversations came out of it, but for the most part, did it make the slightest improvement in anything? EF version 1 is a severely flawed tool that will get incrementally better in version 2, but still fall very short of what I want out of a persistence tool even in that version 2.
- I only wrote the original kernel of what has become Fluent NHibernate, but I’m very happy with what James Gregory & co. have made out of that thing. (I’ll be a lot happier when it has a very solid Sematic Model underpinning and gets away from the direct coupling to the hbm.xml. You go Paul Batum!)
- I’m proud of the StructureMap 2.5 rewrite (at a minimum, it’s a helluva lot better than the previous release and I learned a lot)
- I had a blast with the pre-conference workshops at KaizenConf, and I think we shared a lot of new ideas about development
- I think the wave of convention based techniques and real DSL approaches popping up in Windsor, StructureMap, FubuMVC, MassTransit, Fluent NHibernate, and others are going to make .Net development more efficient. I think the .Net OSS community is pushing the art of software development instead of just copying Java or Ruby projects.
Notice a trend? Bitching at Microsoft about EF was basically useless. Building new OSS solutions that made NHibernate easier to use was helpful. Arguing online with anybody on TheRuntime.com was a waste of time. The way that we’re helping each other with efforts like The Summer of NHibernate, Karl Seguin’s Foundations of Programming, and Casey Charlton’s ongoing DDD series was awesome.
Let’s put our first efforts toward making our stuff as good as it can possibly be and helping out anybody who does ask us for help. Let’s still stay usefully engaged with Microsoft and the traditional .Net world, but back off from evangelizing anybody who doesn’t want to listen. Crusades against Microsoft or RAD Programming? Let’s leave that stuff behind in the dark ages of ALT.NET history where it belongs.
Yes, I’m fully aware that I’m implicitly stating that the ALT.NET way is the way – but I’d defend that just a little bit by pointing out that the ALT.NET “way” is very fluid and has changed in significant ways every year. For example, I’ve dropped my old TDD style in favor of a more effective BDD style. We’ve incorporated stricter DDD rules for our Domain Model at work that have added value. My team switched from XP style iterations to the Kanban style of rolling wave development (I seriously think that the Kanban style of continuous flow and adaptation is smoother and easier to use for a team than iterative cycles). My team uses DSL and FP techniques that weren’t even in my vocabulary 3 years ago to great effect. My point here is that we’ve happily adopted new things that have made our development efforts more successful and I have no doubt that even better ideas will pop up next year.
All of the above again proves my larger point here — we should focus more on advancing the art of software development than trying to convert the majority of the development population to whatever it is that we happen to be doing at this very moment. The people who are motivated and interested in coming along with us will come along.
And my friends would like to start a dialogue about how to usefully engage staunchly pro-sproc developers in a useful fashion. I’d be happy to take those comments here as well.