Set of Engineering Principles that were part of the engineering culture at Indix. This document was authored during the beginning of 2015.

1. Engineering Culture
Code

2. Engineering Culture
● Right time to make this explicit
● We are poised to grow dramatically,
so the time is NOW
● Amplify the good parts and identify
the areas for improvement

3. Rules of Engagement
● Participative
● Here is the start
● In Confluence - Search “Engineering Culture”
● Please add suggestions, improvements, tips
● Important to discuss
● Culture happens when everyone owns it
● Detail What? Why? How?
● Step up and Take Charge
● Do or Do Not. There is no Try!

4. Timing
● Start commenting now
● Deep dive sessions every week
● Lets get this in good shape together by
the end of the year
● Practice makes perfect

5. Engineering Culture Code
1. Walk a mile in the customer’s shoes
2. Be world class in ambition & every detail
3. Pay it forward, build on shoulders of giants
4. Learn continuously, challenge the status quo
5. Fail fast, iterate faster
6. Think platform, do platform
7. Design & execute for scale
8. Build quality in
9. Automate everything
10. Measure & monitor everything relentlessly
11. Plan meticulously, deliver on time
12. Share code ownership

6. Walk a mile in the customer’s shoes
What?
● Customer perspective in every part of the engineering process from planning to
design to engineering to operations and support
● Know your customers. Could be end customer or internal folks.
Why?
● Customer focused companies succeed. Customer first culture ensures customer
satisfaction, renewals and positive word of mouth
● Customers are betting their mission critical processes on us
● Happy customers → Revenue → Growth → Happy company
How?
● Every engineer goes through the bootcamp and works for a while as an engineer on
a customer focused project in order to understand customer issues and perspective
● Every engineer be able to give a demo of the API and MDA
● Eat your own dog food - add Indian sites
● Customer prioritized input to planning process
● Simple is Beautiful

7. Be World Class In Ambition &
Every Detail
What?
● We want to be the best at what we do
● It takes attitude and commitment to be the best
● Its not just what people see, its what’s inside the system - they both need to be
perfect
Why?
● We are competing with world class companies
● We want to be #1
How?
● Hire the best - hungry for excellence
○ “T” shaped people

8. Pay it forward, build on
shoulders of giants
What?
● Maximize productivity for yourself and others. Our system has a large
surface area and is complex, so we need to minimize the time it takes for
everyone to understand every part of the system
● Share learnings with internal and external communities
Why?
● Save time - make new hire more productive, faster
● Make it easier to understand and fix things
● Makes it easier to build on things that exists and not have to reinvent the
wheel
How?
● Companies are solving similar problems. Build on top of them.
● Internal Open Source Model
○ Document it else no one will use your system

9. Learn continuously, challenge
the status quo
What?
● Challenge yourself to improve
● Challenge how things are done to improve the way things are done
Why?
● Technology is changing at an incredible pace
● Today’s best practice is tomorrow’s anti pattern
How?
● Freestyle
● Look for similar solutions in alternate domains
● Follow Experts in your fields
● Invite critical review of what you’re working on

10. Fail Fast, Iterate Faster
What?
● Build the right thing the right way
Why?
● Fail fast means that you spend less time in things that don't work
● Get feedback quickly - its costly to build the wrong thing
● #1 motivation for engineers is making progress.
○ Releasing to production is making progress (not just committing code)
● Releases should be boring ,routine and without any ceremony.
How?
● Plan and build in thin slices to get feedback
● Use spikes to validate assumptions and evaluate risks
● Small, Frequent & Decoupled releases
● Continuous Delivery - CI, Feature Flags, Canary Releases etc.
● Autonomous Feature Teams

11. Think Platform. Do Platform.
What?
● Every part of the system exposed as a service
● Every service is self-service
Why?
● Customers ask for it - real-time crawl/parse, matching, classification services
● Make more money - higher level services such as matching service can be priced at
a premium
● Better 3rd party apps, higher level apps - such as for advertising
● Internal users don't have to re-invent the wheel
How?
● You build it, you scale it, you operate it, you document it
● Our Apps should be built on the same API that our customers will use
● Microservices/Light weight SOA
○ Exposing systems as services
○ Support both real time and batch use cases

12. Measure & monitor relentlessly
What?
● We are flying an airplane and we need to know the health and state of every
element of the system - internal and external
Why?
● You cannot improve/fix/optimize, what you cannot measure
● If you don’t monitor what you are measuring, your actions will always be reactive
How?
● Measure - Identify Key Metrics, Plot Trends, Derive Thresholds (RAG),
● Monitor - Big Visible Charts/Boards/Monitors
○ Not just systems but also how customers use the app
● Alerting - Pragmatic Alerting (for Success and for Failures)
○ Pro-active Production Support vs Reactive Production Support
● Examples - App Support, Price/Product Refresh, Customer Sites Health, Data -
Accuracy & Coverage

13. Automate everything
What?
● No human intervention or manual process throughout the system
Why?
● Manual repetitive tasks are error prone and are not scalable
● Manual steps slow the need to improve the system - as in “ah, never mind, Anirudh
will fix that before he sends the report “
● Helps engineers focus on what they are good at - solving problems through code
How?
● Identify & remove bottlenecks
● Where not possible - provide power tools to users
● People make mistakes - build Human Fault Tolerance on top of automation
○ Make it difficult to do the wrong thing
○ Make it fail fast
○ Make it easier to recover from a mistake
● Build, Deployment & QA automation

14. Share Code Ownership
What?
● Everyone on the team owns code, design and architecture (and hacks)
Why?
● Worry-Free Vacations
● Increases bus factor - No Silos
● Fresh Insights & sharing of best practices
● Problem Swarming
How?
● Developer Rotation
● Pair Programming
● Code Reviews
● Sufficient Documentation

15. Design & Execute for Scale
What?
● We want to be the single largest provider of structured product information
and analytics, in the world. Bar none.
● Every part of the system should be able to use all of the data in our system
Why?
● Scale is a competitive advantage. Example - SCP
● Scale opens up new use cases, hence business opportunities
How?
● Applying FP Principles
○ Eg. - Immutability, Lambda Architecture, CQRS
● Reactive Manifesto - Design for
○ Resiliency
○ Elasticity
○ Responsive
○ Event Driven

16. Build Quality In
What?
● Every feature, every process, every algorithm, every piece of data in the system has
to be at the highest possible quality
Why?
● Increases velocity by reducing rework, fire drills
● Increases customer satisfaction
How?
● Pragmatic Test Automation
● Understand and pay off technical debt
● Boy Scouts Rule
○ Refactor

17. Plan Meticulously, Deliver On
Time
What?
● Detailed planning prior to the start of the quarter
● Plan for a quarter as well as for a year
● Manage own time
● Take personal responsibility for your deliverables
Why?
● Good planning ensures quality execution
● On time delivery results in customer confidence and satisfaction
● Predictable execution raises confidence and quality
● Your team members depend on you
How?
● Take commitments seriously. If you commit, you need to deliver 99.9% of the time.
● All engineerings are mini-project managers
● Manage personal activities and multi tasking