Este es un ejemplo clásico de un conflicto entre las partes interesadas que creen que todo se trata de la administración y los desarrolladores que realmente crean el valor.
Refactorizar el código no debe hacerse del lado del desarrollo de características, en caso de que haya “tiempo terminado”. Debería ser PARTE del proceso de desarrollo. En realidad, diría que es más importante que cualquier característica. Digo esto porque agregar una característica se vuelve cada vez más difícil si la base del código es un desastre. Si no refactoriza y ordena el código regularmente, se deteriorará lentamente hasta convertirse en un antipatrón llamado “gran bola de lodo”. Cuando esto sucede, entonces el negocio está ABIERTO, no habrá dinero para las partes interesadas porque el código debe reescribirse desde cero. Los desarrolladores deben comunicar esto a las partes interesadas.
Otro argumento para esto es la competencia. Hay competidores por ahí, que permiten refactorizar, enviar al personal a cursos y conferencias, capacitar a los desarrolladores, etc., que creen (correctamente) que este es el camino correcto. Sus programadores son más felices y el código funciona como un reloj. Intenta competir con eso cuando tengas una gran bola de barro. No puedes, porque estás fuera.
- ¿Por qué todos están en contra de PHP?
- ¿Cuándo puede un desarrollador usar CMS?
- ¿Los diferentes lenguajes de programación atraen a diferentes tipos de personalidad?
- ¿Cuál es la mejor forma / lenguaje para hacer un front-end dinámico?
- ¿Qué es mejor, Java servlets o Spring, para desarrollar un buen sitio web?
Para explicar esto a las partes interesadas, debe hablar su idioma y convencerlos de que hay un valor económico real y que no hay un valor económico (o muy reducido) sin él.
