Todos los programadores se quejan de que no les dejan hacer un trabajo decente y de calidad ¿Qué razón de mercado existe para esto?

A los partidarios de Ruby on Rails les gusta decir que Java es como COBOL (por aquello de que lo usan los bancos). Y quienes usan un lenguaje compilado tienden a menospreciar a los “programadores de scripting”, esos que escriben código guarro sin objetos ni declaración de variables ni nada. ¿Qué hay realmente detrás de todas estas enconadas discusiones?

Ángel me ha pedido que escriba sobre un e-mail en la lista privada del Grupo Tibi acerca de Meta4. Contar los entresijos de las empresas es, en general, indiscreto. Pero ya han pasado casi nueve años desde que dejé voluntariamente Meta4, de modo que supongo que las cosas han cambiado mucho allí desde entonces, y también que puedo contar lo que yo creo que pasó, desde la prespectiva que da el tiempo y sin perjudicar a nadie. Yo trabajaba en el departamento de I+D, tenía un jefe güay, y un jefe de mi jefe güay, hasta que un día las cosas empezaron a cambiar…

Hoy estuve en el chat con un amigo a quien llamaré el Capitán del Proyecto para preservar su anonimato. El Capitán me contaba lo que estaba pasando en su proyecto, que no es nada nuevo, ni nada sorprendente. Pero no por ello menos impactante.

En esto de Scrum y las metodologías de gestión de proyectos en general existen dos corrientes de pensamiento principales. Una es la encabezada por Jeff Sutherland, co-creador de Scrum y gurú de las metodologías Ágiles: según él, para que Scrum funcione hay que ceñirse estrictamente a las reglas, y todo lo que no pase el checklist completo no puede llamarse Scrum (y de hecho debería estar perseguido por la iglesia y garantizarte una buena temporada en los fuegos del infierno).

Otra la forman los que piensan que no hay una policía del Scrum que vaya a venir a detenerte si decides formar equipos de 14 personas cuando la norma es de entre cuatro y diez personas por equipo, o que rodeen el edificio con sirenas y megáfonos si llegáis a la conclusión de que los Sprints de duración fija no son para vosotros.

Cada cierto tiempo se oyen voces críticas sobre la falta de rigor con la que trabajan la mayoría de los programadores. La falta de métodos formales de verificación y benchmarking produce muchos programas lentos y nada fiables. Pero ¿es la programación sólo una extensión de las matemáticas por otros medios?

A los que trabajamos en informática aplicada nunca nos darán el Premio Alan Turing por resolver algún enigma conceptual muy complicado. No obstante, nos enfrentamos a diario a problemas prácticos que nos hacen la vida muy incómoda.
Este artículo es una reflexión sobre algunos de mis problemas cotidianos, y una invitación a comentar posibles tácticas para solucionarlos.

El bien conocido y verificado Principio de Peter establece que por encima de cualquier empleado siempre hay un jefe incompetente. Ahora bien ¿qué podemos hacer para que sea más llevadera la relación con esta persona que está en el puesto equivocado?

¿Existe una barrera infranqueable entre los programadores y el común de los mortales? ¿Qué factores contribuyen a que no nos entiendan?

Las compras de software tienen un problema de percepción en el orden de magnitud de la cifra a pagar. Los compradores esperan pagar 3.000 o 30.000 donde debería costarles realmente 30.000 ó 300.000.