@Guidu80 : on se connaissait bien avant Internet... peut-etre même avant Pyramide! Ce qui explique que je ne me souvienne plus des règles :(

Using external components

In the process of developing the “software” for Notifixio.us, I am facing a question that many start-up are facing up at some point : what should I re-use and what should I build from scratch? There exists tons of pieces of software that one could use in their app, in order to avoid re-inventing (or at least rewriting) the wheel. Notifixio.us is a Ruby On Rails application and benefits from a very broad and active community, which builds dozens of gems or plugins everyday! Both strategies, have their pros and cons.

Using “external” software components

  • Very very quick (no dev, no unit testing…)
  • Maintainable easily : if the software component is updated by its provider : you get the update for “free”, development-time-wise.
  • The code you’re using might very well happen to be better that the one you could write (at last in my case ;p)

Building from scratch

  • There is little chance that you find the exact piece of code you’re looking, in terms of functionalities, speed, … if you build from scratch, you can develop exactly what you actually need
  • You “own” the code, 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
  • You don’t rely on someone else’s technology… which can be problematic if the code is bugged, slow or not maintained anymore

What do you think is the best approach? How do you mitigate the pros and cons of each solution?

  • No Related Post

Viewing 7 Comments

    • ^
    • v
    "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.
    • ^
    • v
    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!
    • ^
    • v
    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!
    • ^
    • v
    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!
    • ^
    • v
    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.
    • ^
    • v
    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.
    • ^
    • v
    @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!
 

Trackbacks

(Trackback URL)

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus