¿Es posible obtener un trabajo de programación Ruby, sin seguir los principios del desarrollo basado en pruebas (TDD)?

Creo que es un callejón sin salida profesional no hacer TDD, y las compañías que no hacen TDD con Ruby se están disparando en el pie. Ambas razones son dos caras de la misma moneda:

1. Sin pruebas, nadie más querrá voluntariamente tocar el código que está escribiendo. En efecto, usted (el autor) se convierte en el “experto” en este código. Vivirás en un silo bastante estrecho y el intercambio y el aprendizaje con otros equipos o incluso personas serán bastante limitados. Ese “experto experto” (usted) es ahora un punto único de falla para la compañía, y la compañía es vulnerable a eso. Si te atropella un autobús, entonces el proyecto o incluso la compañía pueden tener grandes problemas. Llamamos a esto un “factor de bus” de uno. Las empresas siempre deben luchar por un factor de autobús alto.
2. En el papel puede sonar bien ser “indispensable” de esa manera, pero en realidad es un callejón sin salida profesional, porque ahora está atrapado en mantener este código, y la compañía se resistirá a sus intentos de transferir, avanzar o cambiar sus obligaciones. También puede descubrir que debido a que nadie quiere trabajar con su código, que mantener el ritmo e innovar depende de usted, y la mayoría de las personas no pueden hacerlo de manera efectiva por sí mismas. Entonces, a la larga, terminarás manteniendo una pieza de tecnología obsoleta que impide tu habilidad para mantener tus habilidades actualizadas. Esto afectará severamente sus perspectivas de trabajo en otros lugares, en particular a medida que el cambio tecnológico se produce cada vez más rápido, y los nuevos empleadores potenciales exigen versatilidad en las últimas cosas antes de que incluso le permitan entrevistarlo.

No estoy inventando esto. He trabajado en una empresa (pre-Rails, aunque) que tenía exactamente este tipo de disfunción co-dependiente en todos sus departamentos de ingeniería. No hace falta decir que debido a que todos se sintieron tan obligados a proteger su territorio que la cooperación entre divisiones o incluso entre divisiones fue tediosa, no divertida y, en general, poco fructífera. La cultura de la compañía sufrió y los productos eran mucho más caros de producir y de peor calidad de la necesaria. La única razón por la que la compañía se mantuvo en el negocio fue su posición casi monopolista en su mercado y las relaciones OEM que había establecido.