Every company has a process that dictates how an idea might go from someone’s head to a user-facing product. The robustness of this pipeline from concept to creation is an essential part of a company’s ability to function, and the process at Jana is one of the reasons I love working here so much.
Our system combines some of the best properties of several development methodologies to define a procedure that is both agile and well-organized, with a nice balance of self-determination and management and senior developer oversight. The following describes how one idea I worked on, a redesigned home page for mcent.com, went from the planning table to live on production machines and beyond.
Step 1: Put your idea out there using issue tracking
At Jana, we have several sources of ideas; most frequently, they come from employees who notice a bug or have a feature request. Any employee can make a ticket, and we are often encouraged to make any tickets we feel might be helpful to the company. Often ideas for tickets comes out of chats in Slack- we have a chatroom dedicated to weird behavior people have noticed and discussions frequently lead to the creation of tickets. Another source of tickets is Sentry (https://getsentry.com/welcome/), our automated monitoring system, which we’ll cover in a future blog post.
The idea for a redesigned home page was, as one might guess, not the result of a reported error but rather someone’s suggestion: A few weeks back, we removed the ability to sign up on mcent.com. As a result of this change, our home page at mcent.com felt a little outdated.
The old home page
It still presented people with a login page to the web product, which in comparison to our android app is quite threadbare now, especially considering the fact that app installation offers are becoming more and more the focus of our business (which is incidentally the reason why we removed signup on mcent.com). Our UX person, Rob House, felt that it would be better to have the focus of the home page be directing people to our android app. He suggested that idea to everyone at Jana by creating a ticket.
An example trac ticket
In the description of the ticket, Rob detailed the reasons why he thought redesigning the page would be a good idea and posted mock images of a potential new site. One of our product managers, Yoav Shapira, reviewed the ticket, liked the idea, the reasoning behind it, and especially the new proposed designs, and gave the go ahead for the ticket. He ‘assigned’ said ticket to me, which meant I was now the ‘owner’ of the ticket, effectively adding it to my queue of things to do. That queue is largely self managed with prioritization help from product managers, something I have found quite nice: it allows for a good balance of picking what you want to do without having to wonder if what you are doing is really relevant or not.
Step 2: Iterate on implementation of the idea
Once Rob’s redesign ticket reached the top of my queue. Once a ticket is in progress, it is pretty typical that some discussion goes on in the trac page asking about clarifications, edge cases, prioritization, etc. On this ticket, I asked about css properties I was unfamiliar with as well as what to do about people viewing from mobile phones- I was able to get input from several people in the company more experienced with frontend development than me in a very short time because my questions and concerns were clearly communicated on the ticket.
With those people’s help, I was ready to take a crack at making the new page. All new code is created on branches of our main ‘production’ code in github- I branched off from prod and started coding away. Once done with my first iteration, I submit a pull request on github with a link to the trac ticket. We work hard to keep the implementation pipeline running smoothly- one of the things we do to ensure this is with our githooks. They block any commit that does not include a ticket number (and also check for debugger lines and the like). Another measure we take is automatic runs by jenkins of our unit/code quality test suite against new commits that end up in github as checkmarks or x’s next to the commit. This has been really helpful in keeping our codebase clean and free of errors- the suite runs both unit tests as well as various linters to make sure our code is nicely uniform and easy to read and run.
Green checkmarks and red x’s indicating unit test status
We also link from the ticket to the pull request- For our example ticket, I made screenshots of the new home page on desktop and mobile phones in both landscape and portrait mode and uploaded them to the ticket along with a link to the pull request so that people could see the new page without having to clone the branch and run it locally. Both Rob and Yoav then reviewed the images and code on github, making comments and suggestion where they saw fit. After a few iterations, the pull request was ready to go live, and Yoav merged it into our production branch. The review process can be tedious at times, but ultimately it ensures our code is high quality and consistent with itself, and allows me as a developer to feel more confident about changes I have made. Rob and Yoav’s suggestions definitely made my code more robust and made it produce a much better user experience.
The new home page after review
Our process made it easy for me, someone who is fairly green when it comes to front end development, to create a really nice looking, responsive web page.
Step 3: Deploy the Code
Once the code has made it onto our main code branch, our production machines need to grab and start running the updated code. Before code changes go out to real production machines, we run unit and integration tests against them in a staging environment, which has been helpful in parsing out issues in the code that may not be apparent in local builds. We have a monitor for these tests as well as email alerts that keep people aware of currently running deploys.
The Monitor- green is good!
Once the code has passed staging it is deployed out to our production machines and its now user facing- you’re done! Or are you?
Step 4: Followup
The final step in the process is following up on your work. For our example ticket, there wasn’t much followup to do: on the ticket I marked my work as done and created a link to the release notes detailing when it went live. Rob then verified it by checking out the live site, mcent.com, and closed the ticket.
However, for many tickets there is a decent amount of followup that can be done; one of our core values is ‘Measure It’ meaning we want to see the numerical impact of things that we do. Another ticket I worked on was about preventing users from trying to game our app by signing up and completing the same offer over and over using emulators and other tricks- while I can’t go into lots of detail for security reasons, the work on that ticket wasn’t really complete until we measured the impact of the changes. This involved creating events that fire every time we prevent the wasteful behavior I described earlier and a graph that looks at those events and plots them over time. It has been instrumental in measuring the effectiveness of the work I have done and personally, I think it’s really cool that I can see exactly how many people my work is impacting.
An example of one graph on our dash board
I can’t overstate the value in having these visualized measurements of the impact of our work- we also have graphs of key company metrics, and it is always interesting to note the trends on our various graphs and extrapolate as to why they might be happening. On more than one occasion, we have noticed bugs or opportunities as a result of looking at these dashboards.
So there you have it! Jana’s process for taking an idea for our product and bringing it from concept to implementation to points on a graph. One of our greatest strength is our process; it allows us to easily communicate our thoughts to the rest of the company, enforces a high code quality standard, minimizes the amount of bugs we deal with, and makes it easy to see what impact you and others have had on the company.