Bienvenidos a Startup Insights Stories de idNIC, un podcast semanal donde hablamos de Startups y
tecnología. Podéis ver el podcast en idNIC.net para podcast y escucharlo a través de iTunes,
e-books y RSS. Bienvenidos una semana más al podcast de idNIC, soy Bernat Parrero,
CEO de idNIC, y esta semana estoy con Paul Ramón, CTO de Factorial, Ilya, CTO de Camalún y
Enric, CTO de Kipu. Hola, buenas tardes. CTO de Kipu desde hace unas horas. Unas horas.
Aquí anunciamos la primicia. Muy bien, hoy haremos un formato nuevo, experimental, que
básicamente consiste en tirar dilemas, dicotomías, preguntas típicas del mundo tecnológico de las
startups y en menos de un minuto nos tenéis que dar vuestra impresión. Entonces, si vemos en una
ronda de preguntas de ese tipo que hay discusión o que hay tal, dedicaremos otro minuto a discutir.
Pero he apuntado, entre Ilya y yo hemos apuntado unas cuantas preguntas, a ver cuántas llegamos.
Entonces, empezamos por la primera y empezaremos por Paul Ramón. Y voy a poner aquí el cronómetro.
Entonces, primera pregunta. ¿Cómo elegimos un stack tecnológico? En mi caso particular,
cuando escojo un stack tecnológico para un proyecto que no sea personal, intento mirar
que sea conveniente para mí. O sea, Ilya lo entienda suficientemente. Quiere decir que
he tenido experiencia en producción con ese stack, pero a veces también intentar añadir
algo un poco más moderno, igual o algo menos conservador, para poder reer talento. Entonces,
no solo es conveniencia, igual cosas conocidas, sino un poco de modernidad para reer talento
del futuro. En nuestro caso, por ejemplo, somos más conservadores en el backend y un poco más
futuristas en el fronte. Ilya, as soon as this podcast should be about more like black and white,
and depends is not the possible answer. So, why would answer that way, that you should select
the stack which your developers are just like comfortable with, because. In my experience,
normally I was working in the companies which were just startups and they were starting up.
So, it's not my timer. Continúate. So, obviously they need to deliver fast, you will be delivering
fast on the technology that you know. So, for me it's normally, if you have three developers,
pick the average technology that they are kind of good enough on them. Enric? Sí, realmente mi
respuesta es bastante parecida a la de ellos dos. Yo creo que la parte más importante, sobre
lo principio una startup es algo que quien esté liderando tu desarrollo tenga confort con ese stack,
no solo desarrollando, no solo facilidades de desarrollo sino habilidad de divulgar cuando
hay programas en producción con ese stack. Y la segunda parte para mí es, aparte conveniencia
para el producto, facilidad rápida de desarrollo, también que donde en tu pool de hiring haya
bastante más crítica con ese stack, bastante más crítica de gente con habilidad con ese stack.
Para mí esto es un punto muy importante porque de lo contrario pues te limita tu crecimiento
como negocio. Vale, su pregunta relacionada, mezcla de tecnologías, de stacks en una misma
aplicación, en un mismo problema digamos de negocio o no? Dependiendo si tu negocio lo requiere. Sí,
si por ejemplo tienes una parte muy maleable de que requiere un lenguaje flexible como hacía maleable
en el front-end, puedes seguir utilizando por ejemplo Ruby o Node.js porque realmente hay una gran
facilidad y adaptabilidad al cambio, pero si la parte crítica de tu negocio es algo con una necesidad
muy alta de transaccionalidad, mucho rico es por per second, pues entonces a lo mejor moverte algo
mucho más adaptado a este workload aunque no sea lo más fácil para todos los desarrolladores,
algo por ejemplo como Java, depende mucho del negocio, pero en mi criterio sería este.
No, estoy solo haciendo esto en mi mente, es demasiado complicado.
Entonces, para lo que Anik dice, obviamente depende del trabajo, pero de nuevo es muy difícil,
así que vamos a responder algo diferente. Creo que lo que voy a agregar otra regla a eso es un factor clásico.
Entonces, si tienes un equipo que preferirá algún tipo de lenguaje extraño de ese modo, y luego
hace esta parte intranomal importante en ese lenguaje, y luego algo le ocurre a él,
decidió ir o tal. Entonces obviamente tienes un problema, porque tienes que
comprar para esa exacta lenguaje o para implementar eso desde scratch. Entonces,
constantemente contrabalance entre intereses y tecnología, y la altitud de esta tecnología,
y tu decisión de negocio, cómo puedes apoyarla después.
¿Es el número de tecnologías? ¿Estás se preguntando?
¿Convinar distintas tecnologías en una misma aplicación o no?
En mi opinión, a pesar de que hay que escoger lo que sea más adecuado,
cuantas menos mejor. En mi experiencia, también por el tipo de equipos que a mí me gusta montar,
me gusta montar equipos que toquen muchas tecnologías, pero en mi stack prefiero tener
cuantas menos mejor. Cada una de las tecnologías requiere siempre partes móviles, requiere cierto
tooling, requiere cierta infraestructura. Si se puede evitar añadir una tecnología,
en mi opinión, sale escanando. A pesar de eso, hay veces que no hay otra,
porque el dominio es específico y requiere cierta tecnología.
La tecnología web evoluciona, digamos, el presente y el futuro. Está más en el browser,
en la frontera, o más en el servidor, en el backend. ¿Cómo veis esta dicotomía?
Ilya. Lately, I'm seeing more and more like unification,
because even if we're talking about writing JavaScript, there are like fewer and fewer
edge cases when just like thinking, oh, this is just a browser technology.
And if it's just a browser technology, normally you can find some kind of pony field,
whatever field, for Node.js. I think it's awesome and it's perfect, because then you can code
the same application for web workers, nodes, browsers, and whatever.
So I'm really happy on one side that we have kind of unified language across the stack now,
but obviously that brings the complexity of the whole ecosystem that we have now.
So I'm happy and not happy at the same time.
Bueno, para mí es una pregunta un poco rara, pero yo creo que no, es al final, browser
o no, siempre en aplicaciones donde la lógica de negocio no vive en el cliente, o sea,
aplicaciones no más que se destruyan antes, como Flopidies o en un CD, sino que la lógica
de cliente vive en una base Atox, que es Cloud o lo que sea, que es normalmente aplicaciones
web son sea así, a no ser que sean aplicaciones distribuidas, que eso lo creo que lo podemos
hablar más adelante.
Entonces, en general, yo creo que siempre la tecnología va a avanzar diferente en el
servidor y en el cliente, el cliente es un browser, pero bueno, en el tiempo de aplicaciones
puede ser un móvil o puede ser cualquier otra cosa, entonces creo que la tecnología
avanza para en ambos lados.
Hombre, perdona que refine la pregunta, pero ha habido un shift muy importante de lo
que antes se hacía en el servidor, la logica de servidor, el browser era más tonto, digamos,
hoy el browser tiene toda la información y el servidor es más tonto.
Ha llegado a un punto donde el browser pasa a ser un cliente, un cliente como yo os mando,
es antes que el browser solo renderizaba y ahora tú puedes hacer aplicaciones, pero
al final, insisto, o pasas toda la lógica de negocio al browser, entonces ya estamos hablando
de aplicaciones distribuidas, yo creo que no vamos a llegar ahí, o a menos no en el
corto tiempo, o sigue siendo una economía cliente servidor.
Enrique.
Sí, yo opino, para ti, anda igual que pago en este sentido.
Al final, yo creo que también depende un poco del tipo de aplicación y siento ciudad
el depende tan a menudo, pero al final tú lo que quieres es un proceso masivo de datos
porque tu negocio si lo requiere, pues es obvio que una gran parte de tu complejidad
y tu carga de trabajo va a estar en el bucket, pero si es verdad que por también como la
pedagogía que se ha ido haciendo en estos últimos años, 10 últimos años en base
a los usuarios, esperan aplicaciones mucho más responsivas, donde al final esto una
aplicación con un heavy client siempre va a triunfar sobre algo que esté pendiente
de su backend y además ahora mismo con los avances en los browsers, tenemos una potencia
que no sé, a 5 años vista, no hubiésemos esperado, sobre todo y esto es lo que he potenciado
que el potencial que te da un entorno dinámico de desarrollo como el browser, se aplique
a otras tecnologías como el mobile, el caso de React Native, el feedback loop es mucho
más rápido para la iniciativa de código que desarrollan un hablativo, entonces mi respuesta
depende, pero sí que soy consciente de este shift y me parece que tiene todo el sentido.
Pechando que Pau hablaba de paradigmas centralizado-descentralizado, ¿veis un cambio importante en cuanto
a la tecnología en este aspecto, paradigma centralizado-descentralizado?
Por ejemplo.
Sí, los avances que se están haciendo a nivel de descentralización, que es una palabra
muy difícil de decir, lo voy a evitar, son muy importantes y realmente el research que
se ha hecho desde que se publicó el PPR de blockchain han sido brutales, no solo a nivel
de la escritura, sino ya a nivel de base datos mismo, cuando se están hablando de tenemos
cierto programa que corre en varios ornadores al mismo tiempo, yo creo que al extremo donde
no hay un servidor en sí es bastante más complejo y se está viendo que incluso individuos
que se han dedicados completamente a ello han sido bastante incapaces ahora en día con
la tecnología que venía de hacer productos similares a los que tenemos hoy en día ni
tan solo con una fracción de la funcionalidad, creo que estamos lejos de eso.
Otra cosa que hay que ver y es los que somos fundadores y los que vemos por parte del
negocio es un poco los modelos como cambien si tú distribuyes tu software de forma descentralizada
que de forma descentralizada y yo creo que también estamos bastante lejos de entender
exactamente cómo funcionan esos modelos.
Enrique.
Sí, yo creo que los avances en la descentralización y en la computación distribuida está destinado
a solucionar una serie de problemas que son siempre basados en redes de confianza, confianza
de identidad, confianza verificabilidad, veracidad en la transacción, confianza en un histórico,
pero a su vez el Piro Gopao que hay una gran cantidad de complejidad organizacional no
tecnica alrededor de esto que aún está lejos de verse solucionado y sobre todo cuando se
trata de cómo te gustaría distribuir tu software descentralizado 100% el coste efectivo.
Sí, yo estoy pensando en el concepto de distribuidas descentralizados si estamos hablando de aplicaciones
no microservices o otras estructuras internas, parte de mí como técnico más geeky parte
es feliz porque es obviamente algo nuevo interesante que puedes leer, puedes hablar de eso, pero
la parte que piensa que quiero distribuir algo que mis clientes pueden usar ahora no
es feliz porque somos adoptores, si juegamos con estas tecnologías serán adoptores,
necesitas convencer a las personas que es tu nueva manera de usar aplicaciones y los problemas
que vienen con eso, que son cool y shiny y también necesitas ser adoptores y intentar
todos los problemas que vienen con eso, así que no estoy feliz porque siendo adoptador es
también algo cool, pero normalmente es una cosa problemática y si quieres construir un
negocio por encima de esto, es una vez o más, es más problemático que construir esto.
Si estamos hablando de la estructura de microservices, no microservices hype, creo que es muy...
Podemos dejar esta pregunta para más tarde, en particular la de microservices.
Puedes dar su pregunta relacionada con esta y si es tu idea, veo que una pegatina en el
ordenador de Pau que pone IPFS, Interplanetary file system, esto es un approach que se hace,
una propuesta basada en blockchain de cómo distribuir el sistema de archivos que puede
ser usado por storage, pero también puede ser utilizado como la propia web y plantear
otra forma de usar la web o de implementar la web.
Este sistema IPFS en particular, ¿le veis futuro?
Ideal.
Ah, es muy difícil de decir, si estamos hablando de ropa y ropa, creo que obviamente vamos a
ver más en la actualización en los próximos años y la tecnología tendrá que ser más
o que tendrán más adaptaciones en los próximos años, por el gobierno y por las otras empresas
que intentan controlar la web y especialmente el contenido, es un futuro.
Esa fue la pregunta, ¿no?
Si, si, era una pregunta de casi de si o no.
Pau, si tú tienes una pegatina con un one.
Vamos contribuiendo, por cierto.
Este IPFS hace unos tres años y conocí el equipo de atrás del proyecto y la verdad
es que unas bestias, es increíble lo que están haciendo, pero al final no es la tecnología
o lo que esa gente será capaz de hacer, sino al final es si todos los demás seguiremos
no todos los demás, sino los que hacen productos adopten esos nuevos protocolos o deciden,
como ha dicho Irán antes, ser él y adopten esos protocolos para tearse la piscina.
Entonces, como he dicho en la pregunta anterior, yo creo que aún nos falta entender bien qué
paradigma sería ese y cómo funcionarían esas aplicaciones en las cuales tú no tienes
un world carden, donde tú no tienes un control sobre el contenido, sobre lo que sea. Ahora mismo,
todo lo construimos, lo construimos, lo tengo yo y te lo dejo usar, cambia un precio y aquí
cambia el paradigma, que eso es lo que no entiendo bien. Y si la gente no es capaz de hacer negocios o
utilizar esas herramientas, no solo negocios, no utilizar parciales aplicaciones o solucionar
problemas, entonces el protocolo no va a funcionar. O sea, ahora están nuestras manos.
Bueno, yo para ser sincero, prácticamente no conozco y no soy muy consciente de las
implicaciones. Son un poco así el nombre, sé que pretende solucionar y me parece un
objetivo muy idópico, que es conseguible, pero al final todo depende de la masa crítica y de si,
al final la gente está de acuerdo con las implicaciones de algo totalmente distribuido. Las
implicaciones que tiene a nivel de revocación, de contenido que no quieres que esté en una red
como esta, al final, contenido que no te pertenece, que vulnera a los derechos de alguien, pero tú
no eres el propietario, no es quien tiene la firma para revocarlo. Entonces este tipo de cosas,
tienen las implicaciones que como decía antes, no son técnicas, que van mucho más lejos.
Y la similación, realmente entender que significan es lo que va a hacer que esto sea masivo o no,
en mi opinión.
Aprovechándola el paradigma que te he cortado antes, Lilia, sobre microservicios o megalitos o
monolitos, megalitos, monolitos. Normalmente son más megalitos, Lilia. Este dilema que todas las
empresas en un momento, un día que se despiertan y dicen, tenemos que cambiar todo a microservicios,
o no, tenemos muchos servicios, no hay quien los gestione, tenemos que re-centralizar. Este
dilema, ¿qué opinión tenéis? ¿Cómo lo veis? Lilia, no sé quién le tojaba, me estoy perdiendo.
Logicamente, puedo ver la separación, porque todos dicen que son microservicios, ¿qué significa eso?
Estamos hablando de cómo estructuralizamos el código, y cómo dibujamos las fronteras entre
cosas, o cómo dibujamos las cosas en el cloud. Normalmente, las personas están totalmente
cambiando y mezclando estas cosas, hablando de diferentes cosas. La primera cosa es cómo
dibujamos la estructura, es para vosotros, cómo dibujar el modelo domain, cómo decidir quién
está trabajando y qué, y también puedes tener microservicios dentro de tu perfecto megalito
o monolito que trabaja como uno monolito, pero lo separa logicamente. Y eso lo
amo mucho y eso es lo que estoy intentando, y creo que nuestro equipo está haciendo un buen
trabajo, intentando separar esto y escribir los modelos domaines en el papel. Pero personalmente
no lo vi en un año, porque tal vez más de los tamaños del equipo, así que la compañía
es, por ahora, veo mucha complexidad de deployar microservicios en el cloud, como
un servicio de separación real, y luego intentando trabajar con los sistemas de distribución, por
ahora, para los tamaños de las compañías y las complexidades que tenemos, es más problemático
que any advantages.
Tengo una opinión muy fuerte, gracias, es una opinión muy fuerte respecto de este tema.
Si se pueden evitar los microservices, en mi opinión es mejor, no siempre puedes, por
ejemplo, tener una calculadora de IRPF, que es un Java, que nos da al gobierno, y eso es
un microservice, porque no lo voy a calificar en Ruby. Entonces, a veces no te queda otra.
Pero en mi opinión, hay dos argumentos que, nuevamente, salen. Uno es el tema de escravididad,
que en general 99% de los tiempos no es justificado. Yo llevo muchos años haciendo software y nunca
he tenido grandes problemas de escravididad, más allá de provisionar un par de máquinas
entonces, a no ser que seas una empresa, tocha, entonces tienes gente más lista que tú, que
ya te vas a solucionar el problema, igual lo utilizan microservice o lo que sea, pero en
general no es un problema.
Y la otra cosa que intenta solucionar yo, que es un poco lo que ha contado Ilya, es una
idea un poco paternalista, es decir, tú no eres capaz de arquitecturar bien el código,
por lo tanto te obligo a separarlo en formas unitarias, de tal forma que no puedas acoplar
ciertos servicios unos con otros. Y yo creo que, bueno, está bien, pero igual creo que
las ventajas de la memoria compartida son más útiles y arquitectura que he dormido
en el código, que no un apoyo tan paternalista.
Enrique.
Sí, bueno, yo tengo la opinión de que sí, al final, el tema de utilizar aplicaciones
virtuales en Servicio Work o a Servis Oriente de Arquitectures o ya yendo al extremo microservices,
es algo que al final todos hemos vivido un poco del hype y yo tengo experiencia en primera
mano sufriendo las bondades y los problemas derivados de una arquitectura basada en microservicios
y al final no todo está bonito como lo cuentan, tiene una cantidad brutal de implicaciones
como y sobre todo hay que ser muy conscientes a nivel empresa, a nivel de organización
de realmente por qué migras aquí. Y si no lo tienes claro, no tienes cristalino, decir
que no. Obviamente no estoy hablando de grandes escalas, pero a nivel de startups que tienen
mucho crecimiento, tienen mucho una gran transaccionalidad, tienen que pasar a manejar
grandes cantillas de datos, se puede llegar muy lejos con una estructura monolítica, tiene
problemas, pero también las tienen las arquitecturas a orientar a servicios. Al final las implicaciones
últimas de que algo que antes era un call a otro módulo ahora sea una llamada red,
esto llega muy lejos, al final tus equipos tienen que ganar conocimientos sobre lo que
ahora se llama t-box, tienen que casi siempre, porque esto siempre pasa en arquitecturas
cloud, si quieres migrar a microservicios o a arquitecturas orientadas a servicios sin
estar en el cloud vas a tener problemas, van a tener problemas de rapidez, de blockers
por falta de hardware virtual, te va a arrendizar mucho. Yo creo que como decía Pao es si no
lo tienes clarísimo, al final tu negocio vive o muere según cómo puede escalar un
servicio de forma muy distinta al otro, por ejemplo lo que responde fronten con lo que
tus servers frontales tienen que tener una necesidad mucho más baja de escalado que la
que tendría un servidor RPC que pones a la disposición de todos tus clientes, esto
podría ser un caso, pero esto no pasa tanto y no pasa tanto además en las startups, lo
que pasa es que las startups tienen objetivos de hiring ambiciosos. Y microservicios venden.
Obviamente, ven aquí y vas a hacer de shiny new thing, me vengo y me voy a pasar bien,
pero este pasar, pasar todo bien a acaba de tener un coste a veces asumible, a veces
completamente mortal para la startup, a nivel de arquitectura y de complejidad. Vale, una
cosa está ahora, estáis muy de acuerdo a todos, estaría bien que os pegaráis un
poco, de vez en cuando, ya sé que aquí en Inix se habla mucho, no entiendo, que habéis
consensuado todos los puntos previamente. Creo que simplemente teníamos un poco sentido
con todos y es lo que sabe. Vale, oye, pregunta un poco más abierta. ¿Cuál es la última
tecnología que os ha flipado? Enrique. Bueno, por mi parte vendría a ser todo lo relacionado
con la segmentación y clasificación de imágenes y de vídeos, es decir, el reconocimiento
de imagen. Es un campo que en los últimos cinco años, cuatro, está dando los pasos
brutales de cosas que antes solo veías en TED Talks y en vídeos de Futuribles a cosas
que están 100% en producción y me parece increíble. Al final, soy muy profano en este
tipo de materias, intento prender lo que puedo, pero fascinado, seguro que estoy.
Ilya. Ok, así que AI y mucho proceso ya se ha cubierto, y ya hablamos sobre las
cosas descentralizadas y los lockchains, ya se ha removido, creo que voy a bajar a un
poco más de un nivel práctico, y lo que podemos hacer todos los días. La más reciente
y más reciente que podemos usar ahora es Graphkill, porque no es tan raro, no es tan
emocionante que AI o lockchains, no es tan diferente de las cosas que podemos
utilizar, pero es aún algo nuevo, y ya está en el estado donde puedes añadir
a tu proyecto y obtener todas las advertencias. Entonces, finalmente puedes encontrar
los buenos artículos sobre las prácticas mejores, cómo empezar a usar Graphkill,
y no es solo Wild West anymore.
Es un Wild Calling, ¿verdad?
Exacto, así que en términos de balance entre los chinos y los usables, sí, mi
voto va a Graphkill.
Pao. Para mí no es una tecnología, es un cambio mentalidad que ha reflejado en ciertas
tecnologías, que es el tipado gradual. Siempre ha existido la fase de autonomía, como siempre
existen tecnologías entre lenguajes estáticamente tipados y únicamente tipados.
Muchos de nosotros nos gusta la metáfora de los cuchillos que cortan, no nos gusta
ir con algo que va rápido, no nos gusta empezar rápido un proyecto y ir a saco, pero
llega un momento y dices, vale, esto, hay que apuntarlo un poco.
Uno de los proyectos que ha hecho esto de forma muy correcta, que es Flow, en JavaScript,
un lenguaje que todo el mundo se reía, y con Flow tiene un sistema de tipos bastante
potente y bastante flexible, que te permite ir de no tipos a todo el tipado que tú quieras.
Ahora se está viendo otros lenguajes dinámicos que se ha intentado adoptar también el tipado
gradual y para mí eso es algo que me gusta mucho.
Oye, ahora vamos a hablar de los perfiles que os gustan como CTO, ¿no? Y voy a crear
dicotomías que ya sé que siempre son grises, siempre son dependes, pero con el depende nos
vamos a aburrir todos. A ver, si tenéis que elegir entre un perfil junior con potencial,
curiosidad, ambición, whatever, versus un programador senior rockstar con experiencia
y tal, ¿con qué os quedáis?
Pao.
Yo, aunque el último podcast que salía aquí el titular fue que los junios no deberían
trabajar en startups, nunca dije eso, pero es el titular que salía ahí. Elegiría el
junior con potencial, principalmente porque el senior rockstar no me lo puedo permitir.
André.
A pesar de tener las budgets constrained igual que Pao, o peores, al final sí que yo siempre
regiría y sobre todo si mi decisión no está condicionada por el short-term, que muchas
veces lo están, al final casi siempre está haciendo el writing, es porque tiene una necesidad
concreta que cubrir, no puedes hacer como un Google, un Facebook, un Netflix o un Amazon
que es, al final, grado its open engineers, we don't know what you're gonna do, but we'll
hire you anyway. Al final, claro, puedes permitirte contratar gente muy buena, no, no, es una
pregunta, pero al peso, para decirlo mal. En startup esto no pasa, pero si pasase, si
se has preparado más para el long-term, te estás preparando más para el long-term,
yo siempre elegiría la actitud primero y total entorrao aún sin especiidad, yo lo prefiero,
porque…
O sea, es junior con potencial, sí, 10%. Perdón que haya sido el titular, pero…
No, no, no.
No, no, no, perdón, tío. No hay que desmerecer nada, es explicar las cosas.
Ilya, I'm just thinking that I got a joke that Paul hired a junior. Enrique, I supposed
we'll go with senior guys, so then I would go with external agency, but in this case,
yeah, the tecotomies are really simple. If you have a really, at least someone senior
in the team that can train the junior guy to grow fast, then I would also prefer someone
with really bright eyes and talent and passion, but I don't like the word passion, but at
least in this sense.
No, passion no.
It's overused, it's like the same as Ninja, Rockstar, whatever. It could be whatever in
this case.
¿Cómo se queman las palabras?
Exacto. Normal, it's passion, not for technology, it's passion for either to learn or curiosity,
my preferred word, and also the idea to solve the problem that your business solve.
It's normal, it's also really, they should be interested in the main that we're doing.
Otra subpregunta relacionada, generalista, persona que sabe general, o especialista
que domina un stack muy en profundidad.
Elia.
Okay.
Again, if we're talking about startups, normally it's generalista, because I have like two
rules.
The first one, when I'm hiring, and I'm hearing from someone that, oh no, no, no, no, no,
backend is not mine, I'm like fully frontend, it's for me, it's a huge red flag, because
the question why, like, are you not curious again, why don't you like backend?
Este es un tip para toda la gente que está aplicando ahora mismo, que son muchos, nuestro
proceso de selección.
No, wait, yeah, normally the question is like why, because obviously you could have like
preferences, you could like, you could like technology, so the steps, but if someone just
like really says that I have a wall and I'm not going through this wall for some reason,
that's like, it's a question that they need to answer.
So I would prefer general, like at least, people with the white knowledge of technologies
and the whole stacks, but again, as always, it depends on the problems you have at least
now.
Si, bueno, yo siempre generalista, por un tema de asimetría, un generalista te puede
ir profundo si lo requiere, o sea, si tu tienes un problema muy profundo, un generalista
puede coger y especificarse en ese problema y llegar hasta al fondo.
Raramente he visto un especialista hacer lo mismo y generalizar, no lo he visto pasar,
entonces para mí siempre es mejor un generalista, también porque siempre trabajan en equipos
menos de 30 personas y entonces ahí las prioridades cambian muy rápidamente y tienes que estar
todo rápido diciendo vale, pues ahora todos vamos a enfocarnos a esto o haré más presión
aquí y no, o sea, tener gente que solo tiene, solo puede llevar un sombrero te limita muchísimo.
Los negocios requieren un buen mix de los dos, es decir, requiere necesitar a alguien que
en un tiempo agresivo de time to market te genere una transición entre pantallas, por
ejemplo, que realmente sea un go factor, obviamente ese no ser el cor de tu app, pero vas a agar
puntos con ello, pero si en la opinión igual, al final la especificidad es algo que puede
venir después, obviamente vas a pagar un poco lo de time to market, pero yo creo que
va a haber la pena.
No, con discusión.
Todos, todos, de acuerdo, muy bien.
Oye, preguntas, respuestas, cortas, ¿react o angular?
No sé quién le toca, pao.
React.
React.
O tal corta, no sé, bueno, vale, Enric, Enric.
Mi conocimiento de angular se quedó en el uno, o sea que ahora mismo lo estoy diciendo
barbaridades, pero supongo que react.
Enia, react.
Muy bien.
Rubio Python, Enric.
Depende, depende mucho, depende mucho del stack, pero si tu stack es web y Rubi es conocido
por Rails y su extreme, y su tiempo de development agresivo, por lo tanto, yo diría a Rubi,
pero bueno, depende del caso.
Si te toca AI, obvio que es Python.
Para todos los casos, Rubi.
Sí, yo creo que se están diferenciando mucho, o sea, con Rubi solo vas a hacer web o India
y con Python, pues cualquier cosa que sea un poco científica o marimánica, en Django
ordinario, creo que tampoco no ha ganado mucho.
Bueno, al final de los buenos negocios se funcionan con Django, no va a ser un gran
factor diferencial, pero bueno, sí, yo creo que estamos en acuerdo de lo mismo.
Otra pregunta un poco rara, eh, Stripe, Stripe o SerMepa, y esto lo que viene a decir es
API, SuperMolona, que a los desarrolladores les encanta por que tiene que hacer copy-pays
y se está escribiendo comentada, pero cara, cara por transacción o por uso, o API de
mierda con una documentación terrible que nadie entiende, pero barata.
Ilya.
You need to, like, use mathematics and count, because, caro, like, something cheap or not
cheap, it's also a little bit hard to say, like, really fast, even if something is like
twice or three or ten times cheaper than to implement, you still need to think about developer
time, hours that requires to add this API, and then also developers hours to support this,
and multiplying by average salary of the developer, I'm not sure that the bad API will be cheaper
as a result.
Nunca tenías esa discusión en mi vida, ¿eh?
Pao.
Eh, Stripe, porque lo otro, te lo he dicho yo, hasta hoy no había escuchado nunca esta
palabra.
La palabra SerMepa.
SerMepa, eso.
Tienes una suerte que, bueno, increíble, eh, Enrique, tú que sí has implementado o has
escuchado, al menos, SerMepa.
Sí, sí.
Y si le voy a conocer Mepa en otras vidas, pero, ah, yo diría Stripe, es decir, si al
final, eh, el éxito o fracaso de tu negocio depende del margen que te estás gastando
en la pasada de Pao, sin contar que lo que, lo que está ahí te va a dar en términos
de, de metrías, en términos de gestión, en términos de time to market, eh, tiene
un precio.
A final siempre, pues, implementar el, el, el Stripe primero y, y cuando realmente estoy,
este porcentaje en absoluto sea un número grande pasar a lo después, también vas a
tener más, más, más tiempo para hacerlo, más recursos para hacerlo, pero yo, en, en
caso de estar, diría siempre Stripe.
Por eso, eh, por si, al final, si la vida o muerte de tu, de tu negocio depende de, de
los márgenes entre uno y otro, vas mal.
Y voy a hacer trampa si voy a volver a responder.
Es trampa.
Para, para añadir a lo que he dicho ya, eh, no solo la matemática de lo que te cuesta
el programador o el tiempo de programación, eh, es el coste de oportunidad, pues no es
solo el coste, o sea, tú no vas a, a contratar un programador solo para, para programar la
integración de SEMEPA, sino que es el coste de que este programador no está haciendo
otras cosas que, en teoría, tienen que continuar en negocio, que eso, desgraciadamente no
se cuenta muchas veces.
Otra pregunta, eh, también es una dicotomía, tampoco os alarguéis mucho.
Cortar scope y lanzar, o alargar deadline y cumplir scope.
Eh, es que que no tocaba, eh, pa'u?
Eh, bueno, para mí el scope no es algo que esté escrito en pie, o sea, nosotros, a menos
de la forma que trabajamos, es que, decimos, esto se van a tragar esta fecha, y el scope
es lo que entre a esa fecha, o sea, sería el primero, cortar scope y lanzar, pero no
es que cortamos el scope, es que el scope, por definición, es lo que entre en ese time
frame.
Enrique.
A no ser que el equipo sea muy, muy, muy experimentado en lanzando producto, cortar scope y lanzar.
Al final, las constraints, otra cosa es si el scope es loco, pero las constraints ayudan
a dimensionar, porque si no el presupuesto tiene extra, lo que tenemos todos dentro, alargar
deadline es lo que puede.
Enrique.
Y estoy intentando recordar en algún momento cuando el scope fue, como, tan perfectamente
definido, y que podrías decir, ok, este es el scope que necesitamos, necesitamos
deliverar.
Normalmente es ultra, normalmente es ultra, normalmente es ultra, vagas conceptas, o sea, no tan vagas,
pero de todas formas, como, cualquier fecha, o cualquier cosa que vamos a hacer.
Entonces, cada día el scope cambia de todas formas, puedes encontrar algo nuevo, puedes
aprender más de todos los días, sobre la idea, sobre el domenio, sobre lo que estás
realmente implementando.
Entonces, todo el día cambia, por lo que, si lo mueves, o lo hace más pequeño, es un
proceso normal.
Entonces, en mi caso, creo que delivering algo es mucho más importante que hacer cosas
que pensabas, como, dos semanas, un mes, un año y medio.
Vale.
En respuesta es corta, pero si no nos quedamos en tiempo.
Comerse el legacy o start over, o sea, empezar cosas nuevas, es lo que se puede responder
a esto.
Hay Enric.
Start over.
Start over.
El leer código es mucho más evidente que escribirlo, y los rebrights, paga la pena,
en mi opinión.
Perfecto.
Ilya.
Bueno, perfecto, no, por esto.
Y esto es otro tema.
Lately, I would say start over, yeah.
Sí.
Because you said fast answers, and now, like, yeah.
Perdón.
Perdón.
Siguiente.
Siguiente.
Pao.
Yo tenía una respuesta y estaba viendo que están jugando aquí, no sé qué están
haciendo.
Sí, para la audiencia, tenemos aquí una sala al lado donde están jugando a juegos de
VR, y están como saltando y tal.
Entonces, cuesta concentrarse.
Sí, vale, yo voy a salirme de la dicotomía y voy a decir, tercera vía.
Sí.
Yo creo que es encapsular, también es una buena opción.
O sea, a veces no puedes, tienes una monstruidad, pero sí lo que sí puedes decir es, lo voy
a marginar, y al menos ahí queda controlado.
O sea, definirnos boundaries dentro del legacy, donde al menos el resto del código no se
puede afectar.
No siempre se puede hacer.
O sea, si me diera para dar una respuesta original.
Viendo las noticias en la prensa de empresas de startups overfunded o slightly overfunded
que contratan 100 desarrolladores de golpe, mi pregunta es, ¿se va más rápido o más
lento con 100 tíos versus un equipo de 10, 15?
Pero aquí empieza.
Bueno, yo te recomiendo que si quieres, si quieres respuestas diferentes, hagas preguntas
un poco menos obvias a dar estas.
Exacto.
Porque?
Porque ustedes vamos a responder lo mismo.
Ah, sí?
Sí.
Porque vais a responder?
Enrique.
Pero es muy obvio.
Ah, sí?
Que con 10 tíos van más rápido que 100.
Porque la pregunta no es cómo rápido puedes escribir el código.
Es más que cómo rápido puedes comunicar.
Y, como, la comunicación entre 10 tíos, como si escribieras el star y todas las posibilidades
de quién está hablando.
Y con 100 tíos, es como...
Enrique piensa así igual.
Pablo, evidentemente.
Si tienes bien establecida la poca comunicación entre equipos.
Porque mi opinión debe haber buena visión y poca comunicación.
Vale, puedes permitiéndolo en otro caso.
Es mi opinión.
Básicamente lo que estáis diciendo es que todas estas empresas están actuando de forma
absurda.
Están tirando dinero.
Y subiendo los precios del mercado en general.
No, no, no.
No hay porque ser absurda.
Tú aumentas el valor de tu empresa.
Porque, a mí, de cierto modo...
Porque gastas más y procesas menos.
Pero un activo importante, especialmente hoy en día en el mundo de los startups,
es el equipo que llegues a montarlo.
Entonces, tú puedes capturar una masa de desarrollo de eso hoy en día.
Eso es una serie que tienes en la empresa.
Eso es un tema.
El otro tema es ganas vanuiz de cosas en paralelo que puedes hacer.
No ganas velocidad.
Nada empieza con 100 programadores.
No puede programar extremadamente más rápido.
Pero sí que puede hacer más cosas distintas.
Seguramente, esto puede ser una buena noticia o una mala noticia.
Muchas veces tú no es capaz de pasar de tres iniciativas simultáneas a 20
y hacerlo de una forma sana.
Si no tienes objetivos, no los tienes bien diversificados.
Asimilar a gente haciendo push hacia una sola dirección,
ella parece muy, muy complicado.
Yo no estoy de acuerdo con eso.
Pero, bueno, esto sería añadir otra opinión.
Antes hablamos del paternalismo.
El hecho de decir no puedo gestionar con lo cual tal.
Esta discusión también se produce en el caso, por ejemplo,
de los equipos de proyecto por área de negocio,
problema de negocio, versus equipos que se planifican en su conjunto.
Si sabes planificar, si sabes gestionar,
puedes gestionar en un equipo más grande.
Al final, esto no es solo un problema de desarrollo.
Es que estos problemas pasan en cualquier área de negocio.
Gestionar mucha más gente es infinitamente más complejo.
Eso no significa que no se les pueda sacar partido.
Hay una diferencia por eso.
Lo que es que todos interaccionan con la misma cosa.
O sea, escalar un equipo de ventas, todo lo puedes hacer.
Por ejemplo, porque tú estás segmentando un mercado
que es suficientemente grande como para cada uno.
No sé, no hay a uno que es la...
En el caso de una base de código, hay uno que es la...
Claro que es que tienes una base de código o N o las que sé.
No están trivial como otras áreas de negocio.
O sea, a pesar de que esto pueda funcionar en otras áreas,
no es tan simple.
Lo que hay que hacer, evidentemente, no es que la productividad
de un equipo pequeño sea 100 veces mayor.
Obviamente, si tienes mil personas, va a ser más productivo
que un equipo de 10.
Pero hay que ver el trade.
Y los 100 de golpe, eso seguro que sí que no es viable.
Exacto.
Estás hablando no solo de tamaño,
estás hablando de velocidad también.
De velocidad de incorporación.
Bueno, esto sería otro tema.
Otra pregunta.
Sois partidarios de que cualquier persona de la empresa
pueda interactuar con el desarrollador e-kits.
O sois partidarios de tener project managers
que hacen de gatekeepers.
¿Qué le tocaba?
Ilya.
Que es un caso.
En el caso de Gamaloon,
esto es más importante que en el caso de equipo y factorial
por una razón, porque la parte de desarrollo
no es la parte más grande de la empresa como en unas otras.
Yo estoy pensando que, logísticamente,
obviamente, si quieres construir los sistemas,
quieres tener algún tipo de flow
y estar perfecto si todas las comunicaciones
van de una manera o de otra.
Y luego, después,
estará un canal para los desarrolladores.
Pero en realidad, no somos sistemas,
somos personas, tenemos que hablar con el otro
y tenemos que ser fascinantes
sobre los problemas del otro.
¿Te dice que es fascinante?
Hola, ¿qué tal?
Entonces, sí.
Lo prefiero, no lo prefiero,
me gustaría que los desarrolladores
puedan entender los problemas
más cercanos
de otros equipos más cercanos
y que puedan ser,
no sé si es fascinante.
Me gustaría que se soltara estos problemas
más rápido y también
si hablamos con los desarrolladores,
a veces,
entiendes los problemas
y luego entiendes cómo lo soltamos mejor.
Si hablar con el desarrollador.
Sí, pero obviamente
tienes que tener un balance.
Paú.
Estoy de acuerdo
en una parte con lo que he dicho Lea.
Estoy de acuerdo que no puedes
programar tu equipo como si fuera
un producto de ingeniería.
No, Santé es un ingeniero,
no lo puedo evitar, así que lo hago.
Yo creo que no.
O sea, sí que tienes que definir
un pipeline, en mi opinión personal,
en el cual la gente de tu empresa
no tiene que ser capaz
de dictar cuáles son las piedras
de tus desarrolladores.
He hecho una estreche
y he dicho hablar.
Y te he dicho dictar prioridades.
Hablar, claro.
No tenemos a los developers en una jaula
donde nadie puede hablar.
Es hablar para preguntar ¿puedes hacer esto?
O es hablar para decir
vamos a hacer una cerveza.
¿Se entiende perfectamente?
No, yo no.
Me refería a la cerveza.
Es entendido que me refería
ir a tomar una cerveza.
Obviamente no.
Me refería al hecho de interactuar.
Interactuar en cuanto al negocio.
En cuanto a su trabajo.
En cuanto al negocio implica
que pueden alterar
las cosas que tienen que hacer.
Si yo soy tratando de la funcionalidad
y me viene alguien a hablar conmigo,
altera esto lo que estoy diciendo.
El refinado, la funcionalidad, no la prioridad.
La prioridad es otra cosa.
Si estamos hablando de prioridad,
creo que la prioridad tiene que estar
en un único sitio definida
y eso sí que es un problema grande
que pasa en muchas empresas
que la gente dice me puedes hacer esto,
van directamente al desarrollador
y al final no hay nadie
que pienso como sistema, porque soy ingeniero
y me gusta pensar así.
Si es en términos de interacción,
yo creo que puedes...
Hay mecanismos para hacer que todo el mundo
entienda lo que pasa en la empresa
y los problemas que hay en ventas, marketing, etc.
y ponerlo en un punto para que sea.
Después de eso, también me gustaría
no cambiar, pero extender mi respuesta
porque si estamos hablando de prioridad,
obviamente no. Si estamos hablando de empatía,
no pasión, empatía,
entonces es infinitamente
más fácil y mejor.
Yo pienso que
la comunicación
con el equipo de desarrollo debería estar limitada
para...
para esto, para...
para una historia era un poco el focus,
pero no...
no pienso que la solución...
la solución debería ser managers intermedios
que lo único que hacen es frenar
y hacer forwarding, sino limitarlo por tiempo.
Limitarlo por tiempo
durante los ciclos de desarrollo,
sobre todo.
Ahora es el momento donde aportar
para todo el mundo.
Acabamos con dos preguntas
que sólo podéis responder
una o la otra. Ya no... ya no vale
el alargarse, ¿vale?
Reinventar la rueda
o amalgama
de librerías.
O la otra.
Pau.
Amalgama de librerías.
Amalgama, vale.
Otra... otra...
otra pregunta que puede ser sólo una u otra, ¿eh?
¿Se agrada familia?
Es decir,
¿release larguísima con un montón
de funciones, etc. o microrelease
en plan constante?
Microrelease.
Enrique? Microrelease.
Si hay una pregunta de esta manera,
creo que es muy difícil.
Qué mal lo estoy haciendo.
Vale.
Y code coverage,
test coverage
de
más del 90%,
¿tiene sentido? ¿Sí o no?
No.
Mejor monitoreo.
Si hablamos de finanzas
o...
Si tenemos una pregunta corta,
sí.
Sí.
Sí.
No siento.
Acceso de bases de datos
ORM
o apelo.
ORM.
ORM
pues no siempre.
Ahora mismo estamos en un punto...
Pero a ver,
son dicotomías.
Pasas, pero no son.
Es una tricotomía.
Continuous integration.
¿Sí o no?
Sí.
Bueno.
Lo vamos a dejar aquí.
Pero haremos una versión 2
porque han quedado preguntas en el tintero
y esto es realmente interesante.
Gracias a todos
por vuestra participación
y continuará.
Subtítulos realizados por la comunidad.