Rubyists Should Learn from Ford’s Example

From the moment I laid my twelve year old eyes on the Ford Mustang, I was in love. But even before that, I remember taking road trips to Wisconsin, bouncing around in the covered bed of my dad’s F-150 pickup with my sister. Back then, we didn’t wear seat belts – my parents would lay down a mattress for us to play on in the back, while they enjoyed the eight-hour journey in relative peace and quiet up front.

I’ve been a Ford guy all my life. But in the 90’s, a disturbing trend began. Ford, and indeed most auto makers, started homogenizing their product lines.  As the “curvy design” fad erupted, Mustangs were redesigned to look more like the Taurus. And F-150’s were redesigned to look more like…the Taurus. I hope they saved a lot of money on design work, because everything had the same oval headlights and curved hood. Each model was trying to be everything to everyone.

Just when all looked lost, Ford came to its senses in the 2000’s. They started designing the cars so people actually knew what they were for. The mustang now looks like a muscle car:


The Fusion, which evolved from the Mercury Milan, now looks sporty, but efficient:


The Five-Hundred (which looks better in person) boasted size, style, and luxury:


And finally, the F-150 now looks like the workhorse it was meant to be:


Rubyists Can Learn from Ford

First, show intent. While code comments can be helpful, they can also be a crutch. Ruby is a wonderfully expressive language, so use it. Spend time naming your classes, modules, methods, and variables with the intent of having them be perfectly understandable to a stranger. When a method has several parameters, wrap them in a hash so developers (yourself included) can better understand what a method call is trying to accomplish. As a bonus, you won’t have to look up the parameter order every time you want to use the method.

Keep your methods small, and remember the old mantra: a method should do one thing, and do it well. But don’t stop there. Controllers shouldn’t be stuffed with dozens of actions; you probably need more controllers that each handle a more specific part of your application.

On a larger scale, don’t limit yourself to just one app. If your company or project is doing lots of different things, it may need several different apps. They can still talk to the same databases when they need to, and they can appear seamless to a site visitor.

Businesses Can Learn from Ford

A lot of businesses also make the mistake of trying to be everything to everyone. I see this a lot with consulting companies in my own industry. In order to cast the widest net, dev shops will take on any type of work, that uses any programming language or technology they have experience with. Sometimes they might not even have that experience, and that’s usually good news for me. Rescue projects are a big part of my business.

I’ve chosen to focus on the Ruby programming language, and I put my money where my mouth is when I chose my business name. That doesn’t mean I stop learning other technologies. It means that I choose to invest my limited time learning the technologies that will make me a better Ruby developer. Currently I’m digging into PostgreSQL, because it has so much more power than just database queries, and this will improve the performance of my Ruby applications. I also have several years of Perl experience, but I choose not to take on Perl contracts.

RubyCuts is relatively new. During the toddler stage, I’m more open to taking on lots of different types of projects. As we grow, we will focus more and more on our core – training, scaling, and rescue. Lots of developers can build basic applications in Ruby, but I want RubyCuts to be the Navy Seals of the Ruby world. I want to help companies solve the toughest problems so their dev team can get back to building money-making features. I want to make it as easy as possible for companies to invest in Ruby.

I think the future of small business is in specialization, solving very specific problems. The trick will be picking the highest value problems to solve. As Ruby gains popularity, I think the increased number of beginners will require an increase in experts. If I’m not successful in five years, you have my full permission to rub this article in my face 🙂



Posted in Business, Ruby.

Leave a Reply

Your email address will not be published. Required fields are marked *