Has your Rails application gone off the rails, dragging your business along with it?

Does this sound familiar? 

You want to build new features to grow and improve your business, but you’re noticing that the time taken to develop them is gradually increasing. This causes missed deadlines and frustration amongst your team.

Not only that, when a new feature does get built, it causes other parts of your app to break, leaving your team in a scramble to deploy non-optimal hot fixes so your users and clients are not affected.

Hot fixes, which once deployed, are never refactored and cleaned up.

Unfortunately, this leaves your codebase more fragile and harder (read “more bugs”) to work on than before.

Now, you’re more than familiar with technical debt. You realize that though it can make business sense to incur technical debt (perhaps to meet an important deadline), letting your debt get out of control can easily cripple most of your future development efforts. However, you also know that getting rid of technical debt is a “hard problem”, in more ways than one.

Your team need to be well-versed in the techniques needed to refactor a legacy code base. They also need to be able to get the codebase to a point where it can be refactored in the first place by ensuring a high level of test coverage. This can be hard to do depending on how inflection and change points are distributed in your system. Perhaps just as important, because your business is growing, your team is focusing on new feature development and simply do not have the time to exclusively make payments on technical debt in your system.

You’re looking to get some outside help, but you’re unsure if someone can come in, learn the domain knowledge specific to your business and make your codebase better without disrupting your team’s workflow.

You need a way to accelerate your team’s development cycle, so you can get more features out the door and into waiting customers’ hands.

You also need to get a handle on your technical debt to ensure it doesn’t spiral out of control.


clean-code-vs-legacy-code


You might be wondering if investing the time to get a handle on technical debt in your Rails app is worth the effort. It’s all well and good to have a codebase that your developers love working on, but what’s the point if it doesn’t move the needle on metrics that matter most to you and your business?

In other words, how exactly will this benefit your business?

New features will be pushed out the door faster and cheaper

Technical debt slows your ability to deliver new features, and this lack of speed results in an opportunity cost for lost revenue. By investing the time and resources to refactor and “pay down” the debt, your codebase will be easier to change in the future. This directly translates to a lower cost per feature and enables your team to move faster.

Reduced bug rate

A high bug rate is a two-headed monster. Firstly, your users will be displeased. On top of that, your developers and the rest of the team will have to divert their limited attention to fixing bugs and handling support requests. In most cases, bugs are directly or indirectly a result of technical debt not paid in full. You’ll find that your bug rate goes down when your codebase is well-factored and your technical debt is under control.

Increased developer productivity

A well-factored codebase greatly increases developer productivity and happiness. Happy and productive developers will often be more innovative in their approach and spend more time working on features that are important to the business (read “revenue generating” and/or “cost saving”) and less time chasing down intermittent and catastrophic bugs.

Not only that, existing performance issues and bugs become way easier and faster to debug and fix.

Improved Stability

Increased stability in your application and infrastructure means more time spent helping your customers “kick ass” and less time waking up at 4 am to restart the servers because of a memory leak.

Ultimately, you’ll find that with a well-organized codebase and development process, your business will be able to evolve sustainably with changing business requirements. Your developers will be able to take on bigger challenges and confidently build the systems that will power and grow your business for years to come.

It’s time to ensure that your development process and codebase amplify your business objectives, rather than get in the way.

Here’s how I can help…


A Rails Code Audit identifies, via a step-by-step process, exactly what you need to do to get a handle on technical debt in your Rails application. It will start off by determining the current health of your application and what it does well. Then, it will go on to diagnose the problems your application has and outline a set of strategies, techniques and tactics you can use to fix these problems for the long term, while ensuring minimal disruption to how your team currently operates. Finally, you will have the option to engage with me for a longer term so I can personally help you and your team get a handle on your technical debt.

Your Code Audit will be unique to you and your business, and be tailored to your unique development process.

Rails Code Audit: A 4-step process

Rails Code Audit Steps

Step 1 – Assessment & Goal Setting

First, we’ll block out 1 hour to talk face-to-face and dissect your development process and application at length.

In order to help us prepare for this initial meeting, I’ll send you a short questionnaire designed to highlight the problems you’re having, and the goals you have for your business and codebase. I’ll also ask you to give me access to your codebase, and if possible, a login to your staging or production application.

Once I have your answers, I’ll send you an invoice of $1,000, payment of which will serve as the official confirmation of our engagement. This $1,000 payment will cover the entire length of our engagement from Step 1 to Step 3. At the end of step 3, when I deliver my recommendations, you can choose to engage with me and have me implement my recommendations. I will do so in a way that will cause minimal disruption to your team’s workflow.

After our first meeting, we’ll also schedule one or more follow-up interviews if I need to drill deeper. I will also be in regular touch via email.

Step 2 – Inspect

Once I have a good idea of where you’re looking to be, I’ll get to work with a thorough, line-by-line inspection of your codebase. I’ll start off by noting first what you and your team have done well, as I think it’s important to acknowledge the hard work that has gotten your company to where it is.

Using tools like simplecov, rubocop, codeclimate and git, I will:

  • Assess test coverage throughout your app
  • Assess code quality throughout your app
  • Find out which areas of the codebase are changed the most
  • Assess code quality and test coverage of these areas

Using the metrics established above, I’ll proceed to perform a visual inspection of your codebase, covering:

  • Models, Views and Controllers
  • Tests (with a focus on completeness and speed)
  • Database concerns (for example: checking for missing and/or superfluous indices)

I’ll keep an eye out for any obvious security issues like outdated gems, handling third party credentials and others.

I’ll also look at performance, as your end-user perceives it. Performance bottlenecks in Rails apps are often tied to how you handle things like caching, leverage services like CDNs and how your database is architected. It is very possible to get sub-100 ms performance with your Rails app!

Step 3 – Recommend

Once my analysis is complete, I’ll put together a multi-page report that will outline the results of my analysis in detail. The Code Audit report will contain customized recommendations covering all the areas described above, and specifically target the areas of your codebase that need the most work.

Step 4 (Optional) – Implement

If you and your team are strapped for time because you need to focus on new feature development, the report I generate for you probably wouldn’t be very useful on its own. Here’s where I can come in. I can gradually help you make inroads into getting a handle on your technical debt, by re-architecting your codebase in a bite-sized, atomic manner that cause minimal disruption to your team’s workflow. If needed, I can also help with implementing new features, with a focus on cleaning up the technical debt that I run into.

As noted in the title, this step is optional – if you’re interested in having me implement the changes that I recommend, just let me know and we can discuss next steps.

Steps 1 to 3 are intended to be a low-risk way for you to try out my services and assess for yourself if you’d like to engage me further.


“I have a few questions before I’m ready…”

What are your qualifications?

I’ve written production software in various forms for more than 10 years. Before building web apps in Ruby, I wrote software in C and C++ that controlled the inner components of devices like TVs and game consoles. I also wrote desktop applications in Python to make building and testing these inner components (known as Integrated Circuits or ICs) easier. The web apps I’ve built with Rails cover a wide range and size of applications, from huge project management apps to MVPs. I’ve built greenfield production apps on my own and also worked on large legacy applications with multiple team members. I most recently worked on a large multi-platform project management app for a green energy fund (lots of fun with APIs!).

Throughout that time, technical debt has been a constant companion. Especially in projects which have survived for more than a year. Sooner or later, it starts to cost more to make changes, which sucks because change is a constant in a successful & long-lived project. Though I’ve lived through more than a couple of these, I’ve been lucky enough to have had smart and capable mentors showing me the way out. To ensure that a codebase remains a pleasure to work on requires a sensitivity to code smells, a toolkit with which to eradicate them and most importantly, a culture which encourages clean coding practices.

I’ve spent years trying to avoid crappy code and I think I’ve been successful – that’s why I think I can help make your codebase and subsequently your business better.

The term “Technical Debt” can mean many things. What areas do you specifically cover in your audit?

In the context of a Rails app, technical debt makes its presence felt in a variety of areas. I’ll focus primarily on how your codebase is architected. By initially running your code through a series of tools, I hope to get a good sense of your code quality and the areas which need the most work. I’ll then dive deep into a manual analysis of your codebase, bringing to bear my experience in the software industry and with Ruby and Rails in particular. I’ll also keep an eye out for any obvious security and performance issues.

I know I don’t need a full rescue (read: “I’m not drowning”), but could use advice on how I can reduce technical debt and ensure my team are using “best practices” so that we don’t end up needing a rescue. Will the Rails Code Audit be useful to me?

Props to you for being pro-active in ensuring your app’s health. We can definitely work together! I’ll apply the same rigorous process in analyzing your codebase and practices, and at the end of our engagement you’ll get a set of concrete steps you can take to reduce your technical debt. I’ll also familiarize your team with practices that will go a long way in ensuring that your technical debt problem is contained.

I have more questions

Shoot me an email with your questions, and I’ll get back to you ASAP.


How I’ll make sure that you’re 100% satisfied with the Rails Code Audit

My Rails Code Audits are borne from a career of building, maintaining and extending production quality software, both in and out of the Rails world, and bringing to bear this experience on your unique situation.

That being said, I don’t want you to pay me and that be it. I want you to pay me and make a significant return on your investment, however you choose to measure it.

But there’s rarely a “one size fits all” solution to anything. So if you do decide to buy the Rails Code Audit, and feel that it doesn’t get you any closer to where you want to be, then you can keep it and I’ll give you all your money back. No strings attached.

This is my 100% money back guarantee.


Ready to reap the benefits of a high quality Rails application?

I only commit to working on a few code audits at a time. This helps me offer the highest possible level of service while maintaining quick turnarounds.

As of now, I have the availability to work on 3 new code audits.

And when I say “I,” I do mean me, and only me. I’ll be your point of contact, and you’ll work directly and exclusively with me, start to finish.

It’s okay to say no.

This is only for businesses and teams who recognize that their approach to building Rails applications needs a change and are willing to learn and implement the processes, tools, habits and techniques needed to extend and maintain an existing Rails application for the long-term.

Cheers!

Sid Krishnan