Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Appointy Nine – Why We Scrapped Our Code That Took 9 years to Build

DZone's Guide to

Appointy Nine – Why We Scrapped Our Code That Took 9 years to Build

This article is about why, and how, we were able to scrap 9-year-old code, and started thinking about it in a fresh new way.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Appointy in the Making

aircraft-74020_640.jpg

Between 2004 to 2006, we developed websites over WordPress for the Health and Wellness industry. There was a WordPress plugin for almost every need – except a scheduling plugin. We got so many requests for a scheduling plugin, that we could not keep up!

So, we wrote our own script. A script that would allow us to save time by not having to build the same code again and again. One of the first challenges that we faced was that every vertical has specific requirements. So, we created scheduling rules to generalize our script for different verticals.

Soon the demand for scheduling increased and Appointy first went live in January 2008 with our “Do it Yourself” concept.

Unfortunately, in our zeal to please every customer, we kept on adding features and Appointy became overwhelming. And then the same customers started complaining. We realized that we were moving away from the Do-it-Yourself concept. So we went back to the drawing board with the idea that it needed to be made simple again while keeping the functionality.

It cost us a whole year, but we learned an important lesson.

Appointy is a bootstrapped company (we never raised any external funds) and had to make money from sales in order to survive. We believe that the best way to make money is to solve someone’s problem first and then ask for a fair price. The more we can help our customers, the more we will grow.

We started improving our onboarding and support process. But we soon realized that every business is unique in nature and needs something different. It simply meant that we not only needed to add to our support team but also that we needed to get more programmers. We needed a way to scale vertically in all departments.

So, we started hiring more programmers. After a few months, during a Scrum meeting, a new team member shared that he was happy that something that he had written was live on our production site. For him, it was definitely an achievement. However, I was not happy. I realized that there is something wrong in our setup if it is taking months for new programmers to becoming productive.

It was time to move out of our comfort zone and make some bold decisions. We could simply not scale as quickly as we wanted at this rate!

One of the Hardest, But Best, Decisions

one-way-street-1991865_640.jpg

The next day, I talked to a few senior guys and tried to understand the problem. The problem came down to the architecture that we created 9 years ago. Technology is changing every year and so technically, we were almost 9 years behind.

I did not know how to tell my team to change the entire code they have been writing for 9 years. I didn’t want to look crazy and decided to first take the plunge myself. After all, I was once a programmer (and a pretty good one at that!).

I always write down an objective before starting any new task. So here was my objective – Create a modular architecture with a learning curve of less than a week and develop a blazing fast app.

If Google can fetch the right results from trillions of rows in less than a second then why can’t Appointy?

I came across a term RxJS on Angular.io. Followed the topic for a few hours and really liked the idea of streaming the data. The concept was simple: would you watch a video on Youtube if you had to wait 5 minutes every time you wanted to watch?

I decided to give it a try, but the reality was I couldn’t do it myself. I would need help from the senior guys.

After my research, I explained the streaming concept to my team and tried to create interest. For the next few days, I continued the process until our rock stars (who are way better programmers than me now) picked up the rhythm. The first seed of change was sown.

In a few days, we were able to implement the entire streaming concept in the existing code of Appointy. As expected, it was working well but was not great. We needed to do more.

Time to Alleviate the Suspense

sherlock-holmes-931897_640.jpg

There were 2 more issues that still needed to be addressed:

  1. User Interface and User Experience (UX/UI).
  2. Loading speed.

One-and-a-half months had already gone by and we had only gained knowledge; no action had yet been taken. I was not able to ask the senior guys to work on UX/UI yet, for fear of how they would react to scraping the old code.

So, I decided to work with one of the interns we had hired. This new intern had a different approach to coding. He wanted to be fast, faster than anyone else. He helped me implement tools so that I could check the changes live and give him feedback instantly. We both started coming in early at 6 am and by the time our office would start, we would already have put in a few hours of work. The new product started taking shape.

After a few days, I realized that everything was working great. We were on track and it was time to bring our work to the entire team. Now I had some proof-of-concept to justify that 9 years of code can be scrapped, but not without our rock star team.

The day arrived. We showed the team the new UI and explained the next steps to go live. Our rock star team started believing that it could be achieved. That was just what was needed.

Now after 4 months, our version was in the testing phase.

Result:

  1. We are able to reduce the “Admin Area” load time from 10 seconds to 2 seconds (yes, 5 times faster!).
  2. We are able to reduce the load on our servers by 50%.
  3. We are able to get new programmers productive within a week.
  4. Finally, I got the time to write a blog.

What came next?

  1. The first step was to port the existing software. Next step would be to build badly needed features (we had been compiling feature requests from our customers and our priority list was ready).
  2. Our API was ready which could either be used by our team or external teams to integrate different apps. For example, we would not need more than a week to add a new payment gateway anymore.
  3. We would have more bandwidth to tie-up with other companies who could add more value to our business. We were already tied up with Reserve with Google to help get new customers.

During these past 4 months, our productivity has increased so much that we have not only recreated Appointy from scratch, but also successfully created another conference room scheduling product from scratch!

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
agile ,development process ,scrum ,web dev

Published at DZone with permission of Manish Sharma. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}