I’ve lost count of the number of times I’ve heard software architects and senior developers, after much circumlocution involving IT-governance, Enterprise standards, maintainability, reusability, sustainability, and so forth, come to the ‘inescapable’ conclusion that the new software development project “..will be implemented using EntityFramework/nHibernate/[Insert your choice of ORM here].”

Cue many, many hours of technological sleights-of-hand and hair pullings-out.

Fast forward several days/weeks and you have rising concerns that your process is

• Consuming staggering amounts of memory on the server
• Inexplicably inflating 100,000 unasked-for instance objects into your process space
• Making 5 calls to the database whenever you make what you thought was a simple request for Customer.Name
• Running like a lama

Despite all of this however, your faith remains undiminished.  All these issues will be resolved any moment now, you think to yourself, and you confidently fire off a support request to your ORM software provider, and post a question to your favourite blog-sphere. And sit back and wait.

At this point there is a question I want to ask you, but not just yet, you are not ready and trust me, we have plenty of time.

Soon your phone buzzes and no, it isn’t Sundeep on stack-overflow responding to your query, it’s your mates calling from the pub to ask why you haven’t showed up. Its 6.30pm! Your faith starts to waver, but still you are not ready. Fast forward an hour or two, and you are the only one left in the office, slumped in the gloom, creeping despair illuminated by screen flicker. The cleaner has been and gone, tut-tutting under her breath as she cleaned around you, and you have to resort to  sporadically waving an arm in the air to keep the lights on (sub-text: your brain-time is cheaper than electricity).

But you can do this, you say to yourself, all you need is a triple shot skinny mocha-chino to restore your wavering faith, so you stretch out of your chair and peer out of the window at the Pret across the street, and guess what, its closed. Of course its closed, their target clientele are those nice folks from your IT governance/Enterprise Architecture department, and they’ve looooong since gone home. And to cap it all, the online moderator has closed your question as ‘Not Constructive’.

You sink back in your chair, head in your hands, the rising doubts finally breaking through that surface tension of architectural confidence, and now, now that you are at your lowest ebb, you are finally ready for the question. And the question is this. “What have you done?”

How did you get from “…disrupting the existing market by introducing the next generation crowdFunder app..”, to grubbing about in the tech dumps, endlessly reconfiguring relationships between stock.xml and order.xml, trying to find a freeware Process Viewer download so you can work out whats going wrong, and trying to figure out if array.GetAllCustomerNames() has actually got all customer names, or is just describing HOW it would get all customer names, when it finally gets round to doing it at some most inconvenient time.

Welcome to “should’a done something different with my life”-ville, population: You.

There’s no need to go reflecting on all the points in your life when you could have taken a different turn, and how things might have worked out. It isn’t your fault, you have just become the latest victim of The Golden Hammer, aka ‘when the only tool you have is a hammer, then every problem looks like a nail’. The hammer, in this case being the big-beast third party ORM/Framework mapper that’s now proving to be the bane of your existence.

Ok, so I’m being deliberately provocative. The reasoning behind the decision of my ‘straw man’ architecture board could also be described as ‘the devil you know is better than the devil you don’t..’. An in large corporations, it can be more cost effective to spend as much development resource as necessary on a problem, rather than re-convening a meeting of far-flung architects to try and explain why a totally different architecture should be used in a particular instance (believe me I’ve tried). However, when the context is a small company or startup, the value-proposition is very different.

When those proto-hammers first came out, we were all excited. So we don’t actually have to write any code to pull our data out of storage etc? This product will do it for us? All we have to do is plug it into our new/planned system? Brilliant.

However it soon turned out that the product(s) had limitations whenever you wanted to do something out of the ordinary, so newer and newer versions were released by the vendors, with more and more complicated rules and syntax, and so we began the long, long scramble up Mt. Incomprehensibility. So now, YES you don’t have to write any code to access/update your data store, which is good because now ALL your time is being consumed wrestling the big beast ORM into your system. And IF you do succeed, what have you ended up with? You’ve spent just as much, if not more, development time and resource, and you have created a sluggish, non-optimised, gloriously opaque system with a slumbering uncooperative beast at its core, AND you have now introduced an embedded dependency on a third party product that you didn’t need in the first place.

“But wait!” I hear you cry..

“..we have an expert that can configure our chosen ORM platform/framework with one arm tied behind his back, so it makes sense for us..”

Well that’s great then, but if you have such a Guru, then the chances are the guru-ness also includes being able to craft superb sql data queries, and excellent code, in double quick time. So why didn’t you just empower him/her to do that, why not make use of that talent? Or where on earth did you find an nhibernate guru that can’t also write great code?

“But..”, you protest..

“..what about flexibility of architecture, we need a framework so we can easily adapt to new requirements from the client..”.

Well of course you do. So are you going to spend hours/days/weeks building out this architectural framework, just in case your client decides in a couple of years that they’d like a specific additional functionality? And when that moment comes, do you imagine you would just make an xml configuration change in your super flexible framework, without writing any code whatsoever, and voila! the requirement is satisfied? When, in the history of software development, has that ever been the case? Ok, it’s probably happened a couple of times in a galaxy far, far away but, I respectfully submit, it’s not very likely to happen to you. When your client does request a change, it’ll be something like

“..could we have a ticking clock in the upper right hand side of the screen, so we don’t accidentally wake up the prospective investor at an inconvenient hour..”

And trust me, no amount of mapping/configuration is going to help you with that.

In the meantime, instead of spending time drumming up new customers, or writing software that will enhance existing customer loyalty, you are future proofing for situations that will probably never arise. For an interesting article on why you shouldn’t be doing this, see http://www.agilebuddha.com/agile/agile-principle-simplicity-the-art-of-maximising-the-work-not-done/

In essence, you don’t have to embrace the whole agile, story-boarding, pair-programming, daily stand-up exercise rigmarole, it’s just surely a good idea not to spend all that time future proofing for scenarios that may never arise, especially as if and when they do, they’ll be different from what you imagine.

Returning to the concept of the Golden Hammer, I’m not saying that EntityFramework, nHibernate, and the rest of their ilk are the only tools in your architect’s toolbox hence their usage, nor am I suggesting that your developer has simply chosen those technologies with an eye to skill-ing up for their next role, regardless of the consequences for your project. What I am suggesting however, is that before you bang that ‘nail’ with that hammer, you might be best advised to take a step back and reconsider.

So, with all that said, what are your other options. You could handcraft ALL the code yourself, or you could get an off-the-shelf code generator that just cranks out enough comprehensive code within minutes to get you started. Now every developer worth his salt will reckon they can write faster, leaner, meaner code than any code generator (and they are probably right), and they are happy to spend hours at home in bed, with their laptop, re-writing the same procedure over and over again, proving exactly that. But as a business, you may want the middle ground, a fast solution that gets the project off and running with a comprehensive code framework, but then allows your developer to easily dive in and customise/optimise/replace absolutely anything they want, to their satisfaction. A solution that does NOT involve bundling unnecessary, sluggish and opaque third party dependencies into your finished system. In other words it gives you a helping hand (quickly) whenever you need it, and then, crucially, it steps out of the way!

A quick search for “Code Generators” in my Visual Studio as I write this gives the following results (results filtered for relevance):

CodeSmith Generator [By CodeSmith Tools LLC]

CodeFluent Entities [By SoftFluent]

CodeTrigger Code Generator [By Exotechnic Corporation]

and many more..

Any one of these should get you off to a good start, an initial investigation would confirm for you which of the many available great code generators best suits your style of working, and avoids the pitfalls described above.

So free your mind from the shackles of ritual, and make significant strides, today.

• Uncategorized