Adam Smith vs. desarrolladores fullstack - ¿y productividad en DevOps?

Por Adam Smith, la división laboral puede hacer que sea 240 veces más efectivo (en el ejemplo de una fábrica de alfileres que produce alfileres en 18 pasos).

¿Por qué entonces los roles multidisciplinarios tienen tanta demanda si esto realmente reduce la productividad, o Smith estaba equivocado, por qué entonces?

Las búsquedas de "desarrollador fullstack" siguen siendo tendencia en Google, aunque aparentemente más lento que hace dos años:

=====

En resumen, un desarrollador de pila completa podría hacer prácticamente toda la cadena de valor (corríjame si me equivoco):

• Discuta con los clientes y refine los requisitos ágiles viables para su parte del trabajo.
• Decide qué arquitectura, herramientas y componentes elegir, solo dale un cuaderno
• Escriba código para frontend, backend, ingration, que es compatible con dispositivos cruzados y no requiere muchas pruebas, o lo incluye
• Perfil y datos de escape, use API Cloud AI / ML para funciones avanzadas
• Escriba el código IaC requerido y despliegue
• Estar de guardia en caso de error o procesos de ventas
• Tenga en cuenta el diseño relevante para la seguridad, los parches generales, la migración y la modernización
• Horario de cuenta de una manera escrutada para facilitar la facturación del empleador
• ... olvidé algo?

UPD - " necesitamos la productividad de la especialización, pero no queremos la visión insular del mundo de la" división extrema del trabajo ". (DevOps Guys, " DevOps, Adam Smith y la leyenda del Generalista " , 2013-2016)

Hay dos tipos de trabajo:

1. Explotación : el trabajo bien definido que se puede dividir fácilmente en etapas bien definidas, donde cada etapa se puede aprender y dominar por sí mismo y el traspaso entre etapas no requiere comunicación.

2. Exploración : el trabajo indefinido, que requiere aprendizaje y experimentación para lograr cada etapa, y el traspaso entre etapas requiere una gran cantidad de comunicación de todo el aprendizaje y el estado del proyecto.

Adam Smith se preocupa totalmente por la explotación y no por la exploración. El trabajo realizado en los departamentos de Investigación y Desarrollo de la industria es, por definición, principalmente de exploración, por lo que Adam Smith no lo cubre de ninguna manera.

Pero hemos visto que en etapas posteriores de mejora continua, que son en parte un trabajo de explotación, la aplicación de CI / CD puede generar ganancias similares en productividad, que de alguna manera podrían ser atribuidas a Adam Smith por alguien muy imaginativo.

Adam Smith no necesitaba considerar pasar información de una etapa a otra. Esta es una parte crítica de cualquier proyecto de TI significativo. Entonces, un desarrollador fullstack tiene las ventajas significativas que:

• no tienen que hablar con nadie en otro departamento para hacer las cosas
• no tienen que esperar a que esas otras personas se pongan manos a la obra
• hay muchas menos posibilidades de que algo se pierda en la traducción entre una capa y otra

Para más información sobre la importancia de la transmisión de información en proyectos de TI, vea el Mes del hombre mítico de Fred Brook .

En mi humilde opinión, la respuesta tiene mucho que ver con la escala y la disponibilidad de recursos.

Creo que la teoría de Adam Smith solo se puede aplicar a gran escala: naciones / economías enteras en el contexto original o, en el contexto de desarrollo de SW, grandes equipos de desarrollo.

En un equipo grande es, de hecho, más eficiente contratar recursos humanos más especializados:

• no son estrellas de rock, a menudo consideradas una señal de peligro en organizaciones tan grandes
• generalmente son más fáciles de encontrar, más baratos que aquellos con un espectro más amplio de experiencia
• Por lo general, no aumentan los riesgos de deserción; por ejemplo, no serán infelices porque solo usan un subconjunto de sus habilidades.
• En una comparación de devopsia (quizás extraña), el principio de "ganado contra mascotas" se puede aplicar en organizaciones tan grandes, y por razones bastante similares. Estos recursos especializados son, desde la perspectiva del negocio, literalmente solo capita en los recursos humanos, cuyos tamaños se pueden ajustar rápidamente según sea necesario, generalmente mediante contratación / despido.

Ah, y dichos equipos solo pueden ser funcionales si se complementan con recursos de arquitectos de alta calidad que serían necesarios para dividir el producto en las tareas más pequeñas y especializadas que pueden abordarse con los recursos especializados.

En una escala más pequeña o incluso en equipos de una sola persona (típicamente nuevas empresas o incluso equipos más pequeños aislados en organizaciones más grandes) es ineficaz o incluso imposible usar dichos recursos y aún así hacer el trabajo:

• simplemente no tienen el presupuesto / recursos para contratar los muchos recursos especializados diferentes necesarios para cubrir todo el desarrollo del producto
• en realidad buscan / aprecian estrellas de rock que pueden usar múltiples sombreros e inmediatamente cambian de roles con gran flexibilidad, sin incidentes de demoras y costos adicionales de recursos humanos

Me considero un desarrollador fullstack sobre la base de la siguiente combinación de responsabilidades:

Programación frontal y posterior

Puedo hacer cambios en la interfaz de usuario hasta cierto punto: escribir html, css (como desarrollador web) y, por otro lado, proporcionar datos a la interfaz de usuario desde la base de datos, proporcionarlos en un servicio, etc.

Dejo a un lado las pruebas, la arquitectura y esas, la reunión de clientes se puede agregar a la descripción de trabajo.

Opuesto

Lo opuesto a mi punto de vista serían los roles estrictos de los usuarios de la interfaz de usuario y de los usuarios finales.

Conclusiones

No veo la pila completa realmente tan completa como mencionaste, más bien una expresión elegante como ágil o nube que en ciertas condiciones solo tiene que mencionarse para atraer la atención de las personas y la implementación real puede variar enormemente. Al menos sobre scrum y ágil, he visto tantas variaciones que los términos se han quedado sin significado.

En resumen, no creo que Adam Smith se haya equivocado, pero sí creo que hay algunas diferencias serias entre su modelo de división laboral en manufactura y silos en desarrollo de software.

Primero, el ejemplo de fábrica de alfileres (hasta donde yo sé) era simplemente hipotético; Aunque la mayoría de las fábricas modernas de fabricación pueden rastrear sus raíces en esta división del trabajo, no conozco ningún estudio que haya probado científicamente esta hipótesis.

En segundo lugar, Smith estaba principalmente interesado en la fabricación de bienes materiales; Hay ciertas salidas tangibles asociadas con la producción de material que no tienen análogos similares en el desarrollo de software. Por ejemplo, en la fabricación de alfileres, las dimensiones físicas son importantes como requisito funcional; No hay comparación obvia a eso en el software. Esto es importante porque los objetos tangibles se pueden replicar mediante la repetición exacta; El desarrollo de software nunca es el mismo problema dos veces. Los desarrolladores desarrollan métodos comunes para producir resultados predecibles, pero nunca codifica el mismo problema dos veces. Cualquier componente desarrollado en la pila tiene complejidades a diferencia de los componentes físicos, y esas complejidades tienen interacciones más allá de la medición tangible (altura, peso, longitud, etc.). A un puntero no le importa cómo funciona el cortador de alambre, siempre que el cable se corte de acuerdo con las especificaciones. En desarrollo de software,Los límites nunca son tan claros .

No se espera que los desarrolladores de la pila completa hagan todo el trabajo ellos mismos (no están destinados a ser un solo fabricante de pines), pero se espera que sean capaces de comprender todos los elementos de la pila y cómo interactúan esos elementos. Un equipo completo debe estar compuesto por individuos en forma de T que se especialicen en una o más áreas, pero entiendan el espectro (y puedan intervenir en algún nivel).

Donde creo que el trabajo de Smith es válido en el desarrollo de software es en el área de cambio de contexto (o multitarea ); Si un único desarrollador es responsable de todas las áreas de desarrollo, lleva tiempo pasar de una responsabilidad a otra. A escala, la colaboración entre los miembros del equipo con diferentes experiencias en el mismo equipo de producto puede equilibrar el cambio de contexto y las interacciones complejas.

Un punto importante a entender es que la división del trabajo no siempre significa una persona diferente por paso.

Tomaría mi propia historia en una fábrica de automóviles, estaba en una cadena de ensamblaje de asientos, para obtener un asiento completo con airbag, cuero, reposacabezas, etc., la cadena se dividió en 9 etapas. Éramos 9 trabajando en la cadena. Cada persona estaba haciendo solo una etapa a la vez, pero cada hora estábamos cambiando a la siguiente etapa para evitar demasiadas repeticiones. El día de trabajo fue de 8h, así que no subimos a cada etapa todos los días.

Esta es exactamente una división de trabajo en la que realiza solo un paso del ensamblaje en un momento dado, que no le impide poder realizar el ensamblaje completo.

Como ya se indicó en otras respuestas, esto es un poco diferente al desarrollo de software, pero creo que esto arroja luz sobre por qué un desarrollador de Full Stack no se excluye mutuamente con la división laboral, alguien con las habilidades para manejar el ciclo de vida completo de una aplicación no lo es. requerido para hacerlo todo el tiempo.

En general, cuando escucho al desarrollador de FullStack, pienso más en alguien capaz de codificar back-end eficientes y una interfaz de usuario agradable al mismo tiempo, en oposición con Front y Back Dev.