Part 2: History of Sider the Code Review Support Service
To mark Sider’s participation in this fall’s GitHub Universe as a sponsor for the first time, we are publishing a three-week-series. In these posts, I am writing the stories from the beginning of my entrepreneurship to the present where I provide the code review service, Sider.
Last week, in the first post of this series, I talked about how I, as the CEO, aspired to be an entrepreneur, and how I finally launched Sider. This week, I’m going to tell you about the history of Sider.
Recap from the Last Week
With experience in app development since college and project launch at companies, I decided to set up my own business that solved problems and finally founded a service that supported code review. As you can see in the former company name, SideCI, and the current product/company name, Sider, I named my company with hope and goal that it will be right by your side, developers, and support you as a mentor, partner or colleague.
Development of SideCI Prototype — Jan 2014
After many twists and turns, the code review automation tool “SideCI” (It is currently Sider. See the previous post.), which I proposed the initial idea around December 2013, finally began the actual development in January 2014. Because I had hearing sessions with my friends who were CTOs and found that there were issues with code review processes, we started developing the prototype that solved those issues.
By the way, the team members at the time were three programmers including myself. I took care of all the tasks other than programming by myself.
The prototype decompressed the zip file with source code uploaded on the server-side by a user and displayed the results analyzed with rails_best_practices gem in HTML. When I think back, I don’t understand why I thought this was the Minimum Variable Product at the time. Obviously, this is not much different from executing the gem on the command line on my computer. Maybe, it would be easier to execute on the command line.
However, when I was developing, I used this prototype to have the user hearing sessions.
The Release of SideCI Beta Version — April 2014
After having the hearing sessions to find out how developers were reviewing code and whether this MVP made code review easier for developers, many developers said they were reviewing code on GitHub Pull Requests, and they wouldn’t compress source code into a zip file and then upload because it was too much work. We thought working with GitHub Pull Request would bring us more seamless workflow. As a result, we decided to make the SideCI beta version that was integrated with GitHub.
With the concept of code review automation, the beta version analyzed all the commits on the static analysis tool and made comments on the results using the GitHub Commit Comment API. You could implement analysis by using git clone on Heroku and calling the analyzer with Kernel.#system.
But this beta version had two critical problems. One was the memory usage. Even with PX Dyno (8 core processor) which was Heroku’s maximum spec, memory was insufficient for analyzing code. Another problem was that rails_best_practices often died with the parent process (Rails application layer). So, the system was really unstable.
On top of that, the minimum server structure required four PX Dynos on Heroku and costed US$2,000 monthly because we used a tightly coupled microservice architecture. The expense was too much for a beta version which didn’t generate any revenue yet.
Also, regarding the product functionality, the beta version analyzed and made comments on every commit, so notifications were too annoying. After releasing the beta version, we changed the timing of comments to when a pull request was created and updated.
Transfer to Docker — September 2014
The SideCI beta version’s “execution after calling Kernel.#system on Heroku” was unstable. There was also a security concern when parallel-processing. For those reasons, we changed to the Docker-based architecture. We moved the system from Heroku to AWS, ran the Docker container on EC2, and connected the container via SSH. Performing git clone and implementation of code analyzer were done in the container with this setup.
Processing improved with this method compared to the beta version ran on Heroku. However, this new method still had issues: it sometimes didn’t process Docker instances and didn’t finish the process that was out of control in the container. Unfortunately, the beta version was still unstable.
The Crash of Ineptitude — November 2014
Start-up companies often experience “Crash of Ineptitude (a period of the lowest point of business after a stagnant period shown in Paul Graham’s diagram of the start-up curve).” In November 2014, Sider experienced the crash of ineptitude, our first crisis.
In addition to the unstable system, the relationship between members also became unstable. As a result, the team was broken up and I was left alone. I took care of everything while operating as the CEO and CTO.
Designing from Zero — February 2015
After team members left, the company was provisionally run by two people: a freelancer and me. First, to solve the unstable system fundamentally, we reconsidered the architecture. Specifically, we decided not to connect the Docker container via SSH. Instead, we decided to call commands such as
docker exec rubocop -R dirname from Sidekiq’s Worker process. When Worker process or Docker container ran out of control, you could kill it because we made a new structure with a middle layer between Rails applications and the code analyzer. We also changed the method of displaying analysis results: each static code analyzer’s results were converted into a common file type and sent to the GitHub API.
After that, SideCI briefly had a testing and deployment functionality. It was back in March 2015, SideCI literally became CI for a little while. With this change, we tried to scale out the business from a code review automation service to an overall CI service. But we decided to leave the CI business quickly because many people told us “the CI functionality was unnecessary because they would use TravisCI or CircleCI instead.”
Expansion of Programming Language Support — July 2015
SideCI was a CI for a short period of time. However, by changing to the Docker container and converting the analyzer’s results into a common file type, adding new analyzers for different languages became easier. Since SideCI could support various programming languages with the addition of new analyzers, SideCI started supporting languages other than Ruby around the summer of 2015. It was the first step of expanding multiple language compatibility. Sider now supports over 20 code analysis tools. Also, we decided to focus only on code review again as we were discontinuing the testing functionality. This was the period when we started operating as a service focused on review automation.
1 Person to 3 People — November 2015
SideCI on a new journey gradually gained new team members. The first who joined was Pocke. He joined us as a part-time student employee in October 2015 after I found his tweet on Twitter while I was ego searching SideCI. Pocke continued to commit on RuboCop (OSS) while developing SideCI. He eventually became RuboCop’s core committer and started working with us as our technical advisor in April 2018. In November 2015, another developer joined us as VPoE and a board member. Actcat, Inc. was finally run by three people.
Raising Capitals(#4) — March 2016
We did our fourth capital raising for business expansion since new members joined and the product was performing smoothly. At the time, SideCI already had a function that automatically created pull requests that fixed following comments. (This is discontinued now.) In April 2016, SideCI launched the official version.
The Release of Technical Debt Kanban — August 2016
A couple months after the official launch of SideCI, we released “technical debt kanban” which visualized technical debts. This function solved the developers’ issue: “wanting to pay off the technical debts but unable to.” In the start-up phase, programmers often focus on releasing all the functions first whether the code is good or not, then paying off (as known as refactoring) the technical debts that taken on earlier, similar to financial debts. We created the technical debt kanban to help developers to pay off later. The kanban system used the static analyzer in the background, prioritized the analysis results considering the frequency of edits of the files, then displayed in the popular kanban style that Toyota production system and Agile development used.
Award & Another Crash of Ineptitude — December 2016
SideCI’s business was finally getting on track. At the end of 2016, Ruby biz Grand prix awarded SideCI with the special prize for the quality/disposition of our code review support, the product itself, and the contribution to the Ruby community.
However, another crash of ineptitude came to SideCI. A couple days after the Ruby biz Grand prix 2016, the VPoE told me that he wanted to leave the company and actually resigned. At the time, we were actually raising capitals, and it had been only 4 months since the VPoE took the board member position. The team members including myself were shocked by this unexpected event. Chaos came to the team once again.
As an emergency measure for the VPoE’s resignation, we took on a new personnel structure and the Scrum product development. At the time, we had Soutaro Matsumoto, who was a long-time CTO at his previous work, so we appointed him as the CTO to replace the VPoE how just left. Since the VPoE was gone, and I, the CEO, was busy getting funds, we decided to adopt the Scrum approach to countermeasure issues caused by the absence of product managers. We set up an organizational structure which enabled the CEO to barely prioritize the product development. That was how SideCi started the year 2017.
SideCI’s Review Flow: Comment to WebUI — January 2017
The earlier version of SideCI made comments on problems in the code on GitHub’s pull request. This method had benefits: reading comments were more comfortable, and reviews were completed on GitHub. On the other hand, there were issues such as not being able to or taking a long time to open the pull request page when there were many comments, and notifications on Slack became too frequent when Slack and GitHub were integrated. To solve these issues, we worked on improving the user experience.
We changed to display comments on WebUI. Additionally, we added this function that users could ignore SideCI’s comments. The purpose of the change was to learn whether SideCI’s comments were valuable or not, and how users were reacting to the comments. If we could know whether comments SideCI gave were useful for all users, or helpful for a particular project, or not useful at all. Based on this valuable user information, we continued to improve the review quality and volume, and the rate of misdetection.
Raising Capital(#5. Total: 300 Million Yen) — April 2017
By this time, the cumulative total of equity financing and a long-term debt financing was over 300 million yen. At the time, the churn rate of users was low, and we generated new users organically. I assumed SideCI reached the product market/fit and raised more capitals for the continuous product development and sales expansion. As a company, we started preparing for a new business phase once again.
Also, we revised the personnel structure. Since the resignation of the VPoE in December 2016, our development system followed the Scrum method with me as the product owner. To focus on sales, marketing, and recruiting as the CEO, I transferred the product owner status to Soutaro. Soutaro had an extensive knowledge of program analysis and earned a Ph.D. with a thesis on type analysis in programming languages. He is also a developer of the implementation of static type inference called Steep, which was one of the Ruby3x3 projects. Due to the nature of SideCI supporting and automating code review with static analysis, core committers and committers of RuboCop and Reek worked at SideCI.
Appointing Soutaro as the product owner reinforced the direction of SideCI. Consequently, SideCI, Inc. could focus on offering new analyzers, Querly (Ruby), Goodcheck (all languages), and compatible WebUI to expand the coverage of review.
Reference: Fighting false detections with LINT tools in abyssinian mode
Besides that, we sifted through functions and discontinued functions that were not relevant to code review such as the technical debt kanban to make SideCI much easier for users to use.
Reference: Classic Mode Shutdown Announcement
We added Styleint, Java, Misspell, Flake8 plug-in support around this time too. Our mission to improve and provide a code review product that is more productive for more developers has not changed still.
Focus on Marketing & Sales
While improving the product quality, my desire for having more people to use SideCI grew even stronger. To expand the business worldwide, we have been trying to raise awareness of SideCI by staffing a booth and speaking at events since 2017. The below is a sample list of events we had participated.
- RubyBusiness User Conference
- RubyConf Taiwan
- Rails Developers Meetup
- GitHub Satellite 2018 Tokyo
- Code Review Meetup (Held at Sider)
New Name: SideCI to Sider — June 13, 2018
We had been providing our service under the name of SideCI for about four years since the release in 2014. I’m grateful that SideCi is continuously getting new users and highly recognized by programmers in Japan.
On the other hand, whenever I talked about SideCI in other countries such as the United States and Taiwan, programmers asked me how different SideCI is from the existing test and delivery (CI) services and told me that SideCI was not necessary because they were already using a CI. I often felt “CI” in the product’s name was causing misunderstanding. I assumed that the similar misunderstanding would continue, so I decided to change the name to Sider. In addition, although we haven’t made an official announcement on our website (as of August 31, 2018), we started providing our service for GitHub Enterprise. As a result, various big enterprises began using Sider.
Sider was finally released after going through various crises since its ideation phase. Sider grew into its current shape by learning from the feedback of many users. Sider will always be by our users’ side.
From Now On
To introduce Sider to many more people, we will have a booth as a sponsor at GitHub Universe, which will be held in San Francisco on October 16th and 17th, 2018. If you get a chance, please visit our booth. We will be giving out many promotional goods. We are looking forward to meeting you!
For more information about Sider, please go to our website.