You may not have heard the term “technical debt” before if you aren’t a developer. But, if you’ve worked with custom software at all, you’ve almost certainly felt the effects. So, what is technical debt, and what can you do about it?

Techopedia has a pretty solid definition:

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. Technical debt is commonly associated with extreme programming, especially in the context of refactoring. That is, it implies that restructuring existing code (refactoring) is required as part of the development process. Under this line of thinking refactoring is not only a result of poorly written code, but is also done based on an evolving understanding of a problem and the best way to solve that problem. Technical debt may also be known as design debt.

Or, if you just skipped that whole section as TL;DR, I’ll sum it up. Technical debt happens when a programmer decides (strategically or not) to go with a solution that gets the job done, if not always in the most effective way for the long term.

Technical debt isn’t always a coding problem, though. Sometimes business choices like rushed planning, the wrong tech stack, or other stakeholder decisions can increase a project’s technical debt. That’s why Centresource likes to get in on a project as early as possible. Allowing our strategists access to those early decisions will ultimately make development a lot faster and easier.

Technical debt happens. Accruing it does not (always) mean you have a bad programmer. Some cases call for the quick and dirty solution, understanding that it will have to be adjusted at a later stage.

The key to technical debt? Strategy.

Wait, Technical Debt Can Be a Good Thing?

The short answer is “sometimes.”

What many people forget is that computer programming is, at its heart, a creative task. Developers are often such logical people that we forget that they are creating, often from nothing, complex solutions.

That kind of creativity leaves detritus.

Think about the last time you created or learned something new. If you’re an artist, you know a lot of bad drawings happen before the best one comes out. “Mess” is a part of any creativity–including programming.

When developers are working on a new feature, there will be a lot of ways to solve the problem. The key is to find the best one, but they can only get there by trying multiple different options. Like a chef in the kitchen, the mess you’re making for the current meal is good, because it gets the food to the table. The problem happens when the mess stays around.

Aside from the creative need for a little technical debt, sometimes you’ll find there are legitimate reasons to choose a “good for now” solution to a problem. Budget, timeline, and other product features may all lead you to decide to knowingly take the duct tape solution, while planning to fix it in the future.

The key is strategy. It’s purposely choosing that option, with a basic plan to iterate on it in another phase of the project.

Crisp’s Blog has good illustrations of how to think about good and bad technical debt, if you’re interested in diving a little further on it.

I Have Technical Debt–Now What?

Don’t panic. Just like with consumer debt, there are strategies to deal with technical debt. Every project is different, but technical debt is not an unclimbable mountain.

In the next week, we’ll talk more about how we handle technical debt at Centresource.

This post is the third in a series about the development of The National Museum of African American Music’s digital exhibit: Rivers of Rhythm. The first two posts in the series introduce the client, as well as detail the planning of the application. In this post, User Experience Designer and Front End Developer Jimmy Thorn discusses the process of determining how to best present the musical data within the product.

One of the most challenging tasks we faced while developing this application was determining how to best present the musical data to our users. Design was extremely important to the client – they wanted to create a digital exhibit that both presented accurate information pertinent to the forthcoming museum and was sleek and attractive for the target audience.

Our team had selected Rovi, a robust third party database of artist information to populate the data within the application. We chose Rovi for a variety of reasons – chief of which is how rich their music database is (it is the same database used by applications such as Spotify and AllMusic), and the fact that the client would not have the manually input musical data, which would save considerable time and effort.

We knew that the product would have a lot of repetitive patterns, due to the prevalent artist influencer and influencee information, and thus we started by wireframing the data as a grid. As we began to design the prototype, we realized the grid and block approach worked well for the shapes of data being pulled from Rovi such as album covers and artist headshots. I worked to create a rough design then passed it off to our Art Director, who took it and polished it: emphasizing the larger images, making it cleaner and more professional.

One large design pivot we made occurred after the prototype process. While the client was pitching potential sponsors with the prototype, we had included a fake sponsor page customizable to the particular pitch. Once Belmont committed to fund the full application build, we wanted to better highlight their relationship with NMAAM. We incorporated subtle but prominent references to Belmont and their role in helping Rivers of Rhythm come to life. Overall, the client was extremely happy with the design – and a Rovi associate even said it was one of the most elegant and visually appealing presentations of their data that they had seen! 

Rivers of Rhythm Grid

This post is the first in an upcoming blog series about our planning, design, and development of the music discovery application, Rivers of Rhythm for The National Museum of African American Music. Follow our blog for additional posts and discussion of our product development process. 

Over two years ago, I had the pleasure of sitting down with Henry Hicks, the President and CEO of The National Museum of African American Music at the Red Bicycle in Germantown. The museum would be opening its doors in around four years, after years and years of planning and fundraising to get to this point. In the interim, the museum needed a way to engage and connect with music lovers around the globe, as well as generate buzz and interest in the museum. They decided that a digital experience was the direction they wanted to go. Walking away from that initial meeting, we both knew that by combining the superpowers of NMAAM and Centresource, we could make big things happen.

After months and months of brainstorming sessions and meetings, we all agreed that this application needed to be something you could get lost in. It also needed to be a resource to music lovers, providing them an outlet to get exposed to new music, but still feel like they are part of the larger story around American Music. The Rivers of Rhythm application was born from those conversations.


Once we had a plan, we had to decide what was the best first step. Our team recommended taking the path of creating a clickable prototype of the application. This tool would provide NMAAM the opportunity to let their board members, staff and potential donors experience the application without having to go straight into the build. For a fraction of their budget, Henry could take this prototype to potential sponsors to help them envision how their company could partner with the museum to get this digital experience in people’s hands.

NMAAM quickly saw their return on investment when Belmont University expressed interest in being part of this project, and donated the funds to bring it to life. In June, I had the pleasure of attending a press conference at Belmont University unveiling the Rivers of Rhythm Digital Experience. Our team was honored and proud to be part of that event as well as this two year long project. I literally cry every time I talk about it:) We look forward to a long standing partnership with NMAAM and Belmont University in seeing this revolutionary application change how music lovers discover music online.

I have been going to BarCamp every year since I moved to town in 2010 – I always meet new people, see interesting friends, and leave with a long list of ideas.

This year’s BarCamp was one of the most diverse events I’ve been to in a while.  I met students, professors, parents, teenagers, executives, creatives, job seekers, hiring managers, entrepreneurs, Nashville natives and recent transplants – women and men of all ages and colors.

Here are a few of my takeaways from BarCamp 2015:

  • Alan Laidlaw – one of the most thoughtful product strategy minds in our community – led an interesting discussion about the future of the internet.
  • Data scientist Pete Mancini (@nectarineimp) convinced us – using the principles of Game Theory – that hostile aliens are probably planning to attack the earth.
  • I learned about the HTC Vive Experience downtown – I lost a game of rock-paper-scissors to my husband and he got to go, but we might not have known about this amazing opportunity otherwise.
  • I got personalized coaching on my elevator pitch – in front of an entire group of people. It sounds like a nightmare, but presenter Carolyn German made it powerful, and very instructive.
  • I met lots of people who recently moved to town. Nashville’s reputation as an IT-city has blessed us with some great talent.

Thanks to Edwin, Chuck, and the amazing crew that works to make BarCamp such a great event for our city.  I’m excited to see what’s next.

Imagine this scenario:

You buy a brand new, shiny Toyota Camry. You love your Camry. It’s practical, it’s clean, it gets pretty decent miles per gallon, and it was affordable.

After you’ve been driving your smart, affordable and stylish Camry around for a while, you start to notice more and more campers. “What the heck”, you think? “Why are there so many campers driving around every day? Am I missing something here? Why are there fewer and fewer Camrys on the road these days?”

One day it hits you.

Everyone now drives a camper, and you are driving an old, out of date Camry.

You decide that you too, must get a camper. But you don’t want to pony up and spend the money on a brand new camper. “What if I can have my Camry converted into a camper? That makes a lot of sense!”, you think to yourself. “My Camry is practical, clean, stylish, and only a year or two old. Surely someone can turn this thing into a camper for a fraction of the price of a new one.”

You take your Camry to a mechanic to have it converted to a camper.

The mechanic tells you something like this:

“Well, in order to convert this Camry over, we’re going to have to remove the frame, create a new frame, cut the body up and weld new pieces on to it. Then we will have to make sure the frame fits with the modified body. If that works, then we need to make sure this thing can keep in traffic. If it keeps up in traffic, we then need to make sure it’s safe to drive.”

After 2 weeks of waiting, your mechanic calls.

“I’m not sure we can make this happen for you. And it’s going to take a long time, and it’s going to be expensive. It honestly would be much cheaper and reliable for you to go to the camper store and buy a brand new camper.”

Does this sound familiar?

Maybe you have a website that was built before the web moved to the mobile world. Now you need your site to be responsive. You’ve also heard that Google is going to lower your site in search results if you are not responsive, and this scares you. You know that you need a responsive site as soon as possible. Your business depends on it.

We get it, and we get this question a lot.

Unfortunately, there’s no good way to do this without a full rebuild. Websites these days use what we call “front-end frameworks”. These are a fully thought out set of elements, grid structures, and styles that allow a site to repurpose itself depending on how big the screen is that is loading the site.

There’s no real way to shove one of these frameworks into an already existing site. Just like the differences between a Camry and a camper, a responsive front-end framework and a non responsive site are two completely different things.

If you want to move into the mobile web, you’re going to have to do it once, and do it right. This involves a complete site rebuild. I know this is not what you want to hear, but in the long run, this will cost you less, make your site more “future-proof”, and it will perform exponentially better for your users.

At the end of the day, speed, security and a pleasing experience for your users should be your main goal. If you are in this situation, plan ahead. Get the capital together to do this right. Your users, employees and bank account will thank you.

We love building responsive stuff. It’s something we are passionate about. We have iPhone fans, and Android fans here at Centresource. When we are not fighting each other with torches and pitchforks over which platform is better, we all agree that the future of the internet is on mobile devices. This won’t change anytime soon.

Do it once and do it right.

Disclaimer: I in no way endorse the purchase of a Toyota Camry. Do yourself a favor and buy something that is actually fun to drive, such as a Subaru WRX, Volkswagen GTI, or a Lamborghini Gallardo. You can thank me later.

Also, Android is better 🙂

As a business owner you are always looking for the next step – how you will grow your business, improve your product, sustain competition, and with the increasing popularity of mobile technology, you may feel that your business would benefit from building an app. It should be simple enough, right? After all, school age kids are doing it in their parent’s basement on the family computer. How hard can it be?

Well, while you may be an expert in your industry, the software business can be pretty tricky. There are three common pitfalls that can cause your app to take a nosedive and it very well could take your company with it.

  1. Mishandling your funds: Statistics tell us that 9 out of 10 tech startups fail (1). Most of these are not because of features or usability, but instead are problems related to cash flow, undercapitalization, and lack of revenue. Keep your eye on creating the shortest possible (responsible) path to revenue. Don’t spend everything you’ve got on your first build. We often advise taking your total Phase 1 budget and dividing it in half. Invest the first half getting your first iteration built. You’ll need the rest for polish, further iterations, fixes, maintenance, marketing, and the issues you cannot see yet.
  2. Lack of clarity is another common problem. You may be hard at work building a great app, yet have no idea what specific problem you are solving or who you are solving it for. When you are fully immersed in building software, it is very easy to lose sight of your ideal customer. Without clearly defining who the primary user of your product will be, your team may lose its common vision – sending product owners, UX/UI designers, developers, QA staff, marketers, and salespeople each in a different direction.  Few companies take the time to create a specific, detailed profile of their ideal customer before beginning to build their software, and while it is no easy task, those who accomplish it fare far better than those who don’t.
  3. Trusting technologists to make business decisions. While a talented developer is invaluable to your team as you build the software, developers typically are not inclined to think of the business implications of technology decisions. A poor platform decision out of the gate could cost you down the road. You need an experienced, diverse team who fully understands all aspects of the digital market.

Although developing an app can be a difficult process, being cognizant of these three major pitfalls can help you avoid detrimental mistakes and develop a successful app that will benefit your business.


Did you know that Amazon found that for every 100 milliseconds more in page load time, their sales decreased by 1%? That when Google switched from a 10-result page loading in 0.4 seconds to a 30-result page loading in 0.9 seconds, that it decreased traffic and ad revenues by 20%? Or that when Google Maps worked to reduce their homepage load time from 100KB to 70-80KB, that their traffic went up 10% in the first week, and 25% in the following three weeks? (1) If these statistics weren’t enough to make us sit up and listen, consider for a moment that these came from studies done in 2006 and 2007. For those keeping score, 2007 was the year the first iPhone was released. The explosion of mobile devices into the web space – devices with less processing power and memory than their desktop counterparts, only increases the urgency around this topic.

Your website’s performance directly impacts your revenue, whether you’re using it as a tool to generate leads, sell goods, or even just increase brand awareness. So what can you do about it? For starters, consider a performance audit on your website. This audit will reveal in a negligible amount of time not only how much room for improvement there is on your website but also quick wins that could be extremely cost-effective to put in place. And finally, take comfort in knowing that measuring performance is an exact science, which means you will be able to see the performance statistics of your website before and after any changes are made, then be able to measure your website’s goals against them. What are you waiting for?  


So you’ve got a great idea.
You’ve assembled a crack team of marketers, sales people, client support and investors.
You’re ready to get your idea transformed from vaporware to a fully functioning, sellable web application.

These are exciting moments in your new business venture’s life cycle.

It’s time to take your idea and have some designers and UI/UX specialists create your vision in Photoshop so you can pass this along to your development team. In your meeting with your designers and UI/UX people, they ask you a very important question:

“Will you want a front-end prototype of this built?”

This is the point where you emphatically reply with, “YES”, and I’m going to tell you why.

Front-end prototypes are a crucial element to the success of your web app or service. They allow you (the client) and us (the designers and UI/UX team) to properly figure out how your app should function, look, and generally behave from the user’s point of view.

A lot of clients will think, “Well this sounds like an added cost. I can just take the Photoshop mock-ups and pass those off to my team of back-end devs and they’ll chop them up and make them work.”

This is so often not actually the way it works. I have the upmost respect for the magic that the back-end guys perform, truly. We have some of the brightest and most talented back-end architects in Nashville at Centresource. They are able to blow me away with the things they can do in an MVC on a daily basis.

That said, just the same as I wouldn’t want a back-end guy figuring out how a site’s navigation and color scheme is supposed to look, they absolutely would not want me (a front-end guy) trying to figure out how to best manage the app’s database.

What often happens when an entrepreneur opts to not do a front-end prototype, is that after they pass the Photoshop layered files off to their dev team, they come back with something somewhat working, but mostly a mess for the user. Fonts are incorrect, padding is off, elements that are supposed to be circular are rectangular, none of the javascript works the way it was intended. This results in an app that is unattractive, hard to use, and a nightmare to actually sell in the marketplace.

By allowing a full front-end prototype to be built, a client can avoid the pitfalls of having to hire another team of developers to clean up the potential mess that their initial dev team created by trying to shoehorn their skills into an unfamiliar area of web development.

In 2015, design and user experience is at the forefront of almost every major technology in the marketplace.

Apple has completely revamped iOS and OS X to create a more unified and minimalistic user interface that is focused more on the ability of the user to quickly get things done, than to show their ability to make your screen look like a wooden shelf with a 3D perspective.

Google has dropped the overwhelming green hues and Tron-like neon blue elements in previous versions of Android for their new “material design” approach, which again, ignores their stylistic tastes in favor of usability and quick communication.

Even Microsoft has changed their UI strategy since the release of Windows 8 to move more into a user-focused operating system. They plan to take this even further with the release of Windows 10, due out later this year.

In this age of the digital world, it is truly a time where all successful products are built first and foremost with the user in mind. This isn’t likely to change anytime soon. When planning the strategy of your next great idea, be sure you factor this in and allow a team of talented designers and UI experts to create a working prototype before you hand it off to those back-end guys.

This will save you costs, allow you to keep and gain more users, and you’ll spend less time re-designing things that your users are badgering you about via email and help tickets.

A prototype is a visual, tangible representation of an application that doesn’t require full-fledged development. Our clients have found these models incredibly useful in applying a lean methodology to their application build. So how do you know if you need a prototype?startup-prototype

  1. You are seeking outside investment.  Very few investors and customers understand code, but most understand design.  A picture is worth a thousand words.  Customers and investors don’t have time for a thousand words, so designed screens do the communicating for you.
  2. You still aren’t sure whether customers will pay to use your product.  Getting this question answered as soon as possible (without investing your entire budget) will serve both you and your investors. Building a prototype and using it to sell or pre-sell your intended customers reveals volumes about usability, features, and pricing, which are all critical to success.
  3. You’re interested in user testing.  Conventional product development wisdom states that it takes four tries to get it right.  Spending a fraction of your budget on a prototype and then conducting user testing will allow you to get through a couple of product iterations while preserving cash.
  4. You have developers, but know you’ll need UX expertise to build a world-class product.  Workflow documentation is often inadequate to move quickly into production. Our UX team has been able to jump in and deliver product planning, design, and front-end code to client developer teams, which saves them from having to hire and manage, and creates massive efficiency gains for developer teams.
  5. You’re bootstrapping.  Prototyping is a great way to minimize risk at the early stage.  Most MVPs (Minimally Viable Products) require significant investment.  Getting something built shows progress, and can be used to create traction, which is a powerful currency in the early stage.

Prototypes can be incredibly powerful.  One of our startup clients invested about $20,000 in a prototype with us, used it to pre-sell contracts worth over $1MM. That demonstration of traction got them an investor round of $3.4MM.


We at Centresource love open source software. We use open source projects every day from Ruby on Rails to jQuery, Linux to OpenSSL. In that spirit, we have a few open source projects of our own. These projects open up our process and experience to the community. They serve as a chance to contribute back.

We are happy to announce that our project, Playbook, has reached a 2.0 release.

Playbook is a tool to speed up prototyping and static site development. With a few simple prompts you can have your static site up and running in minutes. The generator for Playbook asks you a bit about yourself and a few simple configuration questions. From there, it installs our preferred tool chain, including Bourbon and Neat. You may also add options to support legacy browsers and add Google Analytics.

So many of our recent prototype engagements have utilized Playbook that it would be difficult to fit them all into one blog post. To give a sense of just how much of our own dog food we are eating, we used Playbook to create The Playbook project site, itself, was built using Playbook. And things get even better in the 2.0 release.

In Playbook 2.0 we move from the Grunt tool chain to Gulp for even speedier development. We have also upped our version of Jekyll and bumped the required Ruby version to >= 2.0.

On a personal note, one of my favorite aspects of the Playbook project is that we have former Centresource team members as core contributors. We continue to connect and collaborate even when we no longer work together. This aspect is one of my favorite parts of open source software: the sense of community around a project. I hope the Playbook project continues to grow and serves its users well. Happy Playbooking.