Discover if your Rails Project is out of control and about to crash
Hopefully before your business and career crash
“Ronny, we need to talk” was the only thing the email said.
Jake has always been a great lead developer. He understood the problem, delivered mostly on-time, and was friendly with the new junior developers. But most of all, he wrote great emails and was never cryptic.
What could be so wrong, Ronny wondered.
That one meeting
“Thanks for meeting with me Ronny, I’ll get right to the point” Jake said. “We’re not going to be able to do the WhizBang”
“By this Friday?” said Ronny, “I guess we can push back the deadline a bit.”
“No. Not ever. Well, at least for a few months.” said Jake.
“What? I don’t understand.”
“Well, you see… you remember that DooHicky feature we added in January and had to rush to fit it in before the launch?” said Jake.
That other code
“We didn’t have enough time to do it right. I mean, it works and all but we had to jimmy-rig it and it wasn’t ever really tested. That was fine because post-launch we were going to come back and fix it, but… well you know” said Jake trailing off.
“Yeah, I guess we got busy and forget about fixing it. But how does that affect WhizBang?” asked Ronny.
“I’ll give you the high-level summary. To make DooHicky work we had to touch every part of the code for users. Which, pretty much means every part of the code.”. Jake smiled at his little joke, before continuing.
“The problem is that WhizBang needs that exact same thing. Normally, we could just add it into the mess but Andrew discovered that in a few major components, they are flat-out incompatible.”
“Incompatible?” questioned Ronny.
“Yeah, like we can either have WhizBang or DooHicky, but not both.”
“But we need both”. Now Ronny was starting to worry.
“Yeah I know, but we need a major restructuring to make it work. A few months at least.” countered Jake
“We don’t have a few months. We need to launch WhizBang next week.”
“Can’t you get more time from the executive committee?” asked Jake
“I can try. This is our third missed deadline this year. And I don’t think they’ll be okay with a slip of a few months. There’s a lot riding on this release.”
“I’m sorry Ronny. I just found out today. Andrew has been working nights on this and he’s completely given up.”
“You didn’t hear? Oh man. Yeah, Andrew’s been putting in 70 hour weeks on this and has burned himself out. We all have been, but he’s had enough. HR just talked to me that today is his last day. Doctor’s orders.”
No way. Andrew was the original architect of the entire system. Losing him will hurt the team.
“I didn’t know. I just got in from a meeting with the QA department. They had a lot to discuss” replied Ronny
“Yeah. I’m going to invite Andrew out after work and try to see what I can do, but from what I’ve seen we’ve lost him”
“Alright. Well, I have a meeting with the executive committee in six minutes. Is there any good news I can give them?” asked Ronny
“We fixed 12 bugs this month. But there are still 100 more” said Jake “At least there’s that”
“Thanks Jake. I’ll see what I can do but get ready for a few bumps.”
Later in the conference room.
“So let’s get this straight Ronny. Your team has had four weeks already and is supposed to deliver WhizBang to us in one week and now you say it can’t be done?” asked Darrien
“Our lead developer and the chief architect have been…”
“Yes or no! Next years revenue is riding on WhizBang to get us out of this financial hole. A hole caused, I might remind you, because your team missed the opportunity with McMacroWare!” yelled Darrien.
“Yes” whispered Ronny.
“Look Ronny.” started Melissa, “I know you know how important this is to all of us. But we’re bleeding cash here and we need this done to make my numbers work. If we can’t, we’re going to have to let people go.”
Melissa was right. She knew the numbers like a hunter knows the forest. Maybe even better, because she doesn’t wear orange to let you know she’s there.
“Ronny, I’ll make this clear.” said Darrien “You find some way to deliver WhizBang next week like you promised, or we’re cutting off your team. We can’t have one department screwing up this entire company. A company my brother founded!”
Darrien had a point. But how did they get into this mess in the first place?
This is not an uncommon story
Though fictionalized, similar scenes play out all the time. Some less intense, some more.
A team is doing good work, with great people, and then they slowly start sinking.
Little by little the project starts to go bad. Sometimes they notice it early and can correct it. Other times, well, let’s just say that pretending the problem isn’t there doesn’t work with software projects.
When a Rails project goes bad
Too much work. Going too fast. Inexperience. Communication problems. There are countless reasons why a Rails project can go south.
But there are some common variations.
What used to work great in development and under basic testing, starts to fail with real traffic levels. Maybe your application become more popular than you thought (congratulations) or maybe it’s just hitting some performance stress points that you can’t solve.
Other times the performance has been decreasing little-by-little over the past months or years. You can’t pinpoint one thing that slowed everything down, but it’s visible to your team (and your users).
One Person or Small Development Teams
Great applications can be built with small development teams, even by just a single developer. But if there is a single problem with small teams, it is that it can be easy to lose perspective. This makes innovation difficult as well as amplify any problem outside of your small team’s experience.
Rails applications aren’t supposed to wake you every night at 3am to reboot the servers. They were meant to run and run and run.
Instability in your application or infrastructure prevents you from helping your users. Over time this will frustrate them and it will affect your business. Unhappy users are tomorrow’s ex-users.
One of the most painful situations occurs when the communication within a team breaks down. The code will still get written and work will still get done. At least for a little while…
… but eventually the application will come to a grinding halt.
Each communication problem with a team is like an infected cut. Treat it quickly and you never know it happened. But let it fester and you could lose a limb or worse.
The worst about communication problems? They sneak up on you. You can’t see them unless you actively look for them.
(Actually, communication problems are the root cause of many of these other types of problems)
The Outsourced Project
Working with people worldwide is great, especially when you can get your application built quickly and inexpensively.
But six months later that inexpensive application might start showing its warts. Features that were done, now don’t work. Bugs that were squashed have come back with a grudge. All of the recent development has been slower than before.
The Big Port
Remember, no one is to touch that old Windows NT server. The one with “The Application” that the business relies on. That was produced by a company that has since folded.
Your team has tried to rewrite and port it to Rails, but every time something gets in the way.
The Prototype in Production
Your first prototype version of your application was great. Your users loved it, it worked, and it let your business get off the ground. But when it was created, it wasn’t ever supposed to last this long. Temporary fixes became permanent. Band-aids and scaffolding were never replaced.
Now’s the time to go back and start correcting the mistakes.
You weren’t sure if your idea would work. Even with some early validation, you were always wondering if this application would build your business.
You were right, but now it’s time for the next version. Time to clean away the cruft and failed experiments so you can grow your business to the next level.
But How bad is it? Really?
Whatever the reason, if you think you might have a Rails project in need of a help, you probably do.
But there are degrees of how bad it might be:
- Your project might just need a bit of focused effort to get back on track.
- Or maybe a few months.
- Or, unfortunately, it might be so far off that it’s a better decision to start over.
In order to know how bad it is though, you need perspective.
Do you have the right perspective?
You’re living with the project. So is your team.
You’re perspective and judgment is clouded because you’re too close and emotionally invested in the project. That’s not a bad thing, but you’re seeing the facts with your biases.
Think as if you’re lost in the woods. You’re upset, confused, and it feels like every tree looks the same. You can only see 15 feet around you. But a rescue helicopter would have a completely different perspective. They can guide you out to safety.
Sometimes you need that rescue helicopter in your Rails project.
Rails Rescue Review
The Rails Rescue Review is a step-by-step process to use my outside perspective and experience to give you that objective feedback you need on the project.
Are you lost in a 1,000 acre national park? Or just in someone’s backyard?
But more than just that, you’ll also learn what you need to do in order to get out of the woods completely.
After many years of working together, I can say with authority, that it’s a privilege and a delight to work with Eric Davis. For many years he has been the sole developer behind our most critical business software which manages our teams, projects and finances. Recently he helped us transition to our in-house team by spending a week training us. I along with my dev team had a wonderful time collaborating with him and now find the process of updating and deploying our own code to be easy and inspiring.
Eric is extremely well organized, unusually adept at setting expectations, and has an uncanny ability to identify and adopt cutting edge technologies just as they become stable but before they become popular. He is a rare gem. I can’t recommend him enough.
Partner, CTO at Modern Tribe, Inc.
The Review Process
Each Rails Rescue Review follows a set process that I’ve used to identify problems in Rails applications since 2005. The review process will identify:
- What things your application does well and will contribute to its health
- What problems your application has that you can fix
- What areas that have the potential to cause problems in the future, so you can protect against them
Specifically you’ll get:
- Series of interviews about your application with me, an experienced Rails developer who has worked with Rails since 2005.
- Summary audit of your entire codebase to pinpoint problem areas, covering dozens of review points.
- Detailed audit into the three most problematic areas with detailed, line-by-line feedback.
- Set of items for your team to start reversing the downward trend in quality, along with effort and return estimates so you can choose the most valuable ones first.
- Six month plan to perform the rescue yourself.
This will let you improve any Rails projects without the time, expense, or shame of a full rewrite.
Q: My application is small, does that matter?
Not really. Even small applications can get themselves into trouble. A benefit you have is that there is less code in total so repairing it should be easier.
A review can also double-check that a small application is growing in such a way that it doesn’t develop problems later on.
Q: What if my application is huge?
Every huge Rails application can use a review. Once you get above a medium size (around 20K lines), the sheer number of classes and objects used means there are going to be trouble areas.
Even a well-designed, maintained application can use a Rails Rescue Review to spot potential future problem areas.
Q: We don’t have any tests, will that hurt the Rescue Review?
No, not having tests or having an old test suite will not hurt the review at all.
They will count against your application because tests are vital to the long-term health of your application. But you can still get a Rescue Review without any tests
Any application without tests is already at a high risk of needing a Rails Rescue Review
Q: I don’t have a team anymore, how can I do the actual work?
Sometimes the original development team has left a Rails project, without appointing a successor. If this happened to your or if your team left with no warning, it can be difficult to hear about all the work they left behind.
You don’t have to be left in the cold though. After the report, if you’d like help repairing things I can help do that for you.
Q: How long will it take to deliver the Rails Rescue Report?
Since each report is customized for the application, it can take a week or two to perform the review. After signing up you’ll get a firmer commitment based on the current schedule and your application size.
Q: How much time do I need for the interviews?
The interviews will range from 30-60 minutes each and there could be up to three of them.
Q: Can this be done discreetly, without my team knowing?
Yes. Just let me know in the order process.
Q: Can this be done discreetly, without my manager knowing?
Yes. Just let me know in the order process.
Q: My boss doesn’t understand how bad things are, can this be used to prove to them that we need a rescue?
With any bad news, having an unbiased third-party presenting their findings can add some weight to a debate.
If it will actually convince them that a rescue procedure is needed? It depends on your boss.
Q: My team is already going at 110%, how can we find time to do everything here?
It can be tough if you’re already completely busy. In the review I’ll help highlight options but some general ones that can work for most people are:
- Slow down feature development and use that time to repair.
- Take longer on each feature and might small improvements in the area the feature affects. (Boy Scout rule)
- Hire help. Hiring an employee or specialized consultant might give you enough breathing room to start repairing things.
I hired Eric to write a plug-in for the open source ticket tracking platform, Redmine. He was a great help from the start by helping us define what we needed and how we wanted the plugin to behave. He delivered the project right on time and at a great price. It worked like it should and continues to be an often downloaded plug-in for Redmine users (leaving the plug in open source was our choice). I highly recommend Eric for any Redmine development (or any Ruby work for that matter).
CTO, Fishpond Ltd
Q: Do we have to follow the six month plan?
No. The six month plan is just a recommendation. If you follow a similar, but different plan, that might work just as well.
But remember, decisions made in the past are what got the application to where it is now. If those same decisions will made over the next six months, you can’t expect things to be different.
Q: Can the review focus on one component of our application?
Yes. This is great for larger applications or ones where there is a troublesome component.
Just let me know in the order process.
Q: My application is split into several smaller applications. Do I need to buy a review for each one?
It depends. If the smaller applications are actually integrated into a whole “single application” like in a SOA approach, one review should be sufficient.
Ask in the order process and we’ll work something out.
Q: What if my team doesn’t like your recommendations?
Then ignore the recommendations. You’re not going to be forced to make the changes recommended. You can ignore all or some of them. It’s more important that the root problems are recognized and repaired, even if the method used is different.
Q: Does the review cover non-technical parts of the rescue?
Many parts of a software project are non-technical, the largest being the team who is building the project.
The Rails Rescue Review will cover some minor non-technical areas. Reviewing the larger, major non-technical areas would need a review that covers more than a few interviews.
Q: Can I keep working while the review is in progress?
Yes, oh course. You might want to schedule and plan some time after the review to implement the recommendations but while the review is going on it shouldn’t matter.
Stating the oblivious of course, changing a portion that has already been reviewed will affect how useful the recommendations are for that area.
Q: We use Agile/Scrum/Waterfall/Sprial/Lean/etc methodology for our development process, can this review work with that?
The Rails Rescue Review can work with whatever process you use for your software development. A more agile one will work better because you can incorporate the recommendations into your development but any process would be fine.
Q: Can I delay the start of the review until later?
Yes. Just let me know in the order process and the review can be delayed.
The Rails Rescue Review Guarantee
If during the review or for up to 30 days after you get the final review, you don’t feel that the review was valuable, you can ask for a full refund.
What to do next…
- When you’re ready for a Rails Rescue Review, click the link below. Your order will be processed immediately, this ensures your spot in the queue.
- You’ll be sent to a private website where you’ll provide details about your Rails application and any specific problem areas.
- Along with your application details, you’ll be given the steps to send your code for analysis.
- After this, you’ll schedule the first interview to kick off the project.
Don’t worry about remembering each step though. They’ll be outlined for you throughout the process. The only thing you need to do now is to click the button below.
So far all my clients love Redmine Timesheet Plugin as a billing tool as well. With your plugin, it is extremely hard for a developer to pad hours without getting caught by the client.
Actually your plugin is exactly what we have been wanting for over 5 years.
P.S. Having a troubled project can be a trying time. Not only is the work difficult, but that feeling of being in trouble with no solution in sight can be demoralizing. The Rails Rescue Review is here to help guide you towards a solution.