ElixirConf 2015 - Keynote: Elixir Should Take Over the World by Jessica Kerr

Elixir debería dominar al mundo

Gracias por venir a Elixir Conf

Creo que es algo alocado, para
muchos de nosotros, estar aquí

¿porqué tomar vacaciones?

¿ir sin paga?

¿Por qué vinieron personas, con sus
propios medios desde Europa?

¿Por qué?

No es como si alguien nos fuera a pagar
por escribir Elixir

en los próximos años

Muy probablemente no

Pero estamos aquí de todas formas

Porque nos importa

Porque estamos emocionados

Por que vimos algo

que puede hacer avanzar el estado
del arte en nuestro campo

pero también en nuestras mentes

y al parecer nos gustó

al parecer somos suficientemente bananas

para venir a esta conferencia
de todas formas

solo a hablar y aprender de una
tecnología que nos parece interesante

E importante para el futuro

de la programación

y por lo tanto para el mundo

Me recuerda mucho a la ciencia

Obtuve una especialidad en
física de la escuela

Y luego, tan pronto me gradué

Irracionalmente me moví a programación

fue en 1999

el año perfecto
para entrar a la programación

todo mundo estaba contratando
sin necesidad de un título

Y yo pensé: Wow! puedo obtener un
trabajo en cualquier ciudad

Obteniendo una mejor paga que la que
podría obtener un físico con doctorado

Y también es estimulante y divertido
y a las 5:30 puedo irme a casa

sin tarea

De maravilla!

Eso era excelente para mi!

Ahora me voy a casa y programo desde ahí

pero al menos escojo que
es lo que quiero programar

Pero muchas personas se quedaron en física

al menos un número

Y lo que hicieron fue

mantenerse en las ciencias,
obtener un doctorado

y luego posdoctorados

se dedicaron a la investigación

Tienen pasión por expandir
el conocimiento humano

Pasaron todos estos años
expandiendo su propio conocimento

para expandir solo un poquito
sus invertigaciones

con la esperanza de expandir
el conocimento humano

Hay un libro acerca de este proceso

fue publicado en 1962

La estructura de las
revoluciones científicas

por Thomas Kuhn

No lo recomiendo como material
para estimular la lectura

Pero me emocionó mucho

Aquí está mi segunda copia

y pueden ver que tuvo mucho amor

Pero es por supuesto que yo aplico todo
lo que dice directamente al software

Lo leí en el 2012

Me habría gustado leerlo cuando
estaba estudiando física

Habría hecho que la actitud
de mis profesores tuviese más sentido

Hay algo que aprendí de este libro

Les voy a dar el resumen

La tésis es

la historia de la ciencia se
cuenta de esta forma

Kuhn fue un Doctor en física

quien después se movió a
la historia de las ciencias

y revolucionó ese campo

porque dijo: esta es la forma en que
contamos la historia

La ciencia progresa gradualmente
hacia la verdad

Lidereados por grandes hombres

(siempre son hombres en estas historias)

Uno después del otro y
Franklin descubrió la electricidad

y Ampere encontró las dinámicas electricas

Y Maxwell unificó el
electromagnetismo y la luz

¿No es asombroso?

Y es lo que obtienes al leer la Wikipedia

pero Kuhn dijo:

Si revisamos los registros

y las cartas y la historia real

esto se ve mucho más complicado

El progreso en realidad pasa con ajustes

y comienzos

Puede haber una nueva teoría
que es super productiva

y luego

las personas van a trabajar con ella
por un tiempo

y mejorarla

y de repente algo
mucho mejor aparece

Y es mucho más complicada en
terminos de personas

Hay muchas personas
involucradas en este punto

Entonces, cuando Franklin estaba
estableciendo la electricidad

Muchos otros eléctricos
(como se decían a sí mismos)

Hacían muchas observaciones

Solo por hacer observaciones de cualquier
cosa que pudiese estar relacionada

con la electricidad

Por ejemplo, tenían una hoja de oro y
algunas plumas y vieron como

se atraían o repelían

Franklin vio el relámpago y notó
que era electricidad

Y había un dispositivo llamado "botella
de Leyden" básicamente el primer capacitor

Y fue inventado simultanea e
independientemente por

alguien en países bajos
y alguien en alemania

Y Franklin tuvo la suerte suficiente de
vivir en un momento donde había muchas

observaciones y fue capaz de relacionarlas

en una especie de teoría

e inventó una teoría de fluidos
de la electricidad

Que era que la electricidad era un fluido

y los objetos con mucho de este fluido
y los objetos con poco de este fluido

se atraen unos a otros

pero al mismo tiempo

En Francia

Du Fay estudiaba la atracción y repulsión

e inventó la
(ahora parece similar para nosotros)

Teoría de los dos fluidos
de la electricidad

Y hay un fluido positivo y otro negativo

Y funcionó

Hay aislamiento en las
moleculas y el ether

pero eran teorías donde las
personas se tenían que basar

y venir con más experimentos por hacer

porque el modelo conductor
detrás de cualquier

campo científico determina que
experimentos hará a continuación la gente

Qué pruebas verán relevantes de hacer

Eso es interesante

y funcionó en 1750

hasta que en 1820

Ørsted (Ilsted, era danés)
se dio cuenta que

una aguja de compás, que se
sabía tenía un fenómeno magnético

en ese tiempo eran dos fenómenos separados

reaccionaría a una corriente eléctrica

y esto fue una anomalía

esto no encajaba en ninguna
otra teoría del magnetismo

Una anomalía, cuando es reconocida y
aceptada como realidad, provoca una crisis

Una crisis es cuando el modelo
dominante deja de ser suficiente

y todo el mundo se da cuenta

y de repente todos dicen:
Oh pero estoy haciendo estos experimentos!

Y las personas es ponen a ver que pasa con
la corriente electrica todo el tiempo

Escuchamos de Ampere, vivía en Francia

Él hizo muy buenas matemáticas

Pero el no estaba solo

Trabajó con Laplace y Saberi y un montón de
personas que no se mencionan en Wikipedia

Y al mismo tiempo que él estaba trabajando

Estaba Fiat y Poisson y otro amigo cuyo
nombre no recuerdo y no puedo pronunciar

trabando en teorías competitivas,
que eran similares a las de Ampere

Y los llevó a hacer mejor ciencia de un
lado y a hacer mejor ciencia del otro

Y todas estas personas juntas

discutieron por un tiempo

hasta que finalmente, por ahí de 1827

Ampere publicó su libro de Electrodinámica
donde se acuñó el término

Y eventualmente ese se volvió el
texto aceptado

Y las personas trabajaron basadas
en su teoría

Donde la electricidad todavía era un
fluido y había moléculas aisladas

Ampere estaba muy apegado a
esa teoría

Eventualmente llegamos a Maxwell

Y pasó algo muy parecido

Pero esto se relaciona con la programación
en muchos sentidos por que

este libro

por cierto he hablado de modelos y teorías

cuando la palabra que uso Kuhn es
paradigma

Y se que todos dirán: AGH BUZZWORD AGH AGH

Este libro introduce esa palabra en
habla comun

Entonces cuando Kuhn usa la palabra
paradigma

Una y otra vez

Está siendo original

La palabra existía pero era rara vez usada

Y no significaba exactamente la
cosa que ahora significa

en este libro era

un modelo del mundo que nos conduce

a una forma de vivir o hacer
ciencias en este caso

y qué preguntas hacer

y porqué importa pensar en ello

La primer cosa que aprendí es que
las ideas se comparten

La segunda cosa fue que las ideas
siguen llegando

Puedes pensar que en algún momento
tenemos la verdad absoluta

como que Newton tenía una muy buena teoría

del movimiento, pero WOW no
consideró el espacio exterior

La velocidad de la luz y las super
duper nano partículas

Por supuesto que no

Incluso cuando pensamos que alcanzamos
la cosa perfecta

para el mundo como lo conocemos

hay algo más allá afuera

Y finalmente, las ideas se comparten

Esto regresa

Primero, Denise Jacobs, en Øredev
en 2013

habló de la creatividad

y una de las cosas que dijo
que se me quedó grabada

fue que cuando el mundo está
listo para una idea

cuando todas las bases están puestas
para una idea

No se le ocurre a una sola persona

Se le ocurre a varias personas

Dos personas inventaron la botella
de Leyden

Franklin y du Fay

Ampere y uno de sus compatriotas

No se le ocurre a una sola persona

Newton y Leibnitz inventaron
el cálculo al mismo tiempo

Porque todas las ideas se montan
sobre otras ideas

Y cuando todas esas otras
ideas están presentes

La misma idea se compartirá
por muchas personas

esto es muy tranquilizado para mi

Cuando estoy pensando

Oh tengo algo

es brillante y es importante

Y acabo de hacer esta conexión

y realmente necesito conectarla

porque puede afectar a todas las personas
programando alrededor del mundo

Y mis hijos tienen que ir a dormir

y uno de ellos se pegó en el dedo del pie
y hay muerte y perdición

Y yo pienso: A alguién más se le ocurrirá

está bien

Lo opuesto de esto es

si una idea viene a nosotros
de múltiples fuentes

si multiples personas piensan
en grupo acerca de la misma cosa

tal vez esa idea es importante

El modelo de actores

Ha estado en erlang por un tiempo

Pero ahora es más accesible con elixir

Y yo trabajé en akka con scala
que corre en la JVM

Y Orleans es el modelo de actores para C#

Y todos estos son sistemas útiles
a los que las personas están

siendo atraidas

Debe haber algo diferente

Tal vez hay una especie de crisis
en nuestro campo

que nos provoca buscar nuevos modelos

Ella es Camile Fournier en StrangeLoop
apenas la semana pasada

La que considero la mejor
plática de la conferencia

Y ella expresó el tema, en StrangeLoop,
como un todo

cuando dijo: Los sistemas distribuidos

son feos, son difíciles

y llegaron para quedarse

esto es muy cierto

y es una excelente plática, la recomiendo

pero el hecho es que hemos estado
trabajando en sistemas distribuidos

desde siempre

porque tienes cliente y servidor

cuando empecé a programar era la
arquitectura de todas las aplicaciones

caja - flechas - caja - flechas - cilindro

Oh sí, esas es cada una de
ellas, tienes razón

Ahora tratamos de ir más allá de
caja - flechas - caja - flechas - cilindro

porque esto no escala

por supuesto Bruce habló de esto

de una forma hermosa, esta mañana

y una cosa que mencionó

que creo que es un punto
importante para pensar

incluso si una aplicación sencilla
de cliente - servidor - base de datos

te está funcionando

puede manejar la capacidad de tus clientes

y tu base de datos es lo
suficientemente grande

y no tienes problemas para escalar

de la forma que los tiene Netflix

todos tenemos problemas para
escalar en nuestras cabezas

en un punto alcanzamos
nuestra capacidad intelectual

de las características que nuestra
aplicación puede tener

porque cada característica genera
una carga intelectual

cliente y el servidor y la base de datos

cada vez más grande

hasta que no podemos mantenerlo
en nuestras cabezas

este es el problema de escalar
software en todos lados

Incluso si piensas que no tienes
problemas de escalamiento

¿Cómo lo manejamos?

Hablamos hace rato, Bruce habló hace rato de

Servicios sin estado y las
limitaciones que hay

porque si queremos escalar horizontalmente

nuestro servidor

está bien

luego podemos empezar a
separarlo en microservicios

y ahora eso es convencional

Pero queremos un poco más que eso

Queremos una de esas conversaciones
ricas de la que habló Bruce

Ella es Caitie McCaffrey

También en StrangeLoop la semana pasada

Y ella dió una plática completa
acerca de servicios con estado

Y tres diferentes arquitecturas
para servicios con estado

Y las peleas en los sistemas distribuidos

Y lo difícil que fue ganarlas

Acabando, por cierto, con
Orleans y el modelo de actores

Que básicamente llegas a

está bien, no es suficiente tener ciclos
de petición y respuesta sin estado

No es lo suficientemente interesante

necesitamos tener un estado del otro lado

porque es más rápido, porque no
tenemos que consultar la base datos

todo el tiempo

Y es más rico, podemos hacer más
cosas con el cliente

de hecho puedes agregar muchos clientes

trabajando con el mismo servidor
de chat o cuarto de chat

o editanto un documento mutuamente

puedes tener multiples vistas con
el mismo modelo

cuando el modelo está en el
estado de tu aplicación

para el cual, por supuesto,
elixir está hecho a la medida

y movimos la base de datos por completo a
otra aplicación a donde pertenece

y puedes tener escalamiento horizontal
en esos servicios

y hacer la separación

y puedes tener más de esos
si usas microservicios

Estos son problemas difíciles de resolver

y me encantaría que pudiesemos resolverlos
todos con programación funcional

Porque la programación funcional
es el paradigma del momento

es la nueva moda

No tan nueva como elixir

pero sigue siendo asombrosa
y todo, ¿cierto?

y es asombrosa

En mi opinión la escencia de la
programación funcional es

el flujo de datos

tienes datos de entrada, que
pueden ser del mundo real

y haces transformaciones, tomas desiciones
y luego tienes datos a la salida

esto es hermoso para petición - respuesta

puedes tener una petición http de entrada

hacer algunas transformaciones y
producir una respuesta de http

y esto es adorable porque

manejas datos inmutables,
no tienes efectos secundarios

puedes tenerlos por fuera

pero no en tu transformación

lo que sea que entra

dada una entrada siempre tienes
la misma salida

y eso lo vuelve extremadamente
fácil de probar

y predecible y maravilloso

y no hay dependencias circulares

no hay nada brincando del exterior

desafortunadamente

la programación funcional no es suficiente

para resolver nuestros problemas
de sistemas distribuidos

El cálculo lambda no soporta concurrencia

Y el mantener estado

No es una de las fortalezas de
la programación funcional

¿Qué tal OO?

bueno, la programación orientada a objetos
definitivamente no es suficiente

Y eso es porque

La programación orientada a objetos

en su estado actual

en Java y Ruby

es una maraña desastrosa

que nunca cabe en nuestras cabezas

Siempre que tienes estados mutables

en particular tienes una
dependencia circular

que no puedes ver

cualquier cosa que pueda tener
una referencia al estado

del que tu también tienes una referencia

si ese estado es mutable, hay
una dependencia circular

y lo mismo pasa cuando accedes al mundo

Hay un montón de
dependencias circulares invisibles

que no sabes donde están

Oh, ¿estás leyendo de esta tabla?

¿Qué pasa si actualizas la tabla?
FFFFFF

Cualquier cosa, entonces todas
estas dependencias invisibles

y sus conexiones que ni
siquiera puedes ver

están mal

Y además, en Java y Scala no hay
nada que me detenga

de hacer que todas mis clases dependan de

cualquier otra clase en el paquete

oh y cualquier otro paquete
en mi aplicación

está todo ahí

Una cosa que empecé a hacer que
aprendí de clojure y elm

es, está bien, no voy a
tener dependencias circulares

las reconozco como una debilidad

Voy a dibujar mi pequeño
grafo dirigido sin ciclos

para las dependencias de mis paquetes

y las dependencias de mis clases

Una vez que haces esto

puedes reconocer que hay una fortaleza
de la programacion OO

y es la organización de código

es muy buena para los espacios de nombres

te da formas muy buenas de
agrupar código relacionado

y podemos usar eso una vez que hayamos
decidido no manejar estados mutables

Elixir tiene esa ventaja

Elixir tiene otra ventaja

Si vas al principio de OO

Cuando Alan Kay enunció el
concepto por primera vez

el principio que guío no tiene nada que
ver con lo que hoy hablamos en Java o Ruby

Es "dile no preguntes"

es mensajería asíncrona

no llamo getters para sacarte los datos

Solo te digo qué es lo que
se necesita hacer

y tu sabes como hacerlo

Qué es exactamente lo que
hace el modelo de actores

Me confunde un poco cuando las personas
hablande Elixir y Erlang

como lenguajes funcionales

porque, bueno, dentro de un
actor tienes inmutabilidad

y puedes hacer transformaciones de datos

y puedes tener programación funcional
dentro del proceso de un mensaje

pero los actores por si mismos y
sus interconexiones

son la escencia de la
programación orientada a objetos

es como la programación
orientada a objetos siempre debió ser

Entonces, podemos tener las
fortalezas de ambos

y además

la cosa que hizo a la
programación imperativa

y por lo tanto útil a la
programación orientada a objetos

útil

es que podemos acceder al mundo

podemos tener efectos secundarios

porque aunque nuestras transformaciones
de datos son adorables

quiero que mi programa haga algo

y en el modelo de actores tenemos
oportunidades de hacer algo

sin meternos el pie a nosotros mismos

porque tenemos ese aislamiento de fallas

Me encantó como lo expresó
Bruce esta mañana

Concurrencia sin aislamiento es solo ruido

Aquí tenemos la oportunidad de responder

porque en el peor de los casos

el mundo explota y mata a mi actor

solo necesito iniciar a un nuevo actor

y lo conecto a un mundo nuevo

donde sea que exista un mundo nuevo
dos segundos después

Y seguramente ese nuevo mundo
será más amigable

Tenemos aislamiento y eso
es crucialmente importante

Tan crucialmente importante como

que Elixir y Erlang reconocen las fallas
como un ciudadano de primera clase

No es algo de lo que no querramos hablar

No es algo que tratamos de evitar
haciendo código

Atrapa una excepción
abró llave cierro llave

uh

pero de hecho hacer algo con ello

lo cual es crucial

hay un paradigma que existe

en nuestra cultura

y también existe en un montón de lugares

que la forma de alcanzar el éxito

es evitando las fallas

pero lo que he visto en nuestra industria

en los últimos cuatro años

es mucho más útil

la forma de llegar al éxito

es a través de muchas fallas

es darle a una falla, reconocerla

aprender de ella, restablecerce

pegarle a otra falla, restablecerse

pegarle a otra falla, reconocerla,
aprender de ella restablecerce

es fallar rápido, y aprender de ello

y ese es el camino al éxito

esto es genial

porque nos deja ver que tan
importante es fallar

en nuestro código, tradicionalmente

amamos escribir la historia
del camino feliz

como se supone que nuestros usuarios
deben navegar a través de nuestro sistema

y tenemos este camino verde en nuestra mente

con florecitas a los lados

y está bien

tal vez un 98 % de las interacciones con
nuestro código se van por ese camino

pero el detalle con el código es

si corre 98 % de las veces o corre
solo una vez, es el mismo código

no contemos el número de interacciones,
contemos el número de caminos posibles

Hay uno o unos pocos caminos felices

que ojalá tomane los usuarios

pero hay una infinidad de caminos de falla

cada cosa que puede fallar es un caso independiente

y cualquier combinación cobinatoria
de todos esos caminos

tiene su propio caso

Entonces los caminos de fallo son
infinitos,

si contamos los caminos en lugar de
contar por donde pasan los usuarios

nos daremos cuenta que
la falla es el caso común

en el código

Y por eso es perfectamente natural

que la mayor parte de nuestro código

sea código para manejar errores

Si tratamos que un proceso

sea legible de una forma
que se cubran todos los casos

no solo los que queremos pensar

Me encanta como Elixir nos
permite hacer esto

con árboles de supervisión

y dejando fallar a los actores

También hay que considerar
esto en las pruebas

las fallas es el caso común también

porque cuando quiero depurar algo

escribo una prueba unitaria fallida

y falla, hago algo de trabajo, y falla

y hago algo de trabajo y falla

y hago algo de trabajo y
ahora pasa y ahí paro!

o tal vez refactorizo un poco y paró!

las fallas también es el caso
común en las pruebas

y es genial, porque tratamos
de aprender de esto

en la BEAM la máquina virtual de Erlang

tienes acceso a algunas de las
mejores herramientas de prueba

en el mundo

tienes acceso a Quick check

desarrollada por John Hughes

la herramienta original para hacer
chequeo de propiedades

y las pruebas por chequeo de
propiedades te pueden ayudar

a encontrar a la falla amigable
en el bosque del éxito

lo cual es realmente difícil

porque es miucho más sencillo para nosotros

escribir casos de prueba exitosos
que escribir casos de prueba de fallo

Es difícil para nosotros encontrar
el caso extremo que va a fallar

En las pruebas basadas en propiedades

no tienes que escribir cientos
de millones de pruebas

Me encanta esa parte

Escribes un poco de código

que genera las entradas para las pruebas

y casi podemos automatizar la escritura
de las pruebas que automatizamos

para correr

y eso es fantástico porque

te hace escribir menos pruebas

y es por lo que me interesa

pero también te ayuda a encontrar
los casos de prueba extremos

les recominedo que revisen QuickCheck CI

probablemente tengan que escribir
las pruebas en Erlang por ahora

pero es algo que podemos ver

por que sería asombroso
escribir pruebas de propiedades

QuickCheck CI es la herramienta
que creo John Hughes

que te permite correr Integración Continua
y correr tus pruebas

en una forma consciente de las propiedades

El detalle con estas pruebas generadas
es que no siempre genera las mismas

Cada vez que corres las pruebas
tienes pruebas diferentes

Lo cual es realmente genial

porque la cobertura de pruebas

constantemente está creciendo

pero es realmente molesto, porque si
en un parpadeo tienes una falla

no pasa la siguiente vez que la corras

pero Quick Check CI recuerda eso

y dice: Uh! la próxima vez que
corra las pruebas

voy a correr primero esa que falló

lo cual es super asombroso

y desesperadamente quiero algo así
en una herramienta de CI

Incluso hay más formas en las que
podemos aceptar las fallas

como ciudadanos de primera clase, nuestras
amigas, y podemos aprender de ellas

Aquí

Si tu objetivo es ir por el camino
de la ciencia

para aparecer en wikipedia como "el
físico más grande de todos los tiempos"

(ese es Maxwell)

Entonces, fallar es el
caso común aquí también

Pero si reconocemos
que las ideas se comparten

Y sí, Ampere obtuvo los créditos, pero
todos los que trabajaron con él

o contra él y lo guiaron
a hacer un mejor trabajo

contribuyeron a la electrodinámica

si lo vemos

y también todos los que
también escribieron libros

y artículos y notas

e hicieron la electrodinámica accesible

para todos aquellos que no sabían de ella

todas esas personas contribuyeron

y si defines eso como un éxito

entonces el éxito se convierte
en el caso común aquí

pero cada éxito es diferente

En Elixir, tenemos lo mejor
de la programación funcional

porque tenemos inmutabilidad

y flujo de datos

dentro de los actores

con toda la arquitectura de plug

es un flujo hermoso de datos

También tenemos lo mejor de la
programación orientada a objetos

tenemos independencia

en nuestros procesos de actores

y podemos ocupar el esquema
de organización de OO

porque tenemos "dile no preguntes"

tenemos lo mejor de eso

también tenemos aislamiento, que no
pertenece a ningno de esos paradigmas

el modelo de actores lo hace por nosotros

Maravilloso, tenemos esta idea grandiosa

y ahora podemos trabajar en este paradigma

y el cielo es el límite

¿verdad?

el cielo es el límite y ese es el problema

porque hay algo acerca del cielo

las ideas siguen llegando

y lo que pensamos que es la
mejor solución posible por ahora

es solo la mejor solución posible que
hemos visto en el mundo que vivimos

por ahora

y nos debemos seguir preguntando

¿Qué es lo que viene después?

¿Qué es lo que viene después?
Voy a hacer muchas predicciones

Que son por completo mi opinión

Pero será entretenido

¿Qué viene después de Ágil?

La respuesta a esto en mi opinión es Lean

No es nada nuevo pero todavía
no lo hacemos

Tomamos la escencia de Ágil

escribes un poco de código, se lo
muestras a las personas

y recibes algo de retroalimentación
para decidir que código escribir

Pero al mismo tiempo también estás
escribiendo código

tienes una retrospectiva donde ves
como le fue a ese código

y decides escribir código un
poco diferente

escribes mejor, casi el código correcto

y casi de la forma correcta

puedes hacer un poco de experimentos

porque no es tan amenazante

decir cambiemos algo en
las siguientes dos semanas

y veremos como funciona

y si no lo podemos regresar

si es necesario

eso es genial

estos ciclos de retroalimentación
realmente promueven el aprendizaje

y nos lleva a lugares que ni
siquiera sabíamos que existían

es difícil predecir resultados

pero podemos decir que los
resultados probablemente sean mejores

lo que es fantástico

El es Marty Caghan en la conferencia
Craft en Budapest, este año

Él habló de cómo solo el desarrollo ágil
es genial, pero es sólo

genial para los desarrolladores

pero no es suficiente hacer
nuestros negocios productivos

porque hay una probabilidad muy grande de
que estemos escribiendo el código erroneo

y puedes escribir el código erróneo
de la manera perfecta

todo el día, y no te va a llevar muy lejos

Para poder escribir el código correcto

necesitamos llevar estos ciclos de
retroalimentación al negocio completo

y Lean es este ciclo de
construir - medir - aprender

puse "aprender" hasta arriba porque
creo que es lo más importante

Requiere de todo el equipo

cómo un tipo de micro negocio

y la creación de la idea

la generación de la idea

y la validación de esa idea

tan rápido como sea posible

haciendo encuestas

o pequeños prototipos de papel

podemos validar o rechazar esta idea

en horas en lugar de meses o semanas

que tardaría escribir el software
para ella

descartar un grupo de ella y solo
mantener a las que parecen prometedoras

basado en mediciones

para entrar en el proceso de
producción de software

y el ciclo Ágil

esto es en realidad increible

pero vayamos un poco más lejos
y preguntemos

qué viene depués de "No estimaciones"

Porque tenemos estimaciones

Muchos de nosotros todavía
hacemos estimaciones

desafortunadamente

pero sabemos que son porquería

Entonces tenemos "no estimaciones"

que es el movimiento que dice

oh como las estimaciones son
porquería no deberíamos hacer estimaciones

porque de otra forma solo nos
llenamos de porquería

bueno, ese es un paso

pero podemos balancear el
péndulo de regreso un poquito

porque la realidad es que
necesitamos tomar decisiones

acerca de qué construir

y si no tenemos nada de estimados,
será muy difícil

basada en

esto viene de Dan North

lo que viene son estimados por rangos

porque si dices

¿Cuanto tiempo va a tomar esto?

WOAA veinte días

porquería

no lo sabes

pero lo que puedes decir es
que no lo sabes completamente

pero cuando alguién te presenta una idea

puedes decir definitivamente tomará
al menos dos semanas

tomará al menos un mes y medio

pero estaría avergonzada de admitir
que tomará más de dos meses

puedes ponerle ese tipo de rangos

y eso es más información de la que la
persona de negocios tenía antes

y si tu estimado termina siendo
algo entre uno y doce meses

ellos dirán : ¿QUÉ?

puedes decir: ok si quieres que invierta
un poco de tiempo en investigar esto

y en las cosas que encuentro altamente
inciertas y peligrosas

que me preocupan acerca de esto, bueno

puedo acerlo y venir después
de una iteración de trabajar

en no la parte más valiosa del software
no el retorno rápido

pero la más riesgosa

y la parte incierta del software

la parte que no piensas

que generalmente dejas al final

y tu último 20%
se convierte en tu siguiente 80%

si haces eso primero

entonces puedes acotar tu estimado

y en este punto hay una decisión y la
persona de negocios puede decir

está bien, basado en esta
nueva información

¿queremos continuar o no?

es algo que se pierde en
muchos procesos de negocios

cada iteración

del desarrollo de software debería
terminar con un punto de decisión

¿todavía vale la pena esto?

¿trabajar más en esto?

¿o hay una mejor oportunidad en otro lado?

también pueden decidir

¿cuál es el valor de esta información?

y ¿Qué tanto queremos
trabajar en las partes más riesgosas?

en lugar de la parte de
has un pequeño prototipo

Una información valiosa y medidas
de este tipo de cosas

si sonó útil para ustedes, entonces
les recomiendo este libro

¿Cómo medir cualquier cosa?

Es un poco aburrido también, pero

Oh fue escrito en el 2007

Es mucho más reciente

Y está en formato de audio libro

pero no podrás ver las hojas de cálculo
de ejemplo en la versión audible

No lo experimenté mucho

Este libro habla totalmente de
aceptar la incertidumbre

ya hablamos de las fallas siendo
ciudadanos de primera clase

haz la incertidumbre un ciudadano
de primera clase en tus estimados

y después podrás lidiar con ella

en lugar de ocultarla o correr

Alguien me hizo notar ayer

que este círculo se parece mucho
al método científico

Es como si hicieras una hipótesis

haces un experimento

analizas los resultados y vienes
con la siguiente hipótesis

Kuhn probablemente te diría: HAHA
no funciona de esa forma

Ampere, cuando estaba haciendo sus
experimentos sobre corrientes eléctricas

para encontrar la electrodinámica

y la relación con el magnetismo

y tratando de unificar ambas

Hizo experimentos donde
descubrío la inducción eléctrica

Pero la inducción eléctrica no
le ayudó a mejorar su teoría

no tenía un nombre en ese entonces

entonces, solo la ignoró

dijo algo como: mhn estó no es importante

debo encontrar algo relevante
que pruebe mi teoría

Mucha de la ciencia de hoy en día
está basada en su borrador

En ese tiempo, afortunadamente,
Faraday exploraba más

y reconocío la inducción eléctrica

y obtuvo el crédito por ello

y es mencionado en wikipedia

Hipoteticamente esto corresponde
al método científico

Pero si nada más confunde
su cabeza el día de hoy

El método científico no puede

aunque puede ayudar en
las ciencias naturales

¿no ayuda en nuestros equipos?

puedes hacer Test A/B

y tener grupos de control

y tener una especie de experimento
reproducible con tus clientes

pero no lo puedes hacer en tu equipo

¿Trabajará mejor mi
equipo si adoptamos elixir?

No puedes probar eso!

Porque solo tienes un equipo

con esos individuos

y su contexto

y el problema en el que
están trabajando particularmente

No puedes controlar los experimentos

El método científico no nos ayuda con

ciclos ágiles de aprendizaje y retroalimentación

¿Qué viene después del método científico?

No es una pregunta que
nos hagamos muy seguido

Tengo una idea

es solo una idea en este punto

La doctora Brené Brownes
una científica social

y estudia el entusiasmo, y la vergüenza
y las vulnerabilidades

Ella tiene una asombrosa charla en TEDx
que puede cambiar tu vida

dura 20 minutos, es muy buena

Y leí más de sus libros y el capítulo
más interesante para mi

por MUCHO

es el apéndice

Porque en el apéndice ella habla de
los métodos que ocupa para hacer

sus investigaciones

Y esto es estudiar un sistema desde dentro

porque cuando estamos en un equipo
estamos en un sistema humano

y podemos ejercer experimentos
objetivos y repetibles

bueno, estamos lejos de ello

Pero eso no se significa que no podamos
recolectar datos

no significa que no podamos elaborar
teorías

en nuestras retrospectivas

y aprender acerca de como funciona

las ciencias sociales incluso tienen
técnicas para esto

Particularmente René Brown ocupa
una teoría fundamentada

que dice: puedes empezar con una pregunta

¿Qué es el entusiasmo y como lo obtengo?

Y empiezas a recolectar datos

escuchando a las personas, principalmente

y haces una categorización que ellos
llaman 'coding' lo que lo hace confuso

pero es la categorización de
todas las historias

y las declaraciones de las personas
y las entrevistas

y luego eso encaja en una
nueva teoría

A lo mejor el entusiasmo tiene que ver
con, ella dice, las vulnerabilidades

Pero luego tomas eso, y eso
tal como cualquier otro paradigma

te lleva a las siguientes preguntas

donde tienes más datos que recolectar

y el ciclo de aprendizaje continua

y esto se puede hacer desde
dentro del sistema

estoy realmente fascinada con esto

todos estos círculos de
aprendizaje e innovación

y encontrar que es lo que
viene a continuación

son super fascinantes en las personas

y estoy totalmente de acuerdo que
pase con las personas en mi equipo

pero se mantengan fuera de mi código

no quiero que mi código sea salvaje y tome
direcciones que nunca podría predecir

Es ahí donde entran las dependencias
circulares o aun peor

Oh dios
enlace de datos bidireccional

UGH

Entonces les tengo que preguntar
¿Qué viene después de MVC?

No soy la primera que pregunta acerca
de esto el día de hoy

lo cual me hace realmente feliz

Chris habló de ello

Y mi respuesta acerca de qué
viene después de MVC

es la arquitectura de Elm

más o menos

Y ha habido mucha charla acerca de elm

lo que es asombroso

Y voy a hablar de él otra vez

En la arquitectura de Elm empiezas
con un modelo inmutable

entonces hay datos
y son immutables

y entonces un modelo encaja
en todas las partes de la vista

entonces produces HTML

de hecho estás produciendo
HTML en el tiempo y eso

pero hay un solo modelo immutable
que encaja en todas las funciones de vista

y tiene como resultado un tipo
que representa HTML

y luego esto funciona como React
donde tienes un DOM virtual

donde revisa las diferencias y
mágicamente actualiza la página rápido

pero la función de vista es
datos de entrada y datos de salida

un bonito flujo de datos

y luego llega al usuario