El sentimiento moral del desarrollo de software

Autor: Xu Xiaobin (Xiaobin)

Hace más de doscientos años, hubo un gran filósofo en Escocia, su nombre era Adam Smith. Hoy en día, la gente sabe más sobre él como economista, y todos creen que descubrió la mágica ley económica de la "mano invisible" y su famosa "La riqueza de las naciones". Sin embargo, además de este libro, Smith también publicó otra gran obra: "La teoría de los sentimientos morales", que es una obra maestra filosófica y literaria poco común. Vale la pena mencionar que creo que este libro puede ayudarnos a comprender varios problemas encontrados en la ingeniería de software contemporánea y también puede ayudarnos a explorar algunas soluciones a dichos problemas.

1. Empatía

La palabra "empatía" (o "empathy") es popular en la sociedad moderna. Esta palabra se expresa en inglés como _empathy_. Por ejemplo, vimos a una pareja de amantes reunidos después de una larga ausencia en la calle. Sonríamos; y cuando Vemos a alguien indefenso a causa de una enfermedad grave, también nos sentimos tristes desde el fondo de nuestro corazón.



Por supuesto, empatizamos con la felicidad, la tristeza y la ira de los demás, no solo por las emociones que muestra esta persona, sino también porque entendemos su motivación para expresar emociones, y su motivación es razonable. Por ejemplo, si alguien fue golpeado accidentalmente y enojado sacó un cuchillo para apuñalar a la persona que lo golpeó, entonces nunca sentiríamos empatía con la ira; pero si la esposa y la hija de alguien fueran violadas y él sacó un cuchillo enojado para apuñalar al criminal que lastimó a su familia. Todos podemos entender y aprobar este enojo.



Aunque las personas tienen la capacidad de sentir empatía, el grado de felicidad y tristeza que pueden experimentar los demás suele ser muy débil en comparación con su propia experiencia personal. La impotencia y la soledad de una persona críticamente enferma, incluso si un extraño observa el lugar durante mucho tiempo, puede experimentar la impotencia, probablemente menos de once; el éxtasis de un ganador de la lotería, la experiencia de felicidad que otros pueden tener también es muy débil Sí, algunos incluso pueden sentir celos.



Como receptores y ejecutores de emociones, cuando las personas que nos rodean reconocen emociones como la felicidad, la tristeza y la ira, nuestra felicidad se duplicará, nuestra tristeza podrá aliviarse y nuestra ira también podrá ser reconocida. y luego se ventila.



En opinión de Smith, el mecanismo de recompensa y castigo de la sociedad se desarrolla sobre la base del principio de empatía entre las personas de la sociedad. Cuando una persona, por buenos motivos, realiza algunos comportamientos y hace que otros se sientan cómodos y felices, entonces los espectadores pueden empatizar con la comodidad y la felicidad del beneficiario y comprender los buenos motivos del beneficiario, entonces aceptarán recompensar al benefactor. ; cuando una persona, por malos motivos, realiza algún comportamiento y hace que otros cosechen dolor y tristeza, entonces los espectadores podrán empatizar con el dolor de la víctima y no estarán de acuerdo con la motivación del mal comportamiento del perpetrador, entonces aceptarán castigar. el perpetrador.



Ejemplos de recompensas incluyen: un joven que pasa por un pequeño río ve a un niño ahogándose en el agua y, con el motivo de salvar a otros, implementa un acto de rescate. Al final, el niño se salva y la familia del niño escapa. mala suerte. Nosotros, como espectadores, todos estaremos de acuerdo. Dale recompensas a este joven; en términos de castigo, todos los casos de delitos son ejemplos, por ejemplo, alguien al costado de la carretera ve el teléfono móvil en la tienda, para para satisfacer su propio deseo, comete el acto de robar, causando daño al dueño de la tienda, luego como un espectador Los que robamos aceptaremos castigar al ladrón.

2. Ética y desarrollo de software

A partir de la empatía, las personas van formando gradualmente un consenso sobre las recompensas y los castigos. Smith cree que la llamada moralidad es un consenso (o reglas) que cuando la sociedad sigue este consenso, toda la sociedad prosperará. Y aquellos que no pueden formar un buen consenso, o cuando el consenso no puede ser seguido por la sociedad, entonces el desarrollo de la sociedad irá mal y declinará gradualmente. Smith escribió un siglo antes que Darwin, pero aquí podemos ver la sombra de la evolución, es decir, para la naturaleza (o Dios), una sociedad que puede evolucionar la moralidad puede hacer que esta sociedad se adapte mejor a la naturaleza y prospere.



En la sociedad, cuando las personas se llevan bien entre sí, no sólo deben considerar sus propias emociones e ignorar las alegrías y tristezas de los demás. Cuando las personas consideran sus propios sentimientos, también deben aprender a considerar los sentimientos de los demás y actuar de manera que beneficien a los demás, para que toda la sociedad pueda prosperar.



Volvamos al tema del desarrollo de software. De manera similar, un desarrollador no puede pensar sólo en sí mismo o en la máquina, sino que debe aprender a considerar los sentimientos de otros desarrolladores y actuar de manera que beneficie a otros desarrolladores, para que toda la organización de I+D pueda prosperar. Muchos desarrolladores creen erróneamente que mientras el software pueda ejecutarse, no tiene nada que ver con la máquina ni con otras personas, pero todos solo necesitan pensar en cuánto código han leído y mantenido durante el año pasado. El sistema entregado por otros comprenderá lo errónea que es esta idea. Ningún desarrollador escribe software desde cero. En las organizaciones grandes, los desarrolladores dependen de los productos intermedios de otros desarrolladores para trabajar diariamente y también producen constantemente productos intermedios. Estos productos intermedios incluyen:



• Documentación: Describe cómo está diseñado el sistema y describe cómo se utiliza la API. Cuando el trabajo de investigación y desarrollo depende de un sistema existente, es necesario comprender el diseño del sistema existente, especialmente cuando es necesario modificar el sistema, es necesario comprender el modelo central del diseño.

• Código: ya sea utilizando servicios (y clientes) proporcionados por otros, utilizando marcos de middleware o asumiendo sistemas heredados. El nuevo trabajo de I + D requiere una comprensión profunda de estos códigos. Si estos códigos son fáciles de entender, introducen dependencias innecesarias y tienen suficiente cobertura de prueba (para que sean fáciles de modificar) afectará en gran medida la eficiencia de la I + D.

• Servicios: el negocio de nivel superior dependerá de una gran cantidad de servicios de nivel inferior, especialmente en la fase de prueba. La calidad y estabilidad de los servicios de nivel inferior tendrán un gran impacto en la eficiencia del trabajo de prueba. Algunos servicios de nivel inferior, como el almacenamiento en caché y la mensajería, ahora suelen ser proporcionados por la nube, y la calidad de estos servicios suele ser relativamente alta.



Cuando los productos intermedios de software que utilizamos en nuestro trabajo diario de investigación y desarrollo sean de muy alta calidad, sentiremos sinceramente gratitud y admiración por los autores de estos productos intermedios; entonces habrá disgusto y desprecio por el autor del producto intermedio de el corazón.



Y cuando todos en la organización, como autores del producto intermedio, siempre puedan considerar la calidad de estos documentos, códigos y servicios al producir y entregar documentos, códigos y servicios, esto tendrá un impacto significativo en otros desarrolladores. Si tiene su propio comportamiento, se exige estándares de calidad más altos y espera obtener la aprobación y gratitud de los usuarios de productos intermedios, en lugar de disgusto y desprecio, entonces esta organización ha formado una buena ética de desarrollo de software.

3. Ley de Postel

Existe un principio de diseño quizás menos conocido en informática: la Ley de Postel (también conocida como principio de robustez):

> Sé conservador en lo que haces, sé liberal en lo que aceptas de los demás.

Este principio fue descrito por primera vez por Jon Postel en el protocolo TCP: cuando las computadoras se comunican a través del protocolo, para el contenido que otras computadoras se envían a sí mismas, se deben considerar varias situaciones anormales e irregulares, es decir, varias anormalidades deben digerir activamente. ; cuando envía contenido a otras computadoras, debe tener una especificación estricta y cumplirla estrictamente.

Aunque el alcance de la Ley de Postel es el diseño de sistemas, creo que para formar un equipo de I+D eficiente, la colaboración entre personas también debe seguir el mismo principio. Como autor de productos intermedios de software, cada I+D debe ser responsable de sus propios productos. borre las especificaciones y sígalas estrictamente. Sólo "siendo conservador en lo que haces" podrá mantener (o incluso mejorar) la eficiencia del trabajo de I+D en el nivel superior; de lo contrario, el trabajo de I+D en lo más alto es como instalar bombillas en una escalera desvencijada, su Se puede imaginar una baja eficiencia.

4. Ineficacia de la ética de la I+D de software

En el artículo anterior, traté de explicar que la calidad de los productos intermedios de software (incluidos documentos, códigos y servicios) es crucial para la eficiencia general de la organización de I+D; una buena ética en el desarrollo de software, o a veces se considera una buena cultura de ingeniería, Todos han formado una cultura de consenso que se enorgullece de ofrecer productos intermedios de software de alta calidad y se avergüenza de ofrecer productos intermedios de software de baja calidad.



Sin embargo, en realidad, a menudo vemos que muchas organizaciones no logran formar esta cultura de consenso. Por el contrario, el sistema no tiene documentos de diseño claros, no revisa el código para ejecutarlo rápidamente, el sistema no realiza pruebas completas, el código no tiene cobertura de prueba unitaria y el cliente proporcionado por otros agrega mucho. de dependencias irrelevantes. Todo tipo de fenómenos son comunes y pueden usarse. Hay demasiados bambúes para describir.



Cuando la I+D se topa con este tipo de fracaso moral de la I+D de software, a menudo se sienten frustrados, impotentes o incluso enojados. Algunas personas sienten que el entorno de I+D es duro, el equipo poco atractivo y el liderazgo incompetente; otros piensan que el trabajo es así y, aunque no es ideal, lo aceptan en silencio y se acostumbran. Intentar cambiar un statu quo insatisfactorio, pero no abandonarlo, o volverse insensible al statu quo y acostumbrarse a él, parece ser el resultado más común.



Si pensamos nuevamente en la teoría de la formación moral de Smith, podemos entender por qué falla la ética del desarrollo de software en las organizaciones, y las razones directas de este fracaso son:

1. El acto de producir software intermedio de alta calidad no se recompensa como debería.

2. No se castiga como debería ser la conducta de producir productos intermedios de software de baja calidad.



Cuando hablamos de la calidad del software con cualquier TL de I+D, ningún TL le dirá que la calidad del software no es importante. Pero todos entendemos que la clave de un asunto no es lo que dice esa persona, sino cómo lo hace. Cómo hacerlo se refleja específicamente en: cuando la prioridad de la calidad y otros factores entran en conflicto, cómo tomará la decisión el TL; cuando el TL evalúa y promueve al equipo, si se debe utilizar la calidad de la I+D como índice de evaluación central.



En organizaciones y equipos donde la ética del desarrollo de software falla, vemos sin excepción: cuando la calidad y el tiempo entran en conflicto, se prioriza el tiempo y se sacrifica la calidad; cuando la calidad y el alcance funcional entran en conflicto Al mismo tiempo, la prioridad se puso en la expansión. del alcance funcional, y se sacrificó la calidad; al realizar la evaluación del desempeño, la contribución de la I+D en la calidad no se evaluó seriamente. La contribución de la calidad a menudo se pasa por alto cuando se evalúa de manera integral desde las perspectivas de la capacidad y la contribución de la calidad.



Solía ​​​​pensar que el problema de la calidad del software y la eficiencia de la I+D era un problema técnico, porque la tecnología avanzada no se entendía ni se aplicaba, pero creo que todos pueden entender mi punto de vista. El núcleo de la eficiencia de la I+D no es una cuestión técnica, sino una cuestión sociológica, una cuestión humana.

5. ¿Qué debo hacer?

Dado que se trata de un problema humano, debemos empezar por cambiar el comportamiento humano. Aquí, primero debemos hacer que la información de calidad sea transparente, de hecho, para permitir que los comportamientos relacionados con la calidad obtengan la debida evaluación. La transparencia es un requisito previo para una evaluación razonable.

Ya sea una metodología de desarrollo de software ágil o una metodología lean, todas enfatizan Build Quality In. Esta frase significa que la calidad se construye en cada detalle del proceso, y solo se considera la calidad del producto de software final o la calidad del resultado. inaceptable. Una vez que se ignora la calidad del proceso, muchas repeticiones y correcciones de errores afectarán seriamente la velocidad de entrega del producto.



La mayoría de las organizaciones hoy en día están muy preocupadas por la calidad de los resultados, lo más típico es la disponibilidad de los servicios, las quejas de los clientes, etc. Esto no es un problema en sí mismo, pero es decepcionante que pocas organizaciones parezcan prestar suficiente atención a Build Quality In, la calidad del proceso, y que esta información no se muestre de forma clara y transparente. Por lo tanto, es necesario transparentar la calidad del proceso, que en el proceso de desarrollo de software incluye específicamente:



1. El código es completamente abierto: para que otros puedan ver el código enviado por cada I + D (git culpe es un comando muy útil), y la calidad del código es naturalmente clara de un vistazo;

2. Los documentos de desarrollo son completamente abiertos (también se requieren registros de versiones): para que otros puedan ver el diseño y el pensamiento de cada I+D;

3. La implementación del mecanismo de revisión de código permite que los colegas revisen cuidadosamente el código antes de que ingrese al troncal;

4. Panel de CI: también se muestra de forma transparente si hay suficiente cobertura de pruebas unitarias automatizadas, etc.



La transparencia de la información de calidad es sólo el primer paso, y el segundo paso es vincular la transparencia de la información con el mecanismo de incentivos. Esto es como, suponiendo que podemos ver autos pasando los semáforos en rojo en la carretera durante el día, pero en realidad pasar los semáforos en rojo no será deducido ni multado, entonces siempre habrá muchas personas que continuarán pasándose los semáforos en rojo; otro ejemplo es que vemos a alguien en el camino, todos sabemos que ha hecho lo correcto al ayudar a un anciano que ha caído al suelo, pero cuando el anciano lo chantajea en lugar de agradecerle, y nadie se acerca a ayudar que lo demuestre, por muy noble que sea esta persona, no seguirá realizando buenas obras.



Por lo tanto, la organización debe incluir la contribución a la calidad del software del personal de I+D en los criterios básicos de evaluación al evaluar el desempeño. Pero en este momento vuelve a surgir la pregunta: ¿es el supervisor capaz de evaluar la calidad de I+D de cada equipo de I+D? ¿O al supervisor le importa la calidad de I+D de cada I+D?



El primer punto que quiero expresar es: una de las responsabilidades principales de un supervisor debe ser preocuparse por la calidad de la I+D, porque esto determina la eficiencia de la I+D de la organización. Un supervisor al que no le importa esto es un incompetente.



El segundo punto que quiero expresar es: es posible que el supervisor no pueda evaluar de manera integral la calidad de I + D de cada equipo de I + D del equipo, porque después de que algunos equipos se hagan más grandes, el supervisor no podrá captar los detalles, pero en este momento él puede hacer dos cosas cosas:

1. Transparente, transparente, transparente: haga que la información de calidad entre equipos y entre equipos sea visible para todos.

2. Introducir el mecanismo de EIA: permitir que aquellos estudiantes de I + D con habilidades técnicas superiores y excelente calidad participen en la evaluación juntos en el equipo o entre equipos.



Una de las responsabilidades centrales de los gerentes es estimular continuamente el comportamiento que la organización necesita y oponerse o incluso castigar el comportamiento que es perjudicial para la organización. Como gerente de un equipo de I+D de software, uno debe ser capaz de comprender en profundidad los comportamientos que son beneficiosos y perjudiciales para la I+D de software y luego establecer un mecanismo a largo plazo en el equipo. En última instancia, se establece un entorno donde la investigación y el desarrollo están llenos de felicidad y pueden liberar plenamente la creatividad. Una organización así también debe estar llena de competitividad en los negocios.



Lo anterior es lo que me inspiró Adam Smith, al que llamo " el sentimiento moral del desarrollo de software ".

Otras lecturas

[01] Teoría de los sentimientos morales de Adam Smith

https://en.wikipedia.org/wiki/Relational_algebra

[02] Ley de Postel

https://devopedia.org/postel-s-law

[03] Calidad de construcción en

https://www.scaledagileframework.com/built-in-quality/