Tag Archives: development

 Crossroads: For a Stronger Connection with Our Users

Why Crossroads?

Have you ever tried to understand how people perceive you? Do they understand just the way you want them to or do you need to put in more effort to get them to follow you?

Living is an art, a skill, a technique. You need to learn and practice it as you would a game or a musical instrument” – SWAMI PARTHASARTHY

Understanding something is also a technique. When we bring out a product, there is so much thought that goes into it, the design, the look and the feel. There are so many more unknown factors that we need to understand while creating a product that is used by a large and diverse group of people.

Report Bee, currently serves 132 schools, with over 5000 teachers using the software. Today, we can proudly say that on an average we have 600 users logging in daily to use our software. Our software has an array of products created to help teachers maintain their data about students better.  As of today, teachers can use the following features:

  • Records– to input all of students’ performance data
  • Insights– to analyse and compare results at all levels in an instant
  • Registries– to view consolidated results in one sheet
  • Report Cards– to generate personalised insightful reports for each student
  • Attendance– to easily manage daily attendance
  • Health Card– to be proactive about students’ health
  • Waggle, SMS– to communicate efficiently with parents
  • Parent Portal– where parents can view insights of their wards

Report Bee works with the vision to help the teachers record data easily by creating different features. As the days go by, we keep creating more and more features in the belief that they are going to be extremely useful for the teachers. Beliefs can sometimes be divorced from reality, especially with inadequate communication.

So, one day, we stopped and questioned our own assumptions:

  • Are the features really as useful as we deem them to be?
  • Are the teachers using them just the way we imagine or…?
  • Do we need to improve the feature and how?

In essence, we thought it was time to try and understand what the users really wanted in comparison to what we were offering them, and bridge any gaps that existed in effective usage of the software in its entirety.  We were convinced that it was time to see how the existing features were being used before creating new ones. It is one thing to create a feature, but having teachers not using them is the worst that could happen to us!

The Memorable Journey

Forming the Team: With this thought in mind, we formed a team to unearth the truth, calling the project CROSSROADS. The team from Report Bee was assisted by Wankai to conduct this user experience study. Wankai is an innovation-consulting firm that helps organizations and companies strive towards newer possibilities in their arena. They helped Report Bee to structure the entire process and implement the project. Thanks guys! The learning for us has been immense! 🙂 The final core Team of Crossroads included Jack, Jayashree, Karthik, Sharanya (from Report Bee) and Brijesh and Varun (from Wankai).

Crossroads Team all Set for Interviews!
Crossroads Team all Set for Interviews!


Visiting Schools for Interviews: The team then started the Crossroads journey. With a process in place, we visited 14 of Report Bee schools and interviewed the key stakeholders –Principals, teachers, students, parents, extended families. For each of the stakeholders, we had a list of exhaustive questions created by the team under Wankai’s guidance. For example, if the respondent was a parent, in all likelihood, he/she would have received the Report Bee report cards generated by the school. So, they were questioned about how well they understood their child’s reports.    Similarly, if the respondent were a teacher or a Principal, questions were based on the usage of the product besides understanding the Report Bee report cards.

An interview in progress with a Principal
An interview in progress with a Principal


We also, interviewed other educational stakeholders to understand their perceptions of our product.

All in all, we conducted close to 70 interviews spread over a span of 2 months. Phew! It was a marathon run for the Crossroads Team but travelling is always fun when done in a group! And the Crossroads Team enjoyed it even more as it was heartening to get real feedback on the product. Of course, all our travels included a day of sight-seeing! 🙂

Crossroads Team sight-seeing :)
Crossroads Team Sight-seeing 🙂

Making Sense and Incorporation of the Feedback: When all the interviews were completed, the Team (under Wankai’s assistance and guidance) rigorously and patiently went through all the interviews to make sense of each of the feedback to gather and compile the information. It was nice to see a coherent picture emerge out of this exhaustive process. Further, suggestions and domain expertise were used to improvise the product with further enhancements to reach the need of the educational stakeholders.

Crossroads Team Compiling Feedback and Discussing Findings
Crossroads Team Compiling Feedback and Discussing Findings

Wrap up with Surprises: The Crossroads findings were finally presented to the entire Team at Report Bee in a grand ceremony, marking it a significant day in the journey of Report Bee. What could be more important to us than introspecting our product and aiming to give the best quality to our users? 🙂 The whole Team had a fun day-out to absorb and discuss the findings. Facing reality sometimes can be hard, but when taken in the right way, it can lead to more positive solutions. This is exactly what happened to us at Report Bee.

Fun and Final Presentation to Report Bee Team at a Beach House ;)
Fun and Final Presentation to Report Bee Team at a Beach House 😉

We thank all the schools and teachers for having given us their valuable feedback. Today, thanks to Crossroads, we have become bigger and better in serving our teachers, understanding their needs and continuously learning in process! We will definitely be back for a bigger learning next year!



Creation Cricket League

We do love cricket. Just like Obama worries why US productivity goes down by 5% when Sachin bats, our productivity too goes down when some tournament is going on. We may be so-called nerds, but that doesn’t mean that we don’t having any coffee-break talks on cricket. But, if you are expecting this article to be some “pure cricket” article about Sachin’s paddle-sweep or Dhoni’s helicopter-shot or some cricket matches that are played by the RB Creation Team, then you will be disappointed.

This article is purely on how we leverage the sport to keep ourselves (Creation Team) creative, motivated and inspired. Above all, it keeps us in love with what we do.

As a Creation Team member, nothing is more exciting than:

  • Solving challenging problems with software programming (or)
  • Observing our customers consume our freshly brewed coffee … er,  code (or)
  • Getting into new challenges (projects).

Usually, by the general psychology of a developer, their motivation, interest or productivity reduces when a project duration increases. The project may become big or tasks may become monotonous.

All Project Managers, remember the formula: Productivity is inversely proportional to project duration or monolithicity of project.

Project vs Productivity

To avoid this we came up with three ideologies for approaching new projects.

“Test Match” Projects

These generally take 10-14 days for completion.

Any big project which we do – we logically separate it to smaller projects in such a way that the longest small project won’t exceed a duration which will make the developers lose interest. Instead of bombarding developers with the entire mission impossible target, we set smaller targets for the metaphorical morning session, post-lunch session and post-tea session. This keeps the developer’s mindset focused and clear. Generally, one to three Creation Team members are involved in these projects.

“The ODI” Projects

These generally take one to three days for completion.

These are usually small enhancements or feature requests from the customers or internal requirements. We sometimes take up these projects between Test Match projects so that the developers get an opportunity to refresh their minds for the next one. Generally, one to two Creation Team members are involved in these projects.

“The T20” Projects

We call these 111 Projects: One Day, One Team, One Challenge.

We sometimes stop all regular projects for a day. On that day, we take up one fresh project that would normally take around 14 days to one month for completion by a small team. The entire Creation Team sits together at the start of the day (we start really early on that day 🙂 ) and does everything.

  • Ideation.
  • Features brainstorming and freezing.
  • Wireframe.
  • Design.
  • Dev plan; smart task separation / delegation.
  • Front end architecture and development.
  • Back end architecture and development.

That is pretty much everything related to a project execution. It’s kind of a pure fun slogging where we might face unexpected turns and bounces in the wickets. We keep this project a secret from the other teams (Happiness and Growth). At the end of the day (a really looong day), we have something to surprise them and our customers with.

The “Practice Sessions”

Do we only play matches? No! Along with these projects, support tickets and small bugs are bound to come along. Usually, these won’t take more than one to two hours for completion. All developers are bound to work on such tickets along with their regular matches. They do these ticket/bug fixes either at the start or end of the day so that they can stay focused on their important match.

Till now, we are happy with this approach and the team is winning matches. All this can be brought down to one quote by God:

Any active sportsman has to be very focused; you’ve got to be in the right frame of mind. If your energy is diverted in various directions, you do not achieve the results. I need to know when to switch on and switch off: and the rest of the things happen around that.” – Sachin Tendulkar

Do you follow something different at your workplace? Do you have suggestions for us? Let us know below.

Apple vs. Microsoft

Okay, I admit that the title is needlessly kindling a fire. The Apple vs. Microsoft debate (war?) has been going on forever and has been beaten to death. I am not going to revisit it here. I just used it catch your attention. 🙂

The real title of this post should be Mac OS vs. Windows for software developers (desktop OS software only). There are so many other similar Apple vs. The World debates which I am not going to talk about. If you are interested in participating in any such mini-battles (like iOS vs. Android, iPhone vs. every-other-phone-on-Earth, Macbook vs. other-laptops), please visit our office. We have a dedicated Apple fanboys club. And if you are not an Apple fanboy yourself, be ready to listen to a lot of hogwash and feel the effects of a mini-Reality Distortion Field.

Now, let’s get down to the actual topic.

At Report Bee, we use a wide range of technologies to build our products.

  • Ruby on Rails as our server side software.
  • MySQL and PostgreSQL as our relational database servers. We even use NoSQL datastores like Redis and MongoDB.
  • Apache Flex, HTML-CSS-JavaScript as our client-side technologies, which include various JS libraries like jQuery, and custom-built JS libraries as well.
  • Statistical modelling and data mining: R (Programming language).

All our servers run a variant of Debian Linux which are all managed remotely.

Most developers at RB use the Mac operating system exclusively for all their development (the rest use Ubuntu Linux). Windows is conspicuously absent. In fact, I recommend all new developers joining us to get a Mac.

Why? Isn’t Windows the most used OS in the world, by far? Is it so bad?

No, not at all. Windows is an absolutely fantastic operating system. I recommend it to all non-developers, non-designers and Growth Team members. It does everything any layman or business user could possibly want and does it beautifully.

What Windows does not do well is cater to the users who want the power of the command-line or terminal shell, as it is called. And who wants this? Software Developers. Web Developers, especially.

Windows does have a command line shell. But it is woeful, to put it mildly. And it does not play well with most open source web development tools. That’s because most of these web development tools are built targeting UNIX.


This is where the Mac OS comes into play. In the late 90s, when Steve Jobs came back to Apple, he brought with him the NeXTSTEP OS, which was built on a variant of UNIX (FreeBSD). That OS is the root of the beautiful Mac OS X that we see today. In short, Mac OS X is built on top of UNIX.

That simple fact is the sole reason why I find Mac OS much more suited for heavy development. The bash terminal that we all love from the Linux world is available out-of-the-box on Mac OS. All Linux commands work with the same syntax. Web dev tools almost always have a package built for Mac first, because it is so easy to create it due to the UNIX heritage.

Sadly, we cannot say the same about Windows. Ruby on Rails especially, is almost impossible to work with on Windows. I say “almost”, because, there is a way around with Cygwin and Console2. But the setup is stupidly complex and time consuming.

Then comes all the supporting tools for web development, like IDEs, database clients, server management software, VCS clients, etc. Every one of those tools target Mac first, Linux second and Windows may come a distant third, if at all.

Another advantage of having a UNIX-like shell built-in to the OS is having SSH out-of-the-box. Any system admin would understand the power of SSH. Not having to use a separate software like Putty just to connect to remote machines makes life a lot simpler (especially when using public-private authentication keys).

In short, when developing web software on Mac OS, you can expect things to just work. What more could a dev ask for?

What about Linux?

Ubuntu is a very mature and extremely popular distribution of Linux. Theoretically speaking, this could be the first choice for all web developers.

But two things let Ubuntu down.

1. Polish

The desktop Ubuntu OS comes with glitches. Lots of them. The level of polish that you see with Windows or Mac OS is just not there. Too many straightforward tasks degenerate into messing with system-level files with the command line. This may be fine for a home enthusiast or hobbyist. But the time wasted is just not worth it for a professional.

2. Support from the big companies

Companies like Adobe which make a lot of tools for web development just do not concentrate on Linux as a platform. So, if you rely on tools like Photoshop, Flash or Flex, you can rule out Linux right away.

I hope I have given a small insight into why I choose Mac OS for my development. Whether you support my views or not, let me know in the comments below.

Meanwhile, enjoy these classic ads.