The Infi Way

Bij Infi werken we graag op de volgende manier

De Infi Test #

Vlotte steekproef om te checken of je ruwweg The Infi Way volgt. Een soort Joel Test.

  1. Zien developers échte gebruikers?
  2. Wordt code gereviewed?
  3. Worden er automatische builds met tests gedraaid?
  4. Kun je automatisch uitrollen naar productie?
  5. Zijn repositories zelfdocumenterend?
  6. Kiest het team zelf passende technologie?
  7. Kiest het team zelf een passend proces?
  8. Wordt het proces periodiek geëvalueerd?
  9. Wordt werk gerefined voordat het gedaan wordt?
  10. Worden storingen proactief opgemerkt en afgehandeld?
  11. Wordt kennis actief gedeeld binnen- en buiten het team?
  12. Worden secrets correct gemanaged?
  13. Zijn er (bewezen) werkende, encrypted backups?

We mikken op maximale score, ook al moet je daar soms nog naartoe werken.

Gebruikers centraal #

Wij werken voor de klanten van onze klant. Ze gebruiken software om hun doelen te bereiken, ons doel is hen daarbij te helpen.

Hoe we dat graag doen:

  • Direct contact met (eind)gebruikers
  • Prototyping, snel itereren
  • User-centric werken
  • Nauwe samenwerking met designers
  • Werk moet waarde opleveren
  • Werken vanuit "waarom"

Denk aan bijvoorbeeld:

Van onze hand:

Ontwikkel­principes #

We werken op een moderne manier, gericht op kwaliteit. Goed is op de lange termijn ook het goedkoopst.

Hoe we dat graag doen:

  • Modern versiebeheer
  • Up to date tooling, frameworks en libraries
  • Automation waar mogelijk
  • Sterke test coverage
  • Linting, code quality checks
  • Pair programming
  • Code reviews voor (vrijwel) alles

Denk aan bijvoorbeeld:

Van onze hand:

Code is de bron #

Broncode is dat: de bron. Zelfbeschrijvend en dus bruikbaar voor elke ontwikkelaar, van onszelf of anderszins.

Hoe we dat graag doen:

  • Architectuur in de bron
  • Clone & run repositories
  • Continuous integration, continuous delivery
  • OTAP
  • Infrastructure as code
  • Ad hoc scripts in versiebeheer
  • Backup-scripts in de broncode
  • Monitoring en alerting in de bron gedefinieerd

Denk aan bijvoorbeeld:

Van onze hand:

Gebruikte tech #

We gebruiken bij voorkeur altijd de "best tool for the job"; we zijn generalisten die zo nodig snel kunnen specialiseren en verdiepen.

Hoe we dat graag doen:

  • Infi is maatwerk; we helpen met buy-over-build waar logisch
  • Hosting (doorgaans) in de cloud
  • Back-end in een moderne stack
  • Front-end doorgaans met volwassen frameworks
  • Mobile cross-platform, tenzij "native" écht meerwaarde biedt
  • Data-opslag passend bij het project

Denk aan bijvoorbeeld:

Van onze hand:

Proces en team #

Teams werken autonoom, maar kiezen vrijwel altijd een vorm van agile werken. Met Product Owner van de klant.

Hoe we dat graag doen:

  • Team bepaalt eigen proces
  • Continu proces blijven verbeteren
  • Product Owner vanuit de klant
  • Scrummaster (projectmanager of developer)
  • Samen een planning onderhouden
  • Alle teamleden helpen refinen
  • Minimaal 2 personen per team, splitsen vanaf 6 a 7
  • Collega's uit andere teams invliegen
  • Regelmatig samenwerken met klant in één kantoor
  • Testers, designers, en overige expertise aanhaken

Denk aan bijvoorbeeld:

Van onze hand:

Ambacht #

Maatwerksoftware bouwen is een ambacht. We willen vol vertrouwen (én trots!) een kijkje achter de schermen kunnen geven.

Hoe we dat doen:

  • Actieve kennisdeling
  • Voldoende studeren
  • Investeren in tooling
  • Goede hardware
  • Experimenteren
  • Monitoring en alerting

Denk aan bijvoorbeeld:

  • Presentaties (intern en extern)
  • Leergangen, zelfstudie
  • Congressen en meetups bezoeken
  • Kibana, Sentry, Zabbix, etc.

Van onze hand:

Vaste waardes #

Sommige dingen spreken voor ons voor zichzelf: dit hoort er altijd bij. Denk aan Security, Performance, Backups, kritisch meedenken, en jezelf kunnen zijn.

Wat die vaste waardes zijn:

  • Backups, inclusief encrypted offsite backups
  • Security van code, en secure manier van werken
  • Security audits waar logisch (eventueel extern)
  • Performance, bijvoorbeeld via load testing
  • Kritisch meedenken over features, alternatieven aandragen
  • Buy-over-build suggereren indien logisch
  • OS naar keuze (Windows, OSX, Linux) voor devs
  • Open Source gebruiken en ondersteunen
  • Meetups hosten en/of organiseren
  • Onszelf zijn: "Wij zijn mensen."

Denk aan bijvoorbeeld:

Van onze hand: