There’s a famous quote by Abraham Lincoln that reads, “Give me six hours to chop down a tree and I will spend the first four sharpening the ax.”  What good ol’ Abe was trying to communicate with this saying is that proper preparation is key to successfully completing a task. Not only will sharpening the blade require you to assemble the necessary tools, it also saves you work when it comes time to chop down the tree.

I often think of this old adage when I am given a new report to build or feature to develop.  Instead of an axe, the tool I have to sharpen is my brain and instead of chopping down a tree, I am building software.  I am often tempted to start writing queries and assembling data before I even have a firm grip on the core of the problem.  I remember when I first started writing software, I would start furiously typing out queries and tests only to realize I was writing code that didn’t directly fix the initial problem.

Thankfully, there have been others who suffered from this lack of preparation who studied development cycles and established best practices for proper software development.  Some of the leading software development practices today are Agile, Waterfall and TDD (test driven development).

Most of the development cycles take root in waterfall which illustrated a cascading model of processes, in which progress is achieved through flowing downwards through some core main stages: requirements, specifications, design, implementation, verification, maintenance.

The waterfall methodology is appealing because specifications and designs can be created before implementation begins.  Waterfall is great concept as long as both the problem and solution are well known.  With this flow, the waterfall almost becomes an assembly line and code can be written easily.   If Abe were following the Waterfall methodology, he would have spent the first 3 hours buying the best ax, sharpening it and looking up effective youtube tutorials on how to swing an ax.  The next 3 hours would have been spent chopping down the tree.

Although waterfall provides a very clear road map to a successful launch, what happens when the solution isn’t 100% understood before development beings?  What happens when the designs and specifications made in steps two and three end up being poor choices?   For our analogy, what if Abe sharpened his ax incorrectly or discovered the YouTube video showing best chopping techniques was horribly inaccurate?

Enter the Agile Product Development Cycle.  The Agile Development Cycle starts with user stories as the driving force behind production.  Filling in the phrase, “As a ____ user, I want to ______” gives developers a clear understanding of the end goal.  In addition to starting with a customer first mindset, agile incorporates feedback loops that include testing, bug fixes and release planning.  The agile methodology takes the best part of waterfall development but starts with a solution-first approach that challenges developers to sharpen before building, test before striking and the freedom to readjust after every swing.

At Century Interactive, we know presenting data in a clear and useful way is one of the keys to helping our customers understand what it takes to own their phones.  One of our favorite ways to do this is by using detailed graphs that span anywhere from one day to several months.  The advantage of displaying extensive amounts of data is that our customers can quickly identify trends in calling activity and overall business performance.

Sharing this information makes our customers happy, but it can be a major headache for the developers who create the reports.  Five weeks of data for one company usually involves thousands of database rows that have to be combed and neatly organized.  Not only do our customers want to see the extra data, they want it to be available nearly instantaneously.  The task becomes a balance between server capabilities, database storage and overall load times.

According to surveys done by Akamai and Gomez.com, nearly half of web users expect a site to load in 2 seconds or less, and they tend to abandon a site that hasn’t loaded within 3 seconds.  Armed with this information, how do we display all our useful metrics without having users feel frustrated while looking at our beautiful loading .gif? Here are three of our easier solutions:

1.  Cut down the number of “order by” statements in the SQL queries.  Removing one “order by” statement from a SQL query returning 9,000 rows cut execution time from 3,156 milliseconds to 2,078 milliseconds.  That’s over one critical second of time we saved each one of our customers each time they visit that report.

2.  Create aggregate join tables.  By creating new tables that only reference information from other tables, we can cut down execution time to only the rows in the new table.  For example, this is helpful when we only want data from certain customers.  There’s no reason to go through our entire customer base when we only want data from dealerships.  By identifying dealership customers in a separate table, the query can skip thousands of rows on each page load.

3.  Utilize AJAX to make requests behind the scenes.  Incorporating AJAX into our reports not only cuts down on initial load times, it lets users choose what data they want to see.  The beauty of this is that the user gets more options and the amount of information we have to initially load can be cut considerably.  For example, our new CRISP score report shows a line graph with the individual “C”, “R/I”, “S” or “P” score plotted against the top 5 dealership’s over the last five weeks.  Upon page load, the only score that is shown is the “C” or “connect” score.  By adding buttons which let the user pick what score to show, we don’t have to load the other scores until the user decides to look at them.