Motivation

Team Core Values

Be AI-native in Every endeavor

every endeavor is guided by the transformative power of Artificial Intelligence in the medical domain. We are committed to being AI-first in all aspects of our work, embodying innovation, efficiency, and precision.

Be generous to help

This value emphasizes the importance of generosity in coaching and mentoring others. It suggests a willingness to share knowledge, provide guidance, and foster a collaborative learning environment.

Be transparent to escalate

This value promotes transparency in communication when escalating issues. Team members should openly and honestly communicate problems or challenges to the appropriate stakeholders, enabling timely resolution.

Be focused on priority

This value highlights the need for maintaining focus on priorities. It encourages team members to identify and concentrate on the most important tasks or goals, ensuring efficient use of time and resources.

Candidate Criteria
  1. technical competency

  2. culture fit

  3. conflict consensus

Open Company Culture

SourceGraph handbook

Problem Statement

huge disruption happened in the past 5 years, due to pandemics, trade wars, military wars, and AI adaptation.

Statistics

The software industry has been in crisis since the 1970s According to the Standish Group’s CHAOS Report in 2018, only 29% of software projects were deemed successful, while 52% were considered over budget or delayed, and 19% were outright failures (abandoned or not used).

Root Cause Analysis
  1. Intent: setup for failure: unclear or even confused on the external force of stakeholders, outcome, strategy, and business model, leading to incorrect goal setting and KPI.

  2. Design: failed before execution: conceptual business strategy is not concrete and realizable for technical execution. enterprise architecture required to bridge the huge gap.

  3. Process: too much focus on technology, tooling, and programming language; the dev team should focus on design, process, capability, and governance.

  4. Measure: software developers spend up to 42% of their workweek dealing with technical debt and bad code. code quality measurement is required to provide transparency on complexity, allowing leadership to define policy, assess cost of delay and weigh the shortest job first

Biggest Challenges
  1. volatility

  2. uncertainty

  3. complexity

  4. ambiguity

Solution

Vision

Our vision is to empower and transform the technology industry by revolutionizing software development through cutting-edge measurements and tools for assessing source code quality. We aim to maximize success rates by providing developers and organizations with actionable insights that drive efficiency, reliability, and maintainability.

Mission

Our mission is to develop and deliver state-of-the-art measurement solutions for software source code quality. We are dedicated to providing developers and organizations with comprehensive tools and methodologies that enable them to assess, improve, and optimize their code. Through our innovative solutions, we aim to enhance software development processes, reduce technical debt, and facilitate the creation of robust, scalable, and maintainable software systems

Goal Settings
  1. Develop cutting-edge measurement tools

  2. Provide comprehensive code assessment solutions

  3. Drive software development efficiency

OKRs

Objective 1: Develop cutting-edge measurement tools

Key Result 1: Launch a beta version of the measurement tool with a minimum of 100 active users by the end of the quarter. Key Result 2: Achieve a customer satisfaction score of 4 out of 5 for the measurement tool based on user feedback surveys. Key Result 3: Publish at least two research papers or technical articles on novel measurement algorithms and methodologies in reputable software engineering journals or conferences.

Objective 2: Provide comprehensive code assessment solutions

Key Result 1: Develop modules within the code assessment solution to analyze readability, maintainability, performance, and security aspects, with at least 80% code coverage. Key Result 2: Generate comprehensive reports with actionable insights for code improvement for a minimum of 500 projects within the first quarter. Key Result 3: Increase user adoption of the code assessment solution by 30% compared to the previous quarter through targeted marketing campaigns and partnerships.

Objective 3: Drive software development efficiency

Key Result 1: Reduce the average time spent on code reviews by 20% through the adoption of code assessment tools and automated analysis. Key Result 2: Increase the number of successful builds and deployments by 15% by identifying and addressing common pitfalls in the software development process. Key Result 3: Conduct workshops or training sessions on code quality best practices for at least 50 development teams within the organization.

Valuation

Ecosystem & Pressure (STEEPL)

business must be designed to be agile due to natural uncertainty:

  1. Social: code complexity reflects aspects of social activities

  2. Technological: artificial intelligence has advanced as the norm

  3. Economical: Businesses greatly depend on software

  4. Environmental: expecting more energy saving from code efficiency

  5. Political: code analysis for trade sanction

  6. Legal: as powerful tool in due diligence and M&A

Stakeholder(DRIVER) Analysis

capture, create, and deliver values to these drivers (direct & indirect interests)!!

  1. customers

  2. supplier

  3. employee

  4. owners

  5. community

  6. competitor

  7. enterprise

EEE Example
Stakeholder Exchange (I/O) Expectation Experience KPI

consumer

online services

no errors in transaction

Easy way to transact

< 3% error rate

Developer Experience (DX)

Metric 1: Onboarding time
  • Time to first commit to production: From their first day, how long does it take a new developer to commit code that goes to production?

  • Velocities of other teammates: You might also notice that a team’s velocity slows down when it takes on a new teammate.

Metric 2: Inner loop optimization
  • Time to first file open: How long does a developer wait after opening their IDE before they can start editing a file?

  • Build time: How long does it take to build a project?

Metric 3: Bug resolution time
  • Time between defect detection and resolution: This is a simplistic metric, to be sure. Still, a team with a decelerating bug resolution time is a sign of trouble.

  • Bug severity distribution, bug assignments, bug reporting frequency: These metrics give clues about the quality of your code. A disproportionate number of high-priority bugs is a signal of poor code quality. Or it might be a sign of the quality of the bug reports themselves. Are bugs clearly reported and reproducible? Do they contain sufficient information for a developer to work from?

  • Defect resolution efficiency (DRE): To pinpoint which part of your process is causing more defects, consider DRE. It’s a more sophisticated set of metrics than just time between detection and resolution. DRE measures the percentage of defect resolutions between different phases of development. DRE is a good prevention tool: the sooner you find and resolve a defect, the less it costs your organization.

Metric 4: Code reviews
  • Response time for code reviews: How long does it take before a teammate responds to a PR? Does your team’s workflow allow a developer to work on other issues while waiting for a PR? How do team leads, managers, or product owners manage assignments for code reviews?

  • Number of comments per review, ratio of accepted and rejected code changes: These metrics give clues to the quality of the reviews.

Metric 5: Deployment frequency
  • Deployment frequency: This is an obvious one, but it still helps to understand the nature of your deployments. What is the historical average time to deploy? For example, can your team promise monthly deployments if it averages 12 deployments in a year? Or can it deploy on the 1st of every month for a year?

  • Success/failure rate of deployments: How often are deployments rolled back or re-deployed because of an incident? This is another obvious one, but it gives a clue to how well your teams are collaborating and detects early signs of weaknesses.

The important metrics defined by DORA (DevOps Research and Assessment) include:

  • R: Mean Time to Restore (MTTR)

  • E: Change Failure Rate

  • L: Lead Time for Changes

  • F: Deployment Frequency