We took the red pill

Going through innovation is always the toughest path. When I think about Ruby On Rails “way of doing things” I always think about innovation.

The old way of coding MVC applications seems to me so damn complicated: no need to learn lots of of frameworks, integrate them together, without being completely sure to have a clear understanding of how things work, actually.

Taking the bandwagon of Rails “way of doing things” is like choosing between the “blue pill and the red pill”: we took the red one, being absolutely sure it’s going to be a winner in the web future.

How can I say that? Almost one year ago we got urgent a problem to be solved in our firm.

We had to streamline the process of Order Management for every engagement sold. We are a small company and buying a new module in our “ERP” (a big word to say “Accounting” for firms like ours) could seem the simplest way to address this organizational problem, but “eat your own dog food” prevailed.

After having thought for few minutes it was clear to me that this necessity could be the perfect test bed for Ruby On Rails. Normally we used to go through those kind of small apps using PHP or Java. I estimated we needed at least 4 weeks elapsed to complete our Web application, including a small analysis, coding and test.

Thinking about the requirements we got, the application seemed quite simple. So, why did we have to spend 4 weeks for a simple task like that? That was enough. I chose to challenge my team using Ruby On Rails to implement what we needed, adopting an agile methodology I sketched out in that period.

The teams feedback to my proposal was enthusiastic! I discovered that two of ours developers had already read something about Ruby, playing with it in the past months. An “8 day delivery challenge”- as we called it – began.

I was really amazed about how fast we could do stuff choosing the right approach: a simple methodology and an easy to learn framework. For the first time we could concentrate on the functionality instead of technicalities.

Simplicity instead of complexity. At day number 9 we were delivering a presentation of this new application we built to the firm. Then we collected some feedback and suggestions, and 7 days later we released the project.

After 15 days we got the first release working in production. It has been a success! We spent 50% time less. Our firm could see things happening quickly. The team could change assignment being completely satisfied.

Something special took place that day – something that improved our delivery skills a lot. Something magical happened.

Leave a Comment