There is nothing like starting a new Ruby on Rails project—a clean slate spread out before you, a dynamic new vision, and only the limits of your own enthusiasm between you and world domination. This article is not about those projects.
At Foraker Labs, many of our client projects are actually “salvage” operations—web applications that were started by other development shops that ran into trouble along the way. We get called in to put things back on track. Contrary to popular opinion in the Ruby on Rails development community, this sort of work is both challenging and rewarding. We’d like to share some of the secrets we have learned about approaching these projects over the years.
Confronting the Problem
The typical Ruby on Rails salvage situation starts with a moment of clarity: Your application is so full of bugs and usability issues that you reach the breaking point; or, your on-again/off-again freelance web developer decides to abandon software and become a free-range llama herder; or someone sees your application and says, “I wish more software had that chunky 80s look! It reminds me of my old Atari.” This situation is often accompanied by the same panic and dread you’d feel if you woke up to find three feet of standing water in your basement. What should you do?
DON’T PANIC. If the situation is dire and is costing your business piles of money every day (or if your buggy software actually did cause a flooded basement), then you must perform triage. Hire a freelance web developer or a development firm to get things patched up enough to run. Then take a step back to evaluate.
Why Is This Project Off the Rails?
Once you have stopped the leak and pumped the water out, the most important question to ask is why things went wrong in the first place. If your plumbing is shot, you’ll want to have that fixed before you start throwing up new drywall. Here are the most common issues we have encountered:
A Lack of Clear Vision
We’ve found that many larger projects that have been in operation for some time tend to lose clarity of vision. The vision may have been clear at the start, but over time things begin to wander. Sometimes the vision has changed but the software has not kept pace. When the vision is unclear, the software developers cannot work efficiently. Additionally, software usability suffers—unclear vision nearly always translates into a confusing user interface.
An example: suppose you are not clear about whether your online site is selling new widgets, or connecting widget users to other widget users in an online community. If the vision on this is not clear, it is likely the user interface will not clearly and intuitively direct the user in the desired direction. For example, community may be over-emphasized and people who simply want to buy a widget may be turned off at first glance, assuming your site is mostly about the widget user community, and not an easy, inexpensive point of online purchase.
It is not that a site can’t do both. It is about understanding what the primary purpose of your site is, and structuring the entire experience and interface around that purpose. If that vision is not clear, there is a good chance that the user interface will reflect that lack of clarity.
When we encounter this problem, we work with a client to re-establish a clear vision. We also evaluate the existing system to identify major elements that diverge from the vision. We establish a plan to put the software back on track, and to guide future development.
The Wrong Development Team
Another common problem we encounter is that a failing software system does not have the right team working on it. Most often this occurs when a part-time freelance developer was used to get the project off the ground, but the project has grown beyond the skill set or availability of that individual.
The truth is that really good software is created by a mix of many skill sets—each of which is a career unto itself. It is extremely rare that a single individual has all of the skills necessary to do it. If your system is not performing the way you want it to, it may be that your current developer simply doesn’t have the breadth of skills to support it effectively. A full development team includes people who are highly skilled at programming, visual design, user experience design, quality assurance and product strategy. Other more specific skills (e.g., database architect) may be needed on a case-by-case basis.
An example: on the web, support for mobile devices (e.g., smart phones, tablets) is increasingly critical. A 2011 report indicated that 7% of all online traffic is from mobile devices (and that percentage is growing rapidly). For this reason, it may be important that your site or application support not only all of the desktop browsers (a challenge in its own right), but also support mobile browsers. To do this well and seamlessly, you need a dedicated front-end programmer. It is rare that an individual generalist has the specific skills necessary to ensure seamless compatibility across all of the platforms. This is just one particular example, and may or may not apply to your case specifically.
When we encounter this problem, we help potential clients identify the advantages they will obtain from hiring a full development team, and to evaluate whether that represents a good return on investment. In many cases, a full development team doesn’t make sense, and we’re happy to tell people that. In other cases, a critical business system may be at the point where it will fail without the attention of a broadly skilled team. We do our best to help potential clients understand the trade-offs and make a good decision.
Unpaid Technical Debt
Technical debt refers to a large backlog of bugs and other defects, as well as underlying “plumbing issues” that you never seem to have time to fix. You knock one issue out and three more pop up. Eventually this debt becomes overwhelming, and you spend more effort servicing your debt than you do adding new features.
Several issues cause technical debt, often several at the same time. Some of the most common include: unskilled or inexperienced developers, lack of attention to quality, poor requirements analysis, unrealistic development schedules, and insufficient budget (which usually leads to low quality or rushed schedules).
Paying off technical debt can be just as painful as paying off its financial counterpart. Yes, it can be costly. But just as with financial debt, not paying it off can cost you a far greater fortune in the long run.
Frequent developer turnover can kill a project, regardless of the skills of the individuals doing the job. Whether you have an in-house team or hire outside freelancers, frequent turnover often leads to inefficient, shoddy code.
A professional development shop can attract and maintain a team of highly skilled individuals. Many of the salvage projects we have taken on were failing because the client could not maintain a steady development team. Internal development teams often suffer from turnover because creative, skilled software professionals are always seeking new and different challenges. In-house development teams often settle into repetitive work with little room for innovation or experimentation.
Internal and freelance developers are typically less expensive by the hour, but apples-to-apples comparisons are very difficult. Research shows that software productivity can vary by a factor of 10 between two individuals! And hidden costs like hiring, management, and professional development can quickly skew this equation into a cherries-to-watermelons comparison.
The Wrong Platform
Another common problem with failing projects is that they have been built on a platform that does not support their goals. The most common case is a system that starts out by using off-the-shelf software in order to “avoid re-inventing the wheel.” We usually see this with ecommerce systems and content management systems, which might be commercial products, or free, open-source software. While these platforms may have been a great choice to get a simple system off the ground cheaply, when it comes to running a business-critical application there can be many pitfalls.
Most free, open-source platforms work very well if used for their intended purpose with “out of the box” functionality. However, the more you customize these systems, the more you can end up fighting the platform instead of using it. For example, you can do amazing things with WordPress by installing plugins and extensions. However, the more you add, the more you find yourself running into compatibility problems and upgrade issues. The plugins are developed by different people, are supported (or not) in different ways, and typically have wildly different user experience design. If you want to run a blog then WordPress might be the best choice but once you try to add in e-commerce or any other non-blog feature you are probably best off with another solution or a custom solution. We’ve seen that over the long-term, customizing off-the-shelf software is more expensive than building what you need from scratch. This wasn’t true 10 years ago, but new development technologies like Ruby on Rails have made custom software less expensive than off-the-shelf for most web applications.
We’ve identified some of the common reasons that development projects run into trouble, and what to do about them. If you have any questions, contact us and we’d be happy to talk with you about your situation. We’ll also be following up on this post with more specific examples of the above scenarios and how to address them. Stay tuned!