I first learned about Doctrine, the PHP-based database project, in 2008. At the time I didn’t understand why would you need an intermediary layer between your applications and your database, which is what Doctrine is — a “DBAL” — Database Abstraction Layer. Why can’t everything just talk to each other directly? Years went by and though I learned some things about Doctrine and Object Relational Mappers (ORM)s I didn’t have a solid grasp of how to use it in a practical, real-world application. No company thought it was necessary, they preferred to keep all their databases and direct querying because that’s all they knew.
Why make something that’s already complicated even more complicated? At least that was the questions I heard. In actuality, wouldn’t it be easier to visit a foreign country with someone who could translate, speak the language, and knew their way around? A pretty good analogy — that’s what Doctrine does for databases.
For most companies and applications I developed web solutions for, there really was no immediate need for this kind of solution. They weren’t ready to scale this way — at least with their systems and data. Let the web application talk directly to the database, we’ll worry about growth later.
Just getting a company to consider using a database at the time and dedicating time to not only design it, but maintaining it, was quite a hurdle!
It takes time, thought, and real work to set up a database properly and to make sure all the systems in the company that pour information into it and feed information from it are all working optimally, so when you start talking to non-technical people about the importance of their database and how it affects everything throughout their entire system, it’s hard to calculate the costs and the ROI from investing in such improvements. Remember it affects every person who accesses this company’s computer system or website, so it wouldn’t be difficult to help realize the opportunity costs incurred by not acting!
Think of using ORMs for your company like “Database Insurance”
It’s not that it’s very complicated. Your company outgrows its small rented office and needs to find a real building. Without having an ORM to protect your company’s database, it’s like finding out you can’t move — all your valuable equipment is just too big and heavy and if you move it, you will destroy it all. You’re stuck. Pretty inconvenient wrench thrown in your growth plans…
Web Developer:
“Look, CEO Bill, your customers are your most important asset, but understanding their wants and needs is the key to growing profits. That means you need information about them, how to reach them, how to inspire them to act — your information and systems all rely on a database that needs to collect all vital customer, product, marketing, and company information that can work together to maximize sales outcomes because information and marketing working together will not just keep your business afloat, it will help you reach new heights.”
CEO Bill smiles admiringly:
“Well that’s right, for the most part. But customer service, relationship building and word-of-mouth all existed before a database.”
Web Developer:
“Well, you didn’t store information about your customers on a computer, but you kept records, they were on paper and probably stacked in boxes that took a long time to sift through to make any sense out of it. Imagine all the information that was never read that could have helped you make better decisions faster to help improve sales — all the opportunities for new ideas and innovation never saw the light of day because all that information was collected but painful to retrieve. Wouldn’t you want to have more useful information with less hassle?”
CEO:
“Sure.”
Web Developer:
“Imagine if you were stuck with an antiquated database system that broke a lot and didn’t give you much useful or reliable information, not to mention the fact that it didn’t help you automate a lot of your systems that cost you hundreds, possibly thousands of hours in manual labor every year. If we take the time and deliberately plan your needs and design a system, database and infrastructure that can support your company needs well into the future, you will save more money in efficiencies and make more money in new revenue and marketing opportunities than doing nothing.”
Don’t get entangled in “web development strangulation”
Because improving your data and systems will almost always result in much higher efficiencies and profits, even in the short run, you need a web developer who will be honest with you. You also need to stay far away from those who call themselves web developers who write code to entrap “customers for life”. You know the symptoms, perhaps you’ve been a victim of it yourself. Why does it take so long to make a small change to your website, Intranet portal, or some backend report? If you often ask or hear this question, this is a symptom of concern for your company — you are wasting time and energy and probably have wasted a lot of time, energy and money getting in the mess you’re in now — “entangled code”, you are an unknowing victim of “web development strangulation.”
First of all, no real web developer worth their salt wants to keep going back to the same project over and over and fixing things they intentionally sabotaged just to keep their job. I’d die of boredom! Yet, many developers create complex monsters for three reasons, and three reasons only:
- They don’t know what they’re doing, so they “wing-it” and go on Google and slap things together until they work.
- They intentionally design in an over-complex way to ensure that no one else could grasp or understand, much less fix or easily replace code they’ve written in the past.
- They really don’t know what they’re doing.
The real test is if a web developer writes code and acts like they don’t want to see this project again so they spend enough time designing, thinking, planning and writing code properly so they can move onto more challenging and exciting projects. Just be sure they showed you enough of the plans and the thought that went into the design of your new systems and databases and be sure to ask what their plans are if the company out grows the system or if they decide to change database systems. If they look at you horrified, chances are they haven’t been exposed to ORMs. Mention that you insist on future compatibility and scalability and ask them if they do not recommend using an ORM in your system now, how would they plan on accommodating your company’s plans for growth later?
Using an ORM isn’t even that much more effort on the front end, but knowing you everything you need is neatly ready for scaling and portability is another positive in your company’s asset column that will inevitably bring you more revenue into your P & Ls.
– Aaron Belchamber
