James Smith

Cette semaine, je m'entretiens avec James Smith de BugSnag, où ils font de la surveillance des erreurs d'application. Nous parlons de casser des ordinateurs quand on est enfant, d'utiliser l'open source comme moyen d'obtenir une traction initiale, du marketing auprès des développeurs, du rôle des données dans la prise de décision et bien d'autres choses. J'espère que vous aimerez !

Josh Pigford : Allons-y, j'aime bien connaître l'histoire complète, où les fondateurs ont été, comment ils sont arrivés où ils sont maintenant, et je suppose que nous allons commencer par là. Vous avez donc mis la main à plusieurs entreprises différentes et projets Open Source au fil des années, et puis récemment, avant BugSnag, vous étiez le CTO chez Heyzap.

Donc je suppose que je suis curieux, comment avez-vous commencé avec les ordinateurs et la technologie ?

James : Oui, bien sûr, eh bien, c'est remonter loin. C'est une bonne question.

Je pense que mon père m'a eu, je m'en souviens, un Noël, mes parents m'ont offert un ordinateur. Je crois que c'était un IBM SX25 486 SX25 et fondamentalement ils l'ont eu pour nous avec quelques jeux dessus. Je crois que nous avions Lemmings et un jeu appelé Micro Machines si vous l'avez déjà joué.

Josh : Des classiques.

James : À l'époque où j'étais enfant. C'étaient des jeux classiques, et cela m'a intéressé aux ordinateurs en premier lieu, puis je l'ai cassé, je l'ai démonté et je l'ai remonté, et j'ai découvert cette chose appelée BASIC à l'époque, et j'étais comme, attends, je peux faire faire des choses à cet ordinateur, à l'horreur de mon père. Et je suis sûr que vous entendez cette histoire chez beaucoup de fondateurs au début, comment vous avez commencé à construire des choses.

Eh bien, vous commencez à construire des choses en cassant d'abord les choses.

Josh : Bien sûr.

James : Donc j'ai eu cet ordinateur, je l'ai cassé, j'ai ennuyé mon frère parce qu'il voulait juste jouer à Micro Machines sur cet ordinateur. Et puis plus tard, je me souviens, j'ai eu la chance que je sois de Londres et nous avons eu Internet par câble très tôt. Et donc nous avions Internet, je pense en 96, ce qui est une époque folle il y a longtemps maintenant.

Josh : Wow, oui.

James : Et donc à l'époque je me souviens, je pense que la principale raison pour laquelle je me suis mis à construire des produits plutôt que de juste casser des choses et les démonter était que mon ami et moi avions l'habitude de jouer à ce jeu, Duke Nukem 3-D si vous l'avez déjà joué.

Josh : Est-ce qu'il venait gratuitement sur votre ordinateur ou quelque chose comme ça ? Ou c'était une version gratuite ou vous aviez …

James : J'avais la version Shareware, il y avait comme le premier pack ou quoi que ce soit.

Josh : Ouais, ouais, d'accord.

James : J'ai joué à ça à mort, c'était un super jeu.

Mais oui, nous avons découvert que vous pouviez, à l'époque nous jouions via modem ce qui me vieillit vraiment je suppose maintenant. Il fallait appeler l'ordinateur de quelqu'un d'autre plutôt que de passer par TCP/IP à travers Internet comme c'est maintenant. Vous aviez à appeler la ligne téléphonique de quelqu'un d'autre et puis les modems parlaient entre eux.

Le joueur IPX, je pense que c'est ce qu'on appelle sur Duke Nukem et nous étions comme, c'est nul, nous voulons être sur Internet et jouer à ce genre de truc. Donc nous avons trouvé cet outil qui canalisait les trucs IPX via TCP/IP et puis nous étions comme, pourquoi personne ne connaît ça ?

Donc nous avons fait un petit site web, c'était comme, hé, si vous voulez jouer à Duke Nukem sur Internet plutôt que d'avoir à appeler le modem de votre copain, voici comment l'utiliser. Et donc des tonnes de gens, c'était juste un outil que quelqu'un d'autre avait construit, c'était un outil gratuit, et donc des tonnes de gens sont venus sur ce site web et étaient comme, wow, c'est fou, les gens aiment ça. Et puis j'étais comme, ce ne serait pas cool si vous pouviez avoir un classement ? Ne serait-ce pas cool si vous pouviez avoir un classement de qui gagne le plus de parties de Duke Nukem et je ne savais pas comment faire ça, je ne connaissais que le HTML à l'époque, un peu de BASIC, et j'étais comme, ne serait-ce pas cool si je pouvais faire mettre à jour cette page web dynamiquement ?

Et encore, je suis sûr que vous entendez cela de beaucoup des fondateurs avec lesquels vous parlez, mais c'est ce qui m'a mis à construire un produit. J'étais comme, je veux pouvoir mettre à jour ce qui était sur ce site web de manière dynamique en fonction de ce que les gens saisissent. C'est juste simple, je pense que c'était en Pearl à l'époque. Et j'étais comme, oh, d'accord, ce n'était pas si difficile. Et puis une fois que vous avez franchi ce cap, je suis sûr que vous avez la même réaction. Une fois que vous avez franchi le cap de, wow, je peux contrôler ça, je peux changer ça, c'est quelque chose que j'ai construit, ça déverrouille dans votre esprit, eh bien je peux probablement construire beaucoup de choses maintenant. Cela ouvre les choses.

Josh : Il y a un effet boule de neige là-dedans.

James : Exactement, oui, c'est positif, c'est excitant. Donc nous avons pris cette expérience et n'avons cessé de construire depuis, et oui, vous avez mentionné Heyzap qui est, vous avez probablement deviné d'après mon accent que je ne suis pas de, ma société est basée dans la Bay Area, mais je ne suis pas de la Bay Area.

Heyzap est la société qui m'a amené à San Francisco, donc avant cela j'ai fait une licence en Mathématiques et Informatique à une université appelée Bath University au Royaume-Uni sur la côte ouest de l'Angleterre. C'est là que j'ai rencontré mon co-fondateur en fait pour BugSnag. Et puis après cela j'ai suivi ce chemin par défaut en allant dans la finance, et j'ai travaillé pour Bloomberg à Londres en construisant des plateformes de trading.

Et j'ai beaucoup de respect pour cette société, j'ai beaucoup appris là-bas, une attitude assez entrepreneuriale dans cette société aussi, mais je travaillais toujours dans la finance, et la finance c'est, sans vouloir offenser personne qui travaille dans la finance, mais ce n'était pas pour moi, c'était une industrie assez déprimante pour travailler.

Un couple de vieux amis de l'école venaient d'être acceptés au programme Y Combinator. C'était, je suppose, hiver 2008, donc décembre 2008, et ils construisaient, à l'époque, je pense que c'était un widget intégrable pour jouer à des jeux flash sur n'importe quel site web. L'idée était, et cela date vraiment cette société aussi maintenant, parce que flash est complètement inexistant de nos jours.

Josh : Bien sûr.

James : Mais l'idée était que si vous étiez une publication comme le New York Times ou quelque part où vous aviez du contenu et vous vouliez augmenter l'engagement, alors l'idée était que vous pouvez intégrer un widget de jeux flash en bas de votre page pour augmenter le temps sur le site, et donc je suis venu, j'ai rejoint le premier employé de la société tout juste après, ayant juste obtenu mon diplôme de la classe Y Combinator, et j'ai finalement transformé cela en une entreprise de taille décente, pivoté environ deux ou trois fois, comme les startups ont tendance à le faire, mais oui, c'est ce qui m'a vraiment donné le goût de la vie en startup.

J'ai toujours été un constructeur, j'ai toujours construit des choses dans ma vie, mais j'étais comme, eh bien en réalité, qu'en est-il de construire des choses pour un plus grand bien ? Qu'en est-il de construire des choses pour améliorer la société ou construire des choses pour gagner de l'argent aussi.

Josh : Bien sûr, bien sûr.

James : Au niveau fondamental, donc oui, c'est ce qui m'a amené ici.

Josh : Donc comment avez-vous, donc Heyzap, était-ce, donc vous avez mentionné la chose du jeu flash. Si je me souviens bien, j'avais l'habitude de faire beaucoup de design, du travail de conseil, j'ai étudié le design, et je suis à 87% sûr que j'ai presque accepté un emploi chez Heyzap en tant que designer UI, donc …

James : Vous savez quoi ? Je vais devoir vérifier ma boîte de réception maintenant. Quel petit monde, c'est fou.

Josh : Ce serait 2000 et, oh je ne sais pas, 9 ou 10 ou quelque chose comme ça ? Peut-être un peu plus tard que ça.

James : Début, très début de Heyzap. C'est fou.

Josh : Ouais. Donc oui, petit monde.

Donc en revenant aux débuts où vous cassiez vos ordinateurs. Vos parents étaient-ils favorables à casser les choses et les remettre ensemble et découvrir comment les choses fonctionnent, ou étaient-ils plutôt ennuyés par cela, ou …

James : Ouais, mes, je pense qu'ils étaient, je ne dirais pas favorables. Je pense que tolérant est probablement un meilleur mot.

Je me souviens que mon père a vraiment stressé à un moment donné. Quelques années plus tard, j'avais ça, quand nous avions une connexion Internet permanente parce que je ne sais pas si vous vous souvenez à l'époque, avec la connexion à distance, si vous n'aviez qu'une seule ligne téléphonique …

Josh : C'était tout.

James : C'était tout, ouais, vous aviez à basculer Internet on et off, donc nous avons encore, j'avais la chance d'avoir, avec le service téléphonique que nous avions, ils vous donneraient une deuxième ligne gratuitement.

Donc mon père était comme, oh super, je peux maintenant faire des appels téléphoniques sans avoir à écouter les bruits de modem sur le téléphone, et donc nous avons eu cette deuxième ligne et je me souviens que je pense que j'exécutais un service web PHP et j'étais comme, j'aimerais pouvoir l'héberger moi-même. Je ne veux pas, je suis un enfant, je n'ai pas d'argent pour l'hébergement, mais j'ai des vieilles pièces d'ordinateurs donc j'ai pris une très vieille carte mère, des vieux composants, j'ai installé je pense Debian Red Hot dessus et j'ai configuré Apache dessus et j'hébergeais un serveur web à partir d'une boîte à chaussures, littéralement une boîte à chaussures dans un placard, et c'était comme un placard Ikea ou quelque chose comme ça. Je pense que j'ai coupé un trou à l'arrière du placard pour mettre les câbles dedans. Et donc mon père a vu ça et il était comme, il est venu et a fondamentalement fait un test de santé et de sécurité. Il était comme, écoute, je te soutiens dans la construction de ces choses et je comprends ce que tu fais ici, mais premièrement, tu exécutes un ordinateur chaud à partir d'une boîte à chaussures, exactement.

Et deuxièmement, viens me parler si tu vas couper un trou à l'arrière de mes meubles. Et j'étais juste comme, ce sera cool, je vais faire ça arriver, je vais construire ce truc.

Donc non, c'était un test à certains moments.

Josh : Bien sûr.

James : Et je pense que si j'étais à sa place, je serais probablement un peu fâché de ce genre de trucs.

Josh : Bien sûr.

James : Mais il était tolérant.

Josh : Étiez-vous dans la construction d'autres choses ou c'était toujours de la technologie, basée sur l'électronique ?

James : Ouais, je pense, encore une fois c'est probablement comme une mentalité de personne de produit, mais j'ai toujours aimé construire des choses en général. Je me souviens qu'avant de me lancer dans les ordinateurs, j'ai mis en place un petit système, petits modems de serveur, je pense que j'avais un kit d'électronique que j'ai obtenu de ce lieu appelé Maplin Electronics, qui est un peu comme un endroit Radio Shack.

Josh : Oui.

James : Au Royaume-Uni.

Et j'avais un kit Servo et un tas de fils et tout ce genre de trucs, et j'ai créé un petit système pour ouvrir et fermer mes rideaux dans ma chambre. Et c'était comme, un niveau de machine de Rube Goldberg de connexions et de fils et de câbles, et ouais, je pense que j'aime la tangibilité de construire des choses. J'aime le fait que, je pense qu'à l'école j'étais, avez-vous déjà vu ces robots toner que vous pouvez programmer qui vont à gauche et à droite et tout droit et ce genre de choses, ils dessinent des motifs.

Josh : Ouais, ouais, ouais.

James : Je ne me souviens pas comment ils s'appellent maintenant mais nous en avions un à l'école et je pense que quand vous voyez les actions que vous dites à une machine ou à un système de faire ont des impacts tangibles, cela déclenche en quelque sorte ce bug. Donc ouais, j'ai toujours aimé construire des choses.

Josh : As-tu toujours été entrepreneurial, comme évidemment il y a le côté construction mais en quelque sorte, pas vraiment le côté vente, mais vouloir gagner de l'argent avec des trucs, ou est-ce que c'était toujours le produit en premier ?

James : Définitivement le produit en premier, je pense que l'aspect entrepreneurial des choses dans lequel je suis tombé.

Je pense que pour Heyzap être le premier employé là-bas, même si j'étais CTO de cette entreprise et que je dirigeais l'équipe d'ingénierie, j'irais à des conférences et j'irais à des événements, donc par défaut j'ai fini par vendre le produit. Et chez BugSnag en particulier, le client de BugSnag c'est moi. Ce sont des contributeurs techniques individuels ou des leaders techniques. Et j'ai été dans les deux rôles.

Si vous avez un produit que vous avez construit et que vous aimez et que vous l'avez construit pour une raison particulière pour résoudre un problème particulier, et votre client est essentiellement le même personnage que vous, cela devient beaucoup plus facile, cela vient beaucoup plus naturellement.

Mais ouais, je veux dire, quand nous avons commencé BugSnag, Simon et moi avons bootstrappé pendant les neuf premiers mois de l'entreprise. Donc je pense que nous avons tous deux dit que nous avions neuf mois d'économies sur le compte bancaire, et je pense que j'ai en fait mal calculé. Je pense que je n'avais que six mois d'économies sur le compte bancaire, et le loyer à San Francisco n'est pas bon marché.

Josh : Non, ce n'est pas quelque chose que tu peux accidentellement faire genre, oh, j'ai mal estimé cela de trois mois.

James : Exactement, mais c'est... je vais te dire, cela a en quelque sorte encadré l'entreprise pour nous. Je suis un constructeur, j'aime les produits et le produit en premier, mais si vous allez voir vos clients et dites ce que vous aimeriez, ils vous donneront une réponse différente si vous dites ce que vous paieriez, et donc encadrer, je veux dire, c'est votre entreprise, vous le savez vraiment bien mais encadrer autour de ce que vous paieriez était une expérience tellement habilitante pour Simon et moi parce que nous avions l'argent qui diminuait. Nous, je pense que nous avons fini par atteindre la rentabilité quand nous bootstrappions avec environ un mois d'économies de rechange.

Et donc, c'était de l'entrepreneuriat forcé. Je pense que, cela dépend vraiment de la façon dont vous définissez le comportement entrepreneurial mais la plupart des entrepreneurs que je connais et que je respecte sont d'abord des gens de produit et deuxièmement des gens commerciaux. Il faut avoir les deux, évidemment mais ouais, je suis tombé dedans de cette façon.

Josh : Ouais, ouais. Alors, je suppose, comment BugSnag a-t-il vu le jour ? Dans ma tête, pourquoi un autre suivi d'erreurs d'application, non ? Quel était l'impulsion pour...

James : Exactement.

Donc nous, Simon et moi avions essentiellement des frustrations. Donc Simon est mon co-fondateur, nous nous sommes rencontrés à l'université. Je l'ai en fait engagé pour diriger mon équipe mobile chez Heyzap, je l'ai amené aux États-Unis pour diriger l'une de mes équipes chez Heyzap et nous étions assis dans un pub un jour en parlant de la construction de logiciels en général. Et j'avais écrit des logiciels chez Bloomberg dans la finance et puis j'ai aussi un peu fait des logiciels embarqués pendant l'université et puis j'ai également dirigé Heyzap en tant que startup, j'ai vu le même ensemble de problèmes dans toutes ces différentes industries et Simon a dit qu'il voyait la même chose.

Alors après l'université, Simon était consultant en logiciels, et donc il irait résoudre les problèmes dans de grandes entreprises comme Votify qui est une grande société de télécommunications ou l'industrie de la défense britannique et ce genre de choses. Il volerait, résoudrait leurs problèmes, et repartirait. Et très souvent il serait comme, pourquoi ne saviez-vous pas que c'était un problème ? Comment a-t-il fallu si longtemps pour découvrir que c'était cassé ?

Nous étions dans un pub un jour en racontant ces histoires et nous avons réalisé que chaque seule entreprise qui a du logiciel est baisée quand c'est cassé, et moi étant un gars du produit, j'étais comme, je ne pense pas que quelqu'un résout cela correctement. Et, historiquement si vous regardez en arrière à quand nous avons commencé l'entreprise il y a environ quatre ans, il y avait essentiellement un seul acteur dans le jeu à l'époque, qui était un produit qui s'appelait Hop Toad et s'appelle maintenant Airbrake.

Je dois respecter l'industrie. Ils ont été les pionniers mais ils ont été la première tentative de cela. C'était comme, essayons cela. Je pense que c'était ces gars et une entreprise appelée Exceptional, ils ont fini par fusionner ensemble.

Josh : Exceptional était essentiellement l'incarnation précédente des gars d'Intercom.

James : C'est exact. Ouais, les fondateurs d'Intercom ont construit Exceptional à l'origine, c'est exact. Donc ils l'ont vendu aux gars d'Airbrake et ils ont fusionné ensemble et ils résolvaient tous les deux le même problème. Ils disaient essentiellement, hey, au lieu de simplement fouiller dans les fichiers journaux ou la version 0.1 de la surveillance des erreurs qui est que quand une erreur se produit, vous vous envoyez un e-mail, pourquoi ne pas simplement le mettre dans une base de données et le montrer sur un tableau de bord, donc c'était la première phase de cet espace.

Je pense qu'ils ont ouvert la voie pour la base de surveillance des erreurs proactives de servitude, mais ce qui s'est passé c'est que chez Heyzap nous avons fini par construire un produit mobile et la surveillance des erreurs mobiles était terrible et le premier essai pour moi dans la surveillance des erreurs en tant que personne produit était d'écrire l'agent en écrivant le SDK qui envoyait des erreurs des applications Android dans Airbrake.

Donc j'ai en fait créé une bibliothèque OpenSource qui envoyait dans l'API d'Airbrake, et j'en suis arrivé au point où j'étais comme, c'était facile. C'était la partie facile, détecter et envoyer ces erreurs. Mais les erreurs sont présentées de la mauvaise façon, elles sont groupées incorrectement, l'alerte n'est pas là. Vous ne pouvez pas dire quel était l'impact sur l'utilisateur. Donc en fait, initialement nous avons construit cette entreprise parce que nous grattions une démangeaison. Il n'y avait rien qui résolvait activement le problème de la façon dont nous pensions que cela devrait être résolu.

Il y avait quelques entreprises au même moment qui ont surgi autour du moment où nous construisions BugSnag, Century étant la principale. Et oui, depuis, nous avons juste été...

Je me souviens du jour un quand nous avons commencé à construire la feuille de route pour BugSnag, nous avions une feuille de route de deux ans que nous avons écrite et quatre ans après, nous avons fait tout cela mais je pense que notre feuille de route est maintenant encore plus longue que cela.

Plus vous avancez dans cela, plus vous réalisez que les problèmes...

Josh : Sont beaucoup plus grands.

James : Exactement. Il y a les bases de j'ai une petite application PHP ou Ruby ou quoi que ce soit, et je veux juste savoir quand chaque crash se produit, c'est la partie facile. Mais ce que nous constatons c'est que lorsque vous entrez dans de plus grandes entreprises comme Airbnb ou Pandora, ces sortes d'entreprises, les problèmes sont très différents en échelle.

Je dis toujours cela aux gens, c'est très facile de savoir que vous avez des erreurs, c'est très difficile de les réparer réellement et de faire quelque chose à leur sujet. Et donc l'espace du problème s'est décalé, plutôt que de dire voici une liste de toutes les erreurs que nous avons, qui est le problème facile, c'est maintenant comment vous concentrez-vous sur les erreurs qui importent et comment livrez-vous proactivement des corrections aux clients les plus largement affectés ou aux bogues les plus largement affectés.

Donc ouais, c'est intéressant de voir comment résoudre le même problème, même dans le domaine de la surveillance des erreurs, les problèmes changent à l'intérieur de cet espace.

Josh : Et je veux dire, je pense que c'est le cas, je sens que le passé, je ne sais pas, cinq peut-être même dix ans du web et juste de la construction de logiciels a... les outils sont tellement, la barrière à l'entrée est tellement basse que pendant longtemps, tout le monde a juste construit des trucs aussi vite qu'ils pouvaient, mais ensuite ce qui se passe, c'est que vous réalisez que d'avoir juste les données en soi est, bien peut être utile, pour la plupart vous ne pouvez rien en faire, n'est-ce pas ?

C'est la même chose avec nous avec Bare Metrics, c'est comme nous pouvons vous dire des chiffres toute la journée, mais et alors ? Qu'allez-vous en faire ? Et c'est la partie difficile.

James : Tu as mis dans le mille. Tu sais quoi, en fait ? Cela me rappelle, donc Simon et moi, notre premier achat en tant qu'entreprise, en tant qu'entreprise constituée était d'acheter un tableau blanc sur Craig's List pour que nous puissions écrire des idées et des choses dans notre chambre/bureau que nous avions. Et nous avons écrit, je pense quatre choses sur ce tableau blanc, et la première sur la liste était des réponses au lieu de données, et c'est exactement, je pense qu'il y a beaucoup d'outils qui vous donneront des données, mais ce n'est pas utile si vous essayez de résoudre les problèmes et de les prioriser.

Donc littéralement, l'un de nos principes fondateurs était des réponses au lieu de données. Pouvons-nous vous livrer une étape plus loin ou dix étapes plus loin qu'un simple fichier journal ou une liste de problèmes.

Ouais, c'est vrai, n'importe qui en logiciel résout le même problème en ce moment avec cela.

Josh : Bien sûr. Donc quoi, évidemment vous avez décidé de construire ce suivi d'erreurs d'application mais aidant les gens à en avoir plus de sens. Quel rôle avant BugSnag, je sais que tu as été très impliqué dans les trucs OpenSource...

James : Oui.

Josh : Donc quel rôle tous les trucs OpenSource précédents ont-ils joué dans le succès de BugSnag ?

James : C'est une excellente question. Je pense que la bibliothèque de construction OpenSource, c'est ce que j'avais l'habitude de faire dans la terre OpenSource et je fais toujours ces jours-ci est de construire des bibliothèques.

Et l'idée était que, hey j'ai résolu ce problème, ce problème n'est pas un problème qui m'est unique, je vais le nettoyer, l'extraire, et le partager avec tout le monde. Et donc une partie cool de BugSnag c'est notre SDK, ce sont nos bibliothèques qui détectent ces crashs et les signalent et donc quand nous avons commencé à construire BugSnag beaucoup d'outils dans l'espace qui font la surveillance des erreurs, surtout du côté mobile qui est l'un de nos plus grands domaines de croissance en ce moment, ne partagent pas le code source de leur solution de surveillance des erreurs.

Quelques-uns d'entre eux, il y a CrashtheLinks et Aptelligent, tous les deux ont des SDK de surveillance des erreurs en source fermée et cela ne m'a même pas traversé l'esprit de faire cela quand nous avons construit l'entreprise. C'était pour moi, ce n'est pas la sauce secrète, ce n'est pas ce que nous vendons à nos clients, nous vendons l'expérience de trouver et réparer plus rapidement. Nous ne vendons pas un SDK, et donc ouais, en ayant cette expérience en OpenSource et en construisant des bibliothèques, je pense que cela m'a appris deux choses.

Numéro un cela m'a aidé à comprendre la valeur de faire cela, non ? Donc les gens peuvent voir derrière le rideau quand vous construisez des choses dans la terre OpenSource. Par exemple, dans notre bibliothèque Android qui détecte les crashs sur les applications Android, je pense que c'était je ne peux probablement pas dire le nom de la entreprise, l'un de nos grands clients du côté mobile grand public, ils ont évalué tous les concurrents et ils ont dit, hey nous sommes allés avec vous parce que vous avez toutes ces bibliothèques OpenSource parce que nous voulons contribuer à elles et nous voulons voir ce que vous construisez sous le capot.

Pour moi c'était juste un défaut, c'est comme ça que j'opère. Et c'était vraiment, vraiment habilitant de voir que nos clients pensaient la même chose. Je pense que la deuxième chose est qu'il n'y a pas de codes de triche, il n'y a pas de raccourcis source quand vous travaillez dans l'OpenSource. Vous travaillez ouvertement, et donc vous devez penser à, est-ce que cette bibliothèque semble appropriée pour la communauté que je construis.

Vous pourriez avoir un ensemble de principes directeurs pour les bibliothèques de surveillance des erreurs, mais celle que vous construisez pour Ruby doit probablement se sentir un peu différente de celle que vous avez construite pour Android, doit probablement se sentir un peu différente de celle que vous avez construite pour Python. Et si vous construisez la façon OpenSource et vous partagez tout ce code et cette interface avec vos clients, vous ne pouvez pas vous cacher.

La communauté Python est un bon exemple ici, il y a ce concept d'être pythonique que les gens sont fiers dans la communauté Python. Je suis d'accord avec cela aussi, c'est mon passé. Je venais de la communauté Python il y a un moment. C'est-à-dire que si votre code est écrit d'une manière pythonique, les développeurs de logiciels sont plus susceptibles d'avoir du respect pour votre bibliothèque et donc de l'adopter dans leur base de code.

Donc ouais, je pense que ce sont les principales choses que j'ai tirées de mon passé en OpenSource. Je pense aussi que la construction de bibliothèques pour moi, et la construction de SDK est très beaucoup comme la construction d'un produit. Vous construisez, c'est une expérience utilisateur. Une bibliothèque est juste un ensemble d'interfaces utilisateur, il se trouve que ce sont des fonctions et des classes plutôt que des interfaces visuelles. Donc je pense que cela m'a donné un respect sain pour la construction de produits aussi.

Josh : Pensez-vous que le travail OpenSource précédent vous aide à obtenir des clients initiaux ou c'est plutôt sans importance ?

James : Cela dépend tellement je travaille généralement dans la langue dans laquelle je travaille en ce moment, donc j'avais deux grands projets OpenSource, un ou deux plugins JavaScript qui sont très dépassés ces jours-ci mais basés sur des requêtes et une grande bibliothèque Android que j'ai construite qui était HDP Cline sur Android.

Et la chose c'est pour BugSnag, parce que nous sommes multiplateformes, nous supportons la surveillance des erreurs dans à peu près n'importe quelle plateforme, mobile, navigateur de bureau, quoi que vous utilisiez. Avoir une expertise dans la terre Android signifiait que je pouvais parler un peu aux conférences Android mais c'était tout, vraiment. Cela ne m'a donné aucune crédibilité dans aucune des autres plateformes.

Mais je me souviens, je pense que quand nous sommes allés à Airbnb pour la première fois pour leur montrer le produit, ce sont l'un de nos clients, l'un des gars là-bas était comme, ah, j'avais l'habitude d'utiliser ta bibliothèque http, et c'est un peu drôle parce que quand tu écris un logiciel OpenSource je sens que tu le fais juste derrière le clavier et ouais, tu pourrais avoir beaucoup d'étoiles sur GetHub, ou les gens forking ton produit sur GetHub, mais rencontrer quelqu'un dans la vie réelle qui a utilisé ton produit avant est une expérience tellement différente, c'est un peu excitant.

Ouais, je pense que dans cette situation cela m'a donné un peu plus de crédibilité. Mais pas pour aucune des autres plateformes, je souhaite que cela l'ait fait.

Josh : Je comprends. Donc il y a évidemment une abondance d'outils de développement, en général, juste de la journalisation des erreurs ou n'importe quoi d'autre, mais il y a essentiellement un nombre infini d'outils à la disposition d'un développeur, donc en tant que développeur vous-même, comment vous évitez d'être à la fois débordé par les outils à votre disposition, et aussi ne pas vous laisser distraire, genre, cet outil aléatoire va résoudre tous mes problèmes.

Comment vous concentrez-vous sur l'utilisation exclusive des outils qui font vraiment une différence ?

James : C'est une très bonne question. J'en parle beaucoup avec mon équipe. Je ne sais pas si cela vient avec l'âge, car je code depuis très longtemps maintenant et la sélection d'outils a toujours fait partie de mon travail depuis longtemps, mais je suis devenu très, très pragmatique ces derniers temps. Je pense que, autrefois, la façon dont j'ai appris à créer des logiciels en premier lieu était que j'essayais tous les derniers et plus grands nouveaux logiciels et je créais des tas de projets secondaires et j'expérimentais avec eux.

Littéralement, juste hier, j'expérimentais avec un outil appelé Roll Up, qui est un système de bundling JavaScript qui rivalise actuellement avec Web Pack. Et c'était juste un petit projet secondaire avec lequel j'expérimentais, mais quand il s'agit de construire et de choisir des outils pour le travail, pour Bug Snag, au quotidien, je penche très franchement du côté du pragmatisme, donc honnêtement, ces jours-ci, je n'ai pas beaucoup voix au chapitre dans la sélection d'outils. C'est normalement mon co-fondateur ou les équipes d'ingénierie. Mais si quelqu'un me demandait un conseil à ce sujet, je dirais, quel est l'outil le plus populaire ou l'outil qui est stable, mais en tendance à la hausse.

Donc, quand nous avons choisi un framework JavaScript pour notre tableau de bord, ce n'était pas comme, choisissons le plus cool nouveau framework JavaScript. C'était comme, quel est le mieux supporté, y a-t-il de grandes entreprises qui l'utilisent ? La qualité de la chaîne d'outils, est-elle de haute qualité ? Tout ce genre de choses.

Donc oui, tout cela mène au pragmatisme de nos jours, mais je pense que c'est la bonne façon de faire. Je pense que si vous expérimentez avec la technologie de pointe sur des projets secondaires, mais que vous vous en tenez à l'approche pragmatique pour la production, si cela a du sens. Je pense que vous pouvez finir par avoir le meilleur des deux mondes, et je pense que c'est vrai pour les bibliothèques ainsi que pour les outils et les services que vous utilisez.

Je veux dire, l'une des choses dont mon co-fondateur et moi parlons tout le temps est comment choisir des logiciels ? Et la plupart du temps, c'est par réputation. Le bouche-à-oreille, je ne pense pas que ce soit un modèle d'entreprise durable d'un milliard de dollars, mais vous savez quoi ? Cela vous apporte d'excellents clients et je choisis les logiciels en fonction de ce dont les gens parlent sur Twitter ou dans les groupes Slack auxquels j'appartiens. Donc c'est pour moi un autre aspect.

Le pragmatisme plus la preuve sociale, je suppose.

Josh : Ouais, je pense que c'est facile, surtout quand vous en êtes aux débuts de la création d'une entreprise, ou si vous êtes, disons, un entrepreneur à la première tentative ou quelque chose comme ça. Le sentiment ou l'hypothèse que le prochain outil va d'une façon ou d'une autre résoudre un gros problème pour vous, alors que la plupart du temps, les outils eux-mêmes optimisent simplement une habitude ou un flux de travail donné, non ? Ils changent rarement les choses de manière significative.

Comme si vous n'étiez pas déjà...

James : Exactement, exactement, oui. C'est, je me souviens même quand nous avons fait beaucoup de travail, nous utilisions beaucoup Elasticsearch chez Bug Snag, et Elasticsearch a sorti une nouvelle version et nous étions comme, « Regardez le journal des modifications, cela va vraiment changer fondamentalement notre façon de construire les choses ». Ce n'était pas le cas.

Josh : C'est vrai.

James : C'est la même chose, c'est le même logiciel. Il fait la même chose. Vous créez de la valeur en haut des outils, je pense que c'est la maxime. Les outils sont la couche de liaison, oui, vous pouvez réduire les frictions comme vous le dites, et vous pouvez vous débarrasser de certaines tâches répétitives, mais oui, je pense que vous créez de la valeur en haut des outils.

Josh : Eh bien, et je suppose qu'avec vous, si quelqu'un se présente et qu'il n'a pas fait de suivi d'erreurs ou qu'il n'a rien mis en place pour améliorer constamment son produit, il ne sera probablement pas un client vraiment réussi parce que ce n'est pas quelque chose qu'il faisait en premier lieu.

James : Ouais, c'est, tu sais quoi, en fait, quand nous avons lancé cette entreprise, nous ne parlerions même pas aux gens qui n'avaient pas utilisé une certaine forme de surveillance des erreurs.

Josh : Ouais,

James : Mais la plupart du temps, c'est là que nous créons beaucoup de valeur pour l'entreprise. Donc, si vous avez une très petite application, une très petite boutique qui a quelques erreurs ici et là, alors Bug Snag est formidable, mais à quel point c'est mieux qu'une certaine forme de surveillance des erreurs basique, ou vous envoyer un e-mail chaque fois qu'un plantage se produit.

C'est mieux, mais cela va-t-il fournir beaucoup plus de valeur ?

Ce qui se passe, c'est ces jours-ci, surtout du côté client sur mobile sur la surveillance du navigateur et la surveillance JavaScript, c'est que les gens savent qu'ils ont un point douloureux, mais ils ne savent pas comment le résoudre. J'ai en réalité parlé récemment avec un autre fondateur à ce sujet.

Quand vous créez d'abord une entreprise qui résout un problème très spécifique, vous supposez que votre marché sera constitué de personnes qui comprennent le problème. Et après avoir acquis un peu de maturité, il s'avère que, du moins dans notre entreprise, la plus grosse entreprise, l'entreprise d'un milliard de dollars, c'est chez les gens qui savent qu'il y a une douleur, mais qui ne comprennent pas que la surveillance des erreurs, par exemple, est la façon de la résoudre, et nous finissons par parler à beaucoup de gens, surtout aux conférences, aux événements, aux rencontres et ce genre de choses, qui sont comme, nous entendons des plaintes de nos clients que l'application est cassée et nous ne savons simplement pas comment.

Et ce serait très facile pour moi de penser que tout le monde crée des logiciels de la même manière que je le fais et que vous comprenez que la surveillance des erreurs est une partie essentielle de votre entreprise, et une partie essentielle de votre pile, mais en réalité, je pense que probablement 90 % des équipes de développement logiciel là-bas savent qu'il y a un point douloureux, mais veulent vraiment de l'aide pour comprendre comment la meilleure façon de le résoudre est.

Donc, c'a été une vraie compréhension transformatrice pour moi au cours des dernières années, c'est que supposer que tout le monde sait qu'il a besoin d'un outil comme celui-ci nous aurait probablement amenés à une entreprise de 50 millions, mais en réalité, le plus gros problème est, hey, mes trucs sont cassés et je ne sais pas pourquoi. Et je ne sais pas comment le résoudre.

Josh : Alors, comment abordez-vous cela du point de vue d'aider les gens à savoir comment résoudre le problème qu'ils ne savent pas... ils ne peuvent pas localiser, ils ne savent pas comment l'exprimer, ils savent juste, hey, il y a ce plus gros problème. Mais comment entrez-vous et dites, ouais, ce suivi des erreurs ou la journalisation ou la surface du problème que vos clients rencontrent... comment les sensibilisez-vous à cela en tant que solution ?

James : Ouais, bonne question. Donc, vraiment, c'est autour de la douleur. Je pense que cela dépend de qui nous parlons dans l'organisation, mais vraiment, ils savent que la douleur existe, non ? Au pire, vous allez recevoir des tweets ou des e-mails en colère de vos clients disant que c'est cassé. Donc ce n'est jamais, en tant qu'équipe logicielle ou équipe produit, ce n'est jamais un bon sentiment, entendre les clients se plaindre.

Donc, du côté le plus viscéral des choses, quand vos clients se plaignent, vous vous sentez mal à propos des choses, donc il y a cette douleur qui est déjà intégrée, mais ce que nous voyons plus souvent qu'autrement, ce sont en fait les résultats tangibles de cette douleur, donc c'est, nous avons commencé cette conversation en parlant de comment ce n'a jamais été facile de créer des logiciels ces jours-ci et les clients ont le choix ces jours-ci, donc ce qui se passe, c'est que quand vous évaluez les produits...

L'un de nos clients, je ne peux pas dire le nom parce qu'il sera en colère si je le dis, mais quand ils ont commencé à utiliser Bug Snag, ils ont commencé à utiliser le produit parce qu'ils avaient une note d'une étoile sur l'app store, l'iTunes app store, et ils étaient comme, c'est pourri, c'est embarrassant, les gens pensent que nous sommes un mauvais produit et donc c'était leur raison tangible d'avoir mis en place la surveillance des erreurs, c'était qu'ils étaient notés en public sur la qualité de leur logiciel.

Cela devient de plus en plus courant ces jours-ci avec tous ces différents outils comme Product Hunt ou Stack Shed qui vous permettent de comparer des produits pommes aux pommes et si les gens disent bien celui-ci plante ou celui-ci est lent, vous n'allez pas aller avec ce produit.

Donc, plutôt que d'avoir simplement ce facteur de bouche-à-oreille, il y a presque un résultat tangible de votre produit est pourri, c'est la note de qualité de votre produit, et ça, nous pouvons éduquer sur comment vous pouvez passer d'un pourri à bon et c'est notre travail, aider les gens à voir qu'il y a un chemin pour résoudre cela, mais en réalité le point douloureux est juste, c'est déjà là dans les esprits des équipes produit.

Josh : Alors, quel a été un élément clé du succès pour Bug Snag. Y a-t-il eu une seule chose qui a vraiment changé la croissance pour vous ? Ou deux choses, trois choses ?

James : Ouais, je veux dire, une je pense que la concentration est importante. Je pense que nous nous sommes toujours concentrés sur l'expérience produit, non ? Je pense que ce serait très facile de continuer à ajouter de nouvelles plates-formes que nous supportons ou d'ajouter un saut quand nos clients disent construire cette fonctionnalité, mais je pense que d'avoir une expérience produit holistique de bout en bout a été ce qui nous a maintenus à un taux de croissance régulier.

En termes de points d'inflexion, nous avons construit, je pense que c'était il y a environ 18 mois. Nous avons changé la façon dont nous modélisions nos données afin de permettre aux gens de filtrer et de se concentrer sur les erreurs qui comptent le plus, nous avons donc construit ce tout nouveau tableau de bord. Nous l'appelons le tableau de bord 2 en interne.

Nous avons construit ce tout nouveau tableau de bord qui vous permet de mieux mettre en évidence les pires problèmes, et je pense que c'a été le plus grand point d'inflexion pour nous parce que, comme je l'ai dit plus tôt, le problème de comprendre quelles erreurs se produisent dans votre application Ruby on Rails à faible volume, je pense que nous faisons un assez bon travail à ce sujet, mais quand vous entrez dans l'espace problématique de je suis une application côté client ou consommateur et je reçois des dizaines de millions de rapports de plantage par jour ou des centaines de millions de rapports de plantage par jour, cela devient plutôt un problème de signal à bruit plutôt qu'un problème d'avoir juste une liste d'erreurs.

Donc, nous avons construit ce nouveau tableau de bord et je pense que c'était il y a environ un an que nous avons commencé à obtenir ce bon bouche-à-oreille dans l'espace consommateur. C'est à peu près à l'époque où Air BnB a commencé à nous utiliser, Pandora a commencé à nous utiliser et tout le monde était comme, ouais, cool, la surveillance des erreurs est une chose, mais quand j'ai cent millions d'erreurs par jour et j'ai cent développeurs travaillant sur ce problème, comment pouvez-vous réellement résoudre ces problèmes ?

Donc, nous avons fait ce gros changement de tableau de bord et je pense que cela a eu un assez gros impact sur l'entreprise. Cela nous a permis non seulement de résoudre les problèmes pour les contributeurs individuels et les petites équipes de développement, mais aussi de monter en gamme vers les plus grandes équipes de développement.

Josh : Donc, y a-t-il eu un moment, à l'inverse de cela, donc vous avez eu cette bonne croissance et il y a eu quelques choses qui ont été ces points d'inflexion pour vous, mais y a-t-il eu un moment où vous pensiez que Bug Snag n'allait pas s'en sortir ?

James : Je pense que la chose intéressante à propos des startups, c'est dans l'entreprise SaaS, quand vous êtes une entreprise SaaS générant des revenus, et c'est ce dont vous parlez tout le temps et dont nous parlons tout le temps en tant que fondateurs, c'est que je pense que nous pourrions toujours réussir. Il y a toujours un moyen de continuer en tant qu'entreprise. Je pense que nous nous sommes fixé des attentes élevées en tant qu'entreprise, et parfois nous nous disons, nous ne satisfaisons pas à ces attentes, ou nous voulons croître plus vite que nous ne croissons en ce moment, et donc la bonne nouvelle d'être une entreprise SaaS générant des revenus est que je pense que nous avons toujours été dans un état financier sain, mais la question est plutôt comment pouvons-nous accélérer l'entreprise sans griller notre argent.

C'est ça, trouver ce doux point de croissance, non ? Trouver le doux point de l'accélération, je pense, c'est la partie difficile. Et je vais vous dire quelle est la chose la plus difficile, les gens me demandent toujours et je suis sûr qu'ils vous le demandent aussi. Quels sont les éléments les plus difficiles de l'entreprise ?

J'ai toujours dit l'embauche et la tarification, et l'embauche au début de l'entreprise, surtout en tant que fondateurs britanniques dans la baie, nous n'avions pas de réseau pour recruter, et donc trouver des gens pour rejoindre l'équipe était très difficile.

Cela change un peu ces jours-ci et c'est, surtout quand j'agrandis mon équipe exécutive ou mes managers, je suis comme, comment trouver des gens qui adhèrent à notre philosophie et notre vision en tant qu'entreprise, mais du côté des prix, je pense que le plus proche que nous soyons jamais arrivés d'être comme, oh non, c'est effrayant, c'est quand nous avons traversé quelques itérations de tarification, donc quand nous avons lancé l'entreprise, nous avons tarifé sur un modèle à volonté. Nous avons essentiellement dit que vous pouviez avoir autant de données, autant de rapports de plantage que vous le souhaitez, et nous avons essentiellement facturisé en fonction du nombre de développeurs qui utilisaient le produit.

Nous avons changé notre modèle de tarification pour doubler sur cela à un moment donné et ce n'était juste pas correct, et cela n'a pas fonctionné. Cela n'a pas aligné avec la valeur que nous fournissions. Et donc je pense que, je ne sais pas, c'est ce qui semble être la première chose qui vient quand je parle à d'autres fondateurs, c'est que la tarification, vous n'avez jamais raison, et je pense que c'est une chose libératrice à comprendre. Je pense que si je, en tant que développeur logiciel, je ressens toujours qu'il y a une bonne réponse à un problème et ensuite vous pouvez refactoriser quelque chose si bien que c'est la réponse parfaite, mais quand il s'agit de tarification, j'ai lu un bon article, et c'est aussi votre entreprise, vous pouvez donc parler à ce sujet.

Je pense que c'est très libérateur quand vous comprenez que vous n'obtiendrez jamais le modèle de tarification parfait, et c'est une expérience itérative plutôt qu'une expérience c'est la bonne réponse.

Mais ouais, je pense que pour revenir à votre question, je n'ai jamais vraiment pensé que nous n'allions pas réussir, j'ai parfois senti que nous avions pris des décisions qui ralentissaient la croissance de l'entreprise et surtout autour de la tarification. C'est l'un de ces domaines clés.

Josh : C'est une de ces choses, comme c'est une partie nécessaire, non ? Parce que si vous ne l'aviez pas essayé, vous ne sauriez pas que cela n'a pas fonctionné et si vous ne le savez pas, vous avez potentiellement manqué quelque chose qui aurait pu être une excellente chose, non ?

James : Bien sûr, mais c'est terrifiant parce que la tarification est telle, c'est toujours aujourd'hui, la tarification est une ancre tellement essentielle à votre entreprise que je veux changer les choses, et...

Josh : Eh bien, et cela rend les gens vraiment émotionnels... ouais, désolé, allez-y.

James : Exactement, exactement, et vous souvenez-vous de Zen Desk, en fait, il y a un couple d'années, ils ont fait un changement de tarification et n'ont pas donné aux gens un droit acquis et c'était cette énorme agitation autour de cela, c'était un peu fou.

Josh : Ouais. Donc, pour conclure ici, quel est l'avenir pour Bug Snag, donc vous avez maintenant quelques milliers de clients ? Trois ou quatre ?

James : Ouais, nous approchons quatre mille organisations payantes utilisant le produit maintenant.

Josh : Donc, à quoi ressemble le produit pour les quatre mille prochains clients ?

James : C'est une bonne question. Je pense que la façon dont nous avons actuellement configuré les choses, c'est que nous avons fait un excellent travail en expliquant aux ingénieurs et aux responsables d'ingénierie ce qui est cassé, quels sont les pires problèmes et comment les réparer. C'est notre cœur de métier et je pense que ce que nous entendons de plus en plus de la part de nos clients, c'est : aidez-nous à comprendre les tendances et les modèles, aidez mon directeur technique à comprendre l'état de l'entreprise. Ou en élargissant à d'autres domaines de l'équipe produit. Un exemple ici est que nous avions ce client qui avait un programme pilote sur lequel il travaillait, et je pense que c'était un contrat à sept chiffres sur lequel il travaillait et son tableau de bord s'est cassé pendant ce programme pilote, et l'ingénieur commercial et le vendeur ne savaient pas que le tableau de bord s'était cassé et alors ils ont perdu la vente.

Donc même un ingénieur commercial ou un représentant commercial dans l'entreprise, si vous êtes une entreprise de logiciels, tout le monde dans l'entreprise se soucie de savoir si le logiciel fonctionne ou non. Mais la vue que nous présentons actuellement dans nos tableaux de bord, qui est voici la liste des erreurs et voici les pires erreurs et voici comment les réparer, n'est pas nécessairement la bonne vue à montrer à votre équipe commerciale, à vos représentants du service client ou même à votre PDG ou votre directeur technique.

Donc en prenant ces données fondamentales que nous avons collectées et mises en avant et les affichées de manière plus appropriée pour le reste de l'organisation produit. C'est presque un problème de superposition. Je pense que les vrais problèmes difficiles autour de la collecte de données et de la détection des pannes et les problèmes sous-jacents, je pense que nous avons fait du bon travail pour les résoudre, mais rendre ces données plus accessibles au reste de votre organisation.

Si vous êtes une entreprise construite autour de logiciels, alors tout le monde devrait se soucier de savoir si cela fonctionne ou non et si vous livrez une haute qualité.

C'est donc un peu là où nous allons.

Josh : Vous avez l'impression que vous ne faites que commencer ? Vous le faites depuis quelques années, mais en même temps, les problèmes, vous avez toujours un très gros problème à résoudre, n'est-ce pas ?

James : Ouais, je dis ça tout le temps, j'ai l'impression que ce n'est pas quelque chose où vous vous dites, c'est un problème résolu maintenant, nous l'avons réparé.

Josh : C'est vrai.

James : Chaque fois que vous approfondissez, vous découvrez de plus en plus de problèmes et je pense que l'objectif fondamental, la chose fondamentale que nous essayons de résoudre, c'est chaque fois que nous approfondissons, nous réalisons comment nous pouvons faire mieux, et comment nous pouvons rendre l'expérience encore meilleure pour nos clients et c'est donc la chose la plus excitante, c'est ce qui me fait sortir du lit le matin. C'est qu'il y a tellement de problèmes à résoudre, et donc oui, je me demande si c'est vrai pour chaque entreprise, mais c'est certainement vrai pour notre entreprise.

Josh : Le voilà, James Smith de BugSnag.