case study

December 24, 2018

A failed attempt on the exploration of the internal tools

Motivation

It all started from a casual conversation with my friends working at Google. I was complaining that I didn't quite know what I should do to complete my task because my manager only got me one-sentence guidance. My friends said it is time to use the internal QA engine. At that time, I realized that I might not be the only one who had such problems. Putting some common questions or the general guidance on the internal QA engine would be time-saving. Thus, I did some research on building QA engine and testing on the t2.micro instance. I sent an email about the reason we should have an internal QA engine (unstructured QA info, etc.) and what I have built to my manager and the manager of engineering, but got no reply. I asked one manager the reason they didn't think it is a feasible idea; he said that it is not worth it because it needs a fulfilled discussion among the team members and required much time to build and maintain even though I said I could cover everything. I built the engine myself anyway, considered it an failed attempt on the exploration of the internal tools, and did some research on how to make a successful internal tool.

Rules:

0: even for internal tools, we need to "use an actual design process to research, plan, and iterate" and " identify use cases, common tasks, and get to know the end-users". [1]

1. "there should be two owners of the internal tool: one non-technical and one technical"[1]. More precisely, the non-technical collects all complaints and suggestions while the technical resolves the issues.

2. "The understanding of interfaces and modularity and documentation is more overwhelmingly important for this position than for most positions." "Build tools, and write enough instructions on how to use a tool, so you don't have to think about it." "Every line of code would be useful and readable, and ideally that the headers/libraries would be self-explanatory. All tools should be well publicized within the organization and standards should be promoted such that every group can take maximum advantage of available resources."[2].

3. "The internal tools should have an internal test and release cycle that treats the internal userbase with respect as though it were a client base. Do not break other people's work or workflow! Test, release, deployment and other cycles -- involving key personnel in scrums if appropriate, all of these things will depend on the size and culture of your organization obviously, but they should be pondered." [2]

A checklist for my self:

<TODO>

Internal tools:

e.g. headcount tracking, bug tracking, project management, code diff viewers, email clients, HR, code review tools, source control browsing, tasks, wiki, intranet, etc.

opensource for facebook: https://opensource.fb.com/

YC-related: https://www.quora.com/What-are-the-internal-tools-Paul-Graham-built-to-help-scale-Y-Combinator

Some apps:

BlogIn (for internal communication)

Trello (for task assign and internal communication)

Some cool tools:

git (help to manage Linux)

Maven and Ant (project maintain)

Phabricator[3] (a tool with similar functions as GitHub)

Reference:

[1] https://www.quora.com/What-is-the-best-way-to-design-internal-tools-for-companies

[2] https://www.quora.com/What-makes-someone-a-great-internal-tools-engineer

[3] https://www.phacility.com/