Deuda técnica creciente en pequeñas empresas de software indias que desarrollan aplicaciones y sitios web: ¿Quién es responsable de ello?

Llevo 10 años en la industria de servicios de software de la India y durante todo ese tiempo he visto cómo se completaban buenos proyectos y se hacían maravillas. He visto equipos esqueléticos trabajar incansablemente en condiciones angustiosas para crear productos que han gustado a personas de todo el planeta. Y aunque ha habido grandes recuerdos en esta década trabajando en algunos proyectos maravillosos, también he sido testigo de proyectos que van cuesta abajo y productos de software que se estropean debido a varias razones. Ha sucedido más veces de las que hubiera deseado a mi alrededor y con las personas que he conocido a lo largo de estos 10 años.

Mucho se ha hablado de proyectos que van mal. Los memes inundan Internet de cómo toda la jerarquía se persigue como una cadena alimenticia en la jungla. Algunas personas culpan a los programadores por escribir código defectuoso, mientras que otras maldicen a la gerencia por hacer promesas poco prácticas que son imposibles de cumplir. Algunas personas incluso culpan a los clientes por no comprender los requisitos técnicos y las dependencias de esta industria. Pero no he escuchado a casi nadie hablar de Deuda Técnica, o Deuda de Código, y tratar este tema de una manera civilizada sin señalarse con el dedo unos a otros. Ni una sola vez me encontré con este término de Tech Debt de personas a mi alrededor, o de los eventos a los que asistí, o de los blogs locales que leí.

Solo encontré este término cuando leí blogs y revistas de Silicon Valley en los Estados Unidos. Esto significa que la mayoría de los programadores y ejecutivos de software que trabajan en pequeñas y medianas empresas de desarrollo de software en la India ni siquiera habrían oído hablar de este término hasta ahora. Entonces, permítanme comenzar explicando el término en sí. La deuda técnica, o Code Debt, es un concepto en el desarrollo de software que refleja el costo implícito del retrabajo adicional causado por elegir una solución fácil (limitada) ahora en lugar de usar un mejor enfoque que llevaría más tiempo.

Permítanme desglosarlo para que sea simple. Es un concepto para calcular el costo de resolver problemas de programación y diseño que podrían haber aumentado al elegir una opción fácil de construir un módulo en particular, o un sistema completo en conjunto, en lugar de elegir el método mejor y más eficiente para construirlo. En el campo del desarrollo de software, este fenómeno de la pereza y la tardanza que regresa para morderte el trasero ocurre con mucha más frecuencia que en cualquier otro lugar. Es casi como si Karma tuviera una representación social de ser maliciosa por parte de los programadores.

Por favor, no me malinterpreten, no estoy culpando a los programadores de toda la deuda del código. Sin duda, hay múltiples entidades que son responsables de la deuda de código que surge con seguridad en más del 90% de los proyectos en pequeñas empresas de desarrollo de software en India. Permítanme tratar de cubrir algunos de ellos brevemente:

1. CLIENTES IMPACIENTES Y OVERSMART

Sí, empezaré por morder la misma mano que le da de comer y lo haré sin piedad. El mercado de proyectos de desarrollo de software subcontratados de pequeña envergadura es enorme y está muy fragmentado. Hay empresas genuinamente buenas que justifican perfectamente este mercado globalizado, mientras que otras son solo empresas parásitas que se alimentan de este arreglo perfectamente bueno solo porque no está regulado ni controlado.

Esto lleva a los clientes a cometer un error al elegir la empresa adecuada para asociarse en función de sus necesidades. Si bien no tener las habilidades adecuadas de investigación de antecedentes no es su culpa, no hay nadie a quien culpar por no tener la inteligencia callejera básica para identificar una compañía de basura de una genuina. Ahora, una vez que aceptan seguir adelante con un equipo con poco talento, ahogan sus expectativas poco realistas y su cronograma. No solo eso, algunos de ellos incluso se exceden y muestran lo inteligentes que son al traer sus propias sugerencias en diseño y programación. (#notodoslosclientes)

Si alguna vez es cliente de una empresa de desarrollo de software, le pido humildemente que los deje en paz y les permita hacer su trabajo. Intente ir a un médico o un abogado y dígales lo que buscó en Google y lo que dijo sobre su problema y vea la reacción en sus rostros. A ningún experto en sus campos le gusta que un novato le aconseje sobre su propio campo. Los ingenieros de software no son una excepción.

Si encuentra un buen equipo de desarrollo de software y parece prometedor, déles su espacio y no sentirán la necesidad de tomar atajos, lo que resultaría en una menor cantidad de deuda de código en su proyecto. Y adivinen qué, la mayoría de las veces, son ustedes, los clientes que pagan esa deuda de código. ¿Alguna vez has oído hablar de las palabras: "Solicitud de cambio"? ¡Apuesto a que la mayoría de ustedes lo ha hecho! En un escenario ideal, nunca deberías escuchar esas palabras en tu vida. Pero eso rara vez sucede. Y cuantas más veces escuchas esas palabras, más te equivocas al ser cliente de una empresa de software.

2. GERENTES PEREZOSOS Y TORVIOSOS

Cuando digo gerentes aquí, es cualquier persona en la posición de gestión de proyectos del lado de la empresa de desarrollo de software. Ya sea un gerente de proyecto, un líder de equipo, un jefe de entrega o el propietario de una empresa, si alguna vez trató de lavarse las manos rápidamente de un proyecto solo para terminarlo y cobrar su pago, usted es una parte. culpable también de esta deuda tecnológica acumulada en sus proyectos.

Aunque la parte más triste aquí es que ustedes nunca pagarán la deuda tecnológica. O es el cliente quien lo paga usando un producto de calidad inferior o pagando más dinero para que lo limpien. Y si no es el cliente, son los pobres programadores los que pagan por tener que trabajar horas interminables mucho más allá de lo que deben hacer. Pero casi nunca son estos intermediarios, por lo tanto, según yo, deberían ser las entidades más responsables en este tema de la deuda tecnológica.

Si alguna vez vas a contratar a uno de ellos, la mayor cualidad que deberían tener es la moralidad. Si su brújula moral apunta en la dirección correcta, asumirán la responsabilidad y tomarán la decisión correcta a favor del proyecto, lo que eventualmente conduciría a una menor acumulación de deuda tecnológica. Esto me recuerda esa famosa cita de Jack Ma donde habló sobre elegir trabajar para el líder correcto. Muy apto en este escenario aquí.

3. PROGRAMADORES

¡Oh, sí, no terminaría este tema culpándolos a ustedes también! Pero bueno, #no todos los programadores, ¿verdad? Bueno, sí, pero casi el 94% de los programadores. Al menos eso es lo que piensa CP Gurani, director ejecutivo de Tech Mahindra, cuando hizo la impactante revelación hace un par de años de que el 94 % de los graduados en TI no son aptos para el trabajo. No sé exactamente cómo llegó a ese número, pero siendo un producto de las facultades de ingeniería de la India y habiendo sido testigo de todo el ecosistema de ingeniería de TI durante los últimos 10 años, puedo decir que tiendo a estar de acuerdo con lo que dijo el Sr. Gurani.

No estoy tratando de debatir si es 94%, 90% u 80%. Pero para ponerte una analogía, es como que casi todos sabemos que necesitamos harina, agua y una pizca de sal para hacer la masa, y un rodillo para hacer los chapatis. Pero muy pocos de nosotros podemos hacer chapatis comestibles. Es un proceso absolutamente simple, pero aún requiere un poco de talento y mucha práctica para sobresalir en él. Lo mismo ocurre con la programación. Todos conocemos la receta, pero muy pocos se han arremangado, se han ensuciado las manos y la han practicado tanto tiempo como fue necesario para dominar ese oficio.

Por lo tanto, incluso cuando un programador promedio recibe el encargo de un proyecto, sin saberlo, escribiría un código con una deuda tecnológica incrustada en él, de la que no se daría cuenta hasta más tarde. Y si se pregunta cómo está funcionando la industria de manera positiva en general con la mayoría de los programadores no aptos para el trabajo, es debido a sus gerentes eficientes y sus experimentados seniors que han aprendido las cosas de la manera más difícil. Ayudan a esas manos y mentes frescas a navegar por los caminos traicioneros de escribir un código óptimo y hacen factible el envío del proyecto y lo mantienen libre de una deuda onerosa. Y eventualmente, con la preparación adecuada y la capacitación de esos novatos para que se vuelvan buenos en su trabajo, o terminarán despidiéndose de la industria de TI.

Entonces, en conclusión, siento que las 3 partes principales en esta colaboración comparten la culpa por compilar la deuda del código. Una vez más, no tome este artículo como un artículo para derribar todo lo que está mal en la industria. Es como cualquier otra industria en el mundo con una buena cantidad de horrores y héroes. Incluso después de 10 años de hacer esto, todavía no haría nada más con mi vida. Me encanta este trabajo, me encanta ser una pequeña empresa que trabaja en proyectos emocionantes de clientes de todo el mundo.

El propósito era hacer que las 3 partes interesadas fueran más responsables y familiarizarlas con esta pérdida blanda subyacente que les estaba afectando a través de una mala colaboración. Si un equipo de desarrollo de software desea calcular y medir con precisión su deuda tecnológica, puede seguir un modelo de proceso estricto basado en la metodología Agile o incluso en la metodología Waterfall. Cuando siga ese enfoque disciplinado, podrá marcar esos sprints de revisión y reparación por separado y, al final de una fase, podrá calcular con precisión cuántos de ellos necesita y llegar fácilmente al final. razón para ello.

Terminaré esto con esta cita final de Samuel Beckett: