Tag Archives: orm

Are frameworks a shortcut to slow bloated code?

elephant traffic jam

I was reading one of my favorite blogs again, Todd Hoff’s High Scalability. He has an interesting weekly post format called “Quotable Quotes”. I like them because they’re often choice quotes that highlight some larger truth.

Join 32,000 others and follow Sean Hull on twitter @hullsean.

1. Chasing bloody frameworks

One that caught my eye was this one by Sandro Mancuso:

Frameworks are bad? Aren’t these the foundation of reusable code? Can we build for the web without Ruby’s Rails, PHP’s Laravel or Java’s Spring?

Also: Are we fast approaching cloud-mageddon??

2. Architecture purity or bloat?

Luckily the conversation remained civil. The other side of the isle piped up with practicality. I think Jeff is saying “Hey we gotta get our jobs done.”

Related: Did MySQL & Mongo have a beautiful baby called Aurora?

3. Look Ma No Frameworks

Then Pablo Chacin jumps in with his slideshare deck, rejecting Frameworks as hugely wastful.

Read: When hosting data on Amazon turns bloodsport

4. Beware the ORM

Anyone who’s a regular reader of this blog knows that I’ve railed on against ORM’s for a long time. These are object relational mappers, they are a library on to of a relational database. They allow developers to build software, without mucking around in SQL.

Hibernate is a famous one. I remember back in the late 90’s I was brought on to fix some terrible performance problems. At root the problem was the SQL code. It wasn’t being written by their team & tuned carefully. It was written en mass & horribly by this Hibernate library.

Also: Is the difference between dev & ops a four-letter word?

5. Where’s the oversight?

Perhaps the biggest risk to many startups is that the decision isn’t being made at all. What do I mean by this?

I think this tweet gets to the heart of it. Often the decision to use a framework or not is simply hidden in plain sight, an assumption albeit a large one, that this is how you build software.

But these decisions are so fundamental because once your scaffolding is built, it becomes very hard to disentangle. Rip & replace becomes terribly expensive, and scalability becomes a painful unattainable dream.

Also: 5 things toxic to scalability

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Understand the High Cost of Technical Debt by Ward Cunningham (Video)

A week or two ago, I got into a conversation on Twitter about technical debt, and someone shared this superb video by Ward Cunningham (youtube). Here is Ward’s Interview website.

Join 10,000 others and follow Sean Hull on twitter @hullsean.

Waterfall, agile, developer or operations, devops, managers, CTOs… everyone should watch this video, for it cuts to the heart of the challenges we face doing modern software development, in a fast paced and always changing environment.

Though it’s not mentioned in the video, I would argue using an ORM is an expensive form of debt, one that is improperly calculated by teams, managers & startups, and one that bites hard into future scalability. Stay tuned for a post about that!

Enough said, here’s the video.

Here’s the transcript of much of the dialog. Appologies for any typos…

1. Metaphors & Thinking

I became interested in the way metaphors influence the way we think

after reading George Lakoff & Mark Johnson’s Metaphors We Live By (Amazon).

An important idea is that we reason by analogy through the metaphors that have entered our language.

Related: 5 Things Toxic to Scalability.

2. Coining Debt Metaphor

I coined the debt metaphor to explain the refactoring we were doing on a product.

This was an early product done in smalltalk. It was important to me that we accumulate the learnings we did about the application by modifying the program to look as if we had known what we were doing all along. And to look as if it had been easy to do in smalltalk.

The explanation I gave to my boss, and this was financial software, was a financial analogy I called the debt metaphor and that said that:

If we failed to make our program align with what we then understood to be the proper way to think about our fin objects, then we were going to continue to stumble on that disagreement which is like paying interest on a loan. -Ward Cunningham

Also: AirBNB didn’t have to fail when Amazon went down.

3. Need for Speed

With borrowed money you can do something sooner than you might otherwise, but until you pay back that money you will pay interest.

I thought borrowing money was a good idea. I thought that rushing software out the door to get some experience with it was a good idea. But that of course you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

Read this: Why generalists are better at scaling the web.

4. Understand the Burden

I think that there were plenty of cases where people would rush things soft out the door & learn things, but never put that learning back into the program. That by analogy was borrowing money thinking you never had to pay it back. of course If you do that you know say with your credit card, evemtually all your income goes to interest & your purchasing power goes to zero.

By the same token if you dev a program for a long period of time, by only adding features, and never reorganizing it to reflect your understanding of those features, then eventually that program does not contain any understanding and all efforts to work on it take longer and longer. In other words the interest is total. You’ll make zero progress.

Check out: How to hire a developer that doesn’t suck.

5. Achieving Agility

a lot of bloggers at least have explained the debt metaphor and confused it i think with the idea that you could write code poorly with the intention of doing a good job later. and thinking that that was the pirmary source of deb.t I’m never in favor of writing code poorly. But I am in favor of writing a code to reflect your current understanding of a problem even if your understanding is partial.

If you want to be able to go into debt that way by dev soft you odn’t completely understand, you’re wise to make that software reflect your understanding as best you can. So that when it does come tiem to refactor it’s clear what your thinking was when you wrote it. and making it easier to refactor it to what your thinking is now.

in other words the whole debt metaphor or lets say the ability to pay back debt, and make the debt metaphor work for your advantage depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.

i think that’s a good methodology it’s at the heart of extreme programming. the debt metaphor is an explanation, one of many explanations as to why extreme programming works.

Read our popular interview guides for candidates, managers & recruiters: MySQL DBAAWS Expert (Amazon Cloud) and Cloud Deployment & Automation Engineer.

Don’t forget, hiring is a numbers game

Get some in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample

Object Relational Mapper – What is it and why is it important?

Object Relational Mappers or ORMs are a layer of software that sits between web developers and the database backend.  For instance if you’re using Ruby as your web development language, you’ll interact with MySQL through an ORM layer called ActiveRecord.  If you’re using Java, you may be fond of the ORM called Hibernate.

ORMs have been controversial because they expose two very different perspectives to software development.  On the one hand we have developers who are tasked with building applications, fulfilling business requirements, and satisfying functional requirements in a finite amount of time.  On the other hand we have operations teams which are tasked with managing resources, supporting applications, and maintaining uptime and availability.

Often these goals are opposing.  As many in the devops movement have pointed out, these teams don’t always work together keeping common goals in mind.  How does this play into the discussion of ORMs?

Relational databases are a technology developed in the 70’s that use an arcane language called SQL to move data in and out of them.  Advocates of ORMs would argue rightly so, that SQL is cumbersome and difficult to write, and that having a layer of software which helps you in this task is a great benefit.  To be sure it definitely helps the development effort, as software designers, architects and coders can focus more of their efforts on functional requirements and less on arcane minutiae of SQL.

Problems come when you bump up against scalability challenges.  The operations team is often tasked with supporting performance requirements.  Although this can often mean providing sufficient servers, disk, memory & cpu resources to support an application, it also means tuning the application.  Adding hardware can bring you 2x or 5x improvement.  Tuning an application can bring 10x or 100x improvement.  Inevitably this involves query tuning.

That’s where ORMs become problematic, as they don’t promote tweaking of queries.  They are a layer or buffer to keep query writing out of sight.

In our experience as performance and scalability experts for the past fifteen years, query tuning is the single biggest thing you can do to improve your web application.  Furthermore some of the most challenging and troublesome applications we’ve been asked to tune have been built on top of ORMs like Hibernate.

Sean Hull asks on Quora – What is an ORM and why is it important?

SQL – What is it and why is it important?

The What:

SQL is a difficult acronym for a difficult language, but what it does is shuttle information into and out of your database in an organized manner.  Your web applications and developers have to speak it, and your database – whether Oracle, MySQL, Postgres or some other will return information back using this computing dialect.

The Why:

Since every movement on your website, from page to page (sessions) and purchase to purchase all involve interaction using these queries, writing them well can have a huge impact on your website performance.  How big?  We’ve fixed queries by adding indexes or rewriting them and seen improvements by as much as 100x.  That’s converting pages that take ten seconds to ones that take 1/10 of a second.  Be especially vigilant about those queries generated by Object Relational Mappers like Active Record, Ruby’s ORM layer.

What is SQL on Quora