7 comments

• 

  Thomas

  1 year ago

  "Very very quick (no dev, no unit testing…)"
  Pas de tests unitaires ? Et pourquoi ça ?
  
  if the software component is updated by its provider : you get the update for “free”.
  Pas toujours. De plus, l'incorporation d'une mise à jour n'est pas toujours facile. Sans parler de l'ensemble des tests des régressions et autres à effectuer avant de mettre en prod. Si en plus (ce qui arrive relativement souvent), la doc est pourrie, ça peut vite devenir un casse-tête les migration.
  
  "which means that technology can be one of the very precious barriers to entry that start-up need to build as soon as they can"
  J'avous que j'ai rien compris
  
  "You don’t rely on someone else’s technology… which can be problematic if the code is bugged, slow or not maintained anymore"
  Si le code est buggé et pas maintenu, ou très peu, alors, c'est le choix de départ qui est mauvais.
  reply
• 

  julien

  1 year ago

  Thomas :
  A priori, le code que tu réutilise a déjà été testé tel quel... il n'y a plus que des tests d'intégration à faire!
  
  Le "free", n'est pas au sens "financier", mais bien de dire que les éventuelles optimisations/nouvelles fonctionalités sont là sans que j'ai eu à la modeliser/concevoir/developer/tester... Il y a a evidement des verifications à faire et des tests d'intégration, mais le temps de travail n'est pas comparable et d'ailleurs, ces mêmes vérifs/tests seraient aussi à faire si je développe moi-même le "module"!
  
  Pour beaucoup de start-up, la techno est une barrière à l'entrée... si tu ré-utilises des technos venant d'ailleurs, rien n'empêche quelqu'un d'autre d'en faire autant! Donc pas de barrière!
  
  Si le code est buggé et pas maintenu, ou très peu, alors, c’est le choix de départ qui est mauvais.
  Oui, enfin, ce n'est pas à toi que je vais apprendre qu'aucn programme de plus de 50 lignes n'est jamais 100% "prouvé"! D'ailleurs dans les technos web; encore plus qu'ailleurs, les choses changent très vite et ce qui est "dans le vent" aujourd'hui peut très bien être enterré dans 12 mois, donc, même avec bon choix aujourd'hui, je peux me retrouver dépendant d'un code qui n'est plus "au niveau" dans un an!
  reply
• 

  Reader

  1 year ago

  i would lean more towards creating and maintaining your own code, especially if the piece of software is a central part of your software, in case something happens it makes troubleshooting much more efficient.
  however, i think that if you are using code from a well maintained source, then that should be safe, i am especially thinking of cpan for perl as an example but not sure if there's something similar for RoR. Using published APIs from the company's website should be safe too i think.
  
  but to me, i go with the motto that "you are better served by yourself" so you are better off doing it yourself! Especially for a startup, I think that if you can pull it off on your own, you'll be even more proud of your product at the end. Good Luck!
  reply
• 

  julien

  1 year ago

  Hi Reader, and welcome here!
  
  You're rigth, I guess the "best" approach is to identify the most critical "components" and to create and maintain it yourself.
  
  I do agree with your motto, but, when time is limited, when you do not have enough competencies/skills to do everything yourself, it's smart to make use of the existing!
  reply
• 

  Thomas

  1 year ago

  C'est pas parce qu'un point est critique qu'il doit être fait en interne. Dans mon contexte, l'accès aux bases de données est critique. Je dois avoir une gestion du cache, des relations n-m, des contraintes, optimization des requêtes générées,etc. Et bien, cela a beau être critique, je vais laisser mon pote Hibernate le gérer pour moi. Sachant qu'il est open-source, en cas de disparition de JBoss, je pourrait toujours maintenir moi-même les sources.
  
  “you are better served by yourself”. It's often wrong. You cannot be good on everything. Presentation layer and ORM layer require differents skills. I prefer to not be proud and have a working product than be proud of a buggy shit that takes all my time to maintain. I prefer to focus on the "business side" of my project than on what is behind the scene.
  reply
• 

  Reader

  1 year ago

  julien, it sounds like you are a bad need of a partner ;)
  
  it's true that areas where you are weak are better left to experts... so until you find the "one" who can complement your skills, it is a valid idea to use existing software and it being open source would leave you some flexibility, so that's a good compromise in the end :)
  
  very interesting to follow your implementation process.
  reply
• 

  julien

  1 year ago

  @Reader : you're damn right... I need a partner, but I should not spend too much time looking for him/her. So I guess, my best option is to "run as fast as I can" and then, welcome people who want to cacth the train!
  reply