- Dmitry Mamonov , Wrike "De bicicletas a motocicletas: por qué desarrollar tus propias soluciones puede ser mejor que utilizar estructuras ya preparadas".
- Vladimir Krasilshchik , Yandex “Bienvenido, o no se permiten ciclistas”
- Vyacheslav Lapin , EPAM – Hackeando la “curva de entrada”
¿En qué se diferencia el proceso de desarrollo de un producto propio de los proyectos de subcontratación desde un punto de vista técnico? ¿Cuándo tiene sentido invertir en desarrollo desde cero y cuándo es mejor adoptar una solución ya preparada?
En el desarrollo de software, escribir tus propias bicicletas se considera el romance del trabajo. Los programadores comparten con orgullo sus bicicletas y las publican en Github. Según el ponente, se trata de proyectos de "Hola mundo" cuyo objetivo es aprender algo, o tonterías del tipo "No recordamos por qué inventamos una bola de billar de la que crece el pelo, pero fue tremendamente difícil".
En su discurso, el ponente abordará las preguntas que debe plantearse un “ciclista” o un jefe de equipo “ciclista” antes de acudir al Tour de Francia. Dará ejemplos de bibliotecas y marcos cuya apariencia fue justificada y dictada por un enfoque pragmático, así como ejemplos de creaciones cuya apariencia es imposible según consideraciones pragmáticas.
¡Inventar “bicicletas” es una gran técnica de enseñanza! Los aspirantes a artistas en su mayoría copian las pinturas de los maestros, entonces, ¿por qué el síndrome NIH se considera malo en TI? Después de todo, para comprender cómo funciona una biblioteca o un marco, es mejor intentar resolver el problema que resuelven usted mismo, generalmente escribiendo algo similar.
Desde que pasamos a un modelo de aprendizaje constante y permanente (de hecho, el aprendizaje y el trabajo se han convertido en un proceso unificado), la “construcción de bicicletas” nos apoya perfectamente en esto, siendo esencialmente una práctica de aprendizaje: leemos tutoriales, artículos, miramos discursos en conferencias e intentar probar algo de esto en nuestros proyectos de combate, encontrando así el camino más corto a lo largo de la "curva de entrada" a una nueva tecnología.
Sin embargo, esta no suele ser la forma más corta, barata y segura de resolver los problemas comerciales del cliente, por lo que es raro que el cliente esté de acuerdo con esto. ¿Adónde debería ir un “desarrollador pobre” en tal situación? Esto se discutirá en el informe de Viacheslav.
GO TO FULL VERSION