Engineering Blog

Much effort has been put into making computers and computer programs easier to use. Simple and intuitive interfaces can make the user of a new tool immediately productive. This is evidenced by the popularity of WYSIWYG editors. WYSIWYG is an acronym for what you see is what you get, meaning that the view on the page while editing is nearly identical to the finished product. By hiding the details behind this friendly interface it is easy to jump in and get stuff done, but this increased productivity off the bat comes at a cost.

My first foray into the world of computer programming was simple HTML. As a 6th grader I would tinker with HTML code by hand, and create very simple websites consisting of text and images, with little to no formatting. My cousin then introduced me to the HTML editor. The particular editor I began to use was a WYSIWYG editor. The interface was very familiar right away, much like a word processor the document was displayed as it would be in the browser. My small websites began to greatly increase in quality.

I eventually hit a point where I could not get the GUI interface to make all of the modifications that wanted. It was at this point that I decided to actually go through some of the HTML that was being generated from the editor, and see if I could modify it to fit my purposes. I was absolutely shocked. By this point I considered myself pretty decent at HTML, but the code that I saw on my screen was completely indecipherable. There were tons of unnecessary tags and formatting, it was a bloated piece of convoluted code. The editor that I enjoyed so much was beginning to show its limitations. When the editor made the “right” decision it improved my ability to generate web pages in almost every way. But when it made the “wrong” decision, it was an absolute pain in the ass to troubleshoot.

More recently I have been programming Java. Working at Rally has been my first exposure to a large system with many different components. One of the components that I was made aware of early on was ORM (Object Relational Mapping). This piece of software manages database transactions so that the developer need not worry about the logic of persisting changes to system data. This was great for me! Coming into Rally I had no database experience, and our ORM allowed me to be (somewhat) productive just writing Java code, and not worrying about what was happening on the db end.

One day I was working on a particular story that involved turning on SQL logging, meaning that each call to the database generated by the ORM would be logged to a file. Upon viewing this file I was once again shocked. There were tons of unnecessary and wasteful queries. Operations that seemed normal in Java were being “translated” into some very inefficient SQL.

So how do we deal with this issue? There are obvious benefits to using technologies that hide implementation details for the sake of simplicity, but is it worth the cost?

Stay tuned for part 2.