- Dmitry Mamonov , Wrike "De bicicletas a motocicletas: por que desenvolver suas próprias soluções pode ser melhor do que usar estruturas prontas."
- Vladimir Krasilshchik , Yandex “Bem-vindo, ou ciclistas não são permitidos”
- Vyacheslav Lapin , EPAM – Hackeando a “curva de entrada”
Como o processo de desenvolvimento do seu próprio produto difere dos projetos de terceirização do ponto de vista técnico? Quando faz sentido investir no desenvolvimento do zero e quando é melhor adotar uma solução pronta?
No desenvolvimento de software, escrever suas próprias bicicletas é tratado como o romance do trabalho. Os programadores compartilham orgulhosamente suas bicicletas e as publicam no Github. Segundo o palestrante, trata-se de projetos “Hello World” com o objetivo de aprender algo, ou bobagens do tipo “Não nos lembramos por que inventamos uma bola de bilhar da qual cresce cabelo, mas foi terrivelmente difícil”.
No seu discurso, o orador irá discutir as questões que um “ciclista” ou líder de equipa de “ciclista” deve colocar-se antes de ir para o Tour De France. Ele dará exemplos de bibliotecas e frameworks cujo surgimento foi justificado e ditado por uma abordagem pragmática, bem como exemplos de criações cujo surgimento é impossível com base em considerações pragmáticas.
Inventar “bicicletas” é uma ótima técnica de ensino! Os aspirantes a artistas copiam principalmente as pinturas de mestres, então por que a síndrome do NIH é considerada um mal em TI? Afinal, para entender como funciona uma biblioteca ou framework, o melhor é tentar resolver sozinho o problema que eles resolvem, geralmente escrevendo algo semelhante.
Desde que passamos para um modelo de aprendizagem constante e permanente (na verdade, aprendizagem e trabalho tornaram-se um processo unificado), a “construção de bicicletas” apoia-nos perfeitamente nisso, sendo essencialmente uma prática de aprendizagem: lemos tutoriais, artigos, assistimos discursos em conferências e tentar experimentar um pouco disto nos nossos projectos de combate, encontrando assim o caminho mais curto ao longo da “curva de entrada” para uma nova tecnologia.
No entanto, muitas vezes esta não é a forma mais curta, barata e segura de resolver os problemas comerciais do cliente, por isso é raro que o cliente concorde com isto. Para onde deveria ir um “desenvolvedor pobre” em tal situação?Isso será discutido no relatório de Vyacheslav.
GO TO FULL VERSION