Recursividad, punteros, estadísticas y pseudociencia del software
En ACM Queue hacen una entrevista a Joel Spolsky, una persona a la que le tengo entre mis lecturas obligatorias por su experiencia, sensatez y sentido común… a pesar de ser informático (y ex-programador de Microsoft, y dueño de una empresa que desarrolla y comercializa software privativo 
).
Unas palabras que suscribiría y que van muy en línea con uno de los enésimos debates en los que me meto sobre la “profesión informática”, pero prometo porque puedo que es pura casualidad:
[Cuando contrato programadores….] Miro muchas cosas. Por ejemplo, no me importa si nunca has usado punteros o si nunca has usado recursividad o si nunca las has necesitado conocer. Pero me dí cuenta que hay una correlación entre ser bueno en esas dos temas con ser bueno en todas las demás, o en problemas más sustanciales.
Mi teoría para explicarlo es que para entenderlas y trabajar bien con ellas debes saber pensar un problema a diferentes niveles de abstracción simultáneamente. Esa es una aptitud que la mayoría de la gente no la tiene, y si careces de dicha aptitud no serás un buen programador.
Está bien aprenderlas, un buen ejercicio para una parte de tu cerebro. También podría darse el caso que sean cosas que se pueden enseñar a la gente que no tenga la habilidad, si desean esforzarse en ello.
Le preguntan sobre los libros que lee.
Ahora mismo no hay demasiados libros sobre el estado del arte en desarrollo y gestión de proyectos de software… Desafortunadamente no hemos superado la fase de anécdotas, y cualquier intento se superar las anécdotas son sólo anécdotas con estadísticas.
Parte del problema es que por detrás no hay una ciencia real, lo que es muy frustrante.
Pero lo mejor, o no, está cuando le hacen la siguiente pregunta:
P: Pero hay mucha matemática que da soporte a esas estadísticas, ¿o lo llamamos pseudociencia?
A lo que responde:
Exacto, pseudociencia…
Por otro lado, y relacionado, Jordi Murgo me envía por email Piensa antes de escribir código. También lo suscribo, de hecho ya comenté que yo pierdo días dando vueltas a un problema antes de empezar a programarlo.
Pero todo esto me hace acordar a una anécdota que leí tiempo atrás en ACM Communications, era algo así (perdón si no la recuerdo mejor):
Afirman que la competencia fundamental de un ingeniero de software es la de dirigir proyectos, y que por lo tanto gestión de proyectos debería ser una parte fundamental de la currícula. La mayoría de las ingenierías estudian gestión de proyectos. ¿Son ellos también ingenieros de software?
Yo le comentaria lo de la pseudociència a Albert Ll., le va a encantar X’-DDD
Comment by guillem — Wednesday 29/8/2007 @ 21:36
Ah, era sobre gestión de proyectos, no sobre el software en sí. No he dicho nada O:-)
Comment by guillem — Wednesday 29/8/2007 @ 21:36
El problema con el que me encuentro a menudo últimamente (aclaro que soy programador amateur, ya que me quedé en 2º de carrera, y ahora intento dar el paso al intrusismo profesional
) es que olvido (y olvidamos, por lo que veo por internet) que debajo de la programación hay una máquina. Me sorprendió el artículo de Ricardo de cómo consiguieron optimizar Bulma, simplemente separando la tabla de cabeceras de comentario y sus cuerpos, porque reducían así el acceso a disco. Y me sorprendió porque son cosas que conozco, que aprendí muy ben en la carrera, y que sin embargo no tengo (tenemos) en cuenta a la hora de programar. Supongo que a esto se refiere Spolski con los de los punteros.
Otra cosa que cada día aprendo una y otra vez, es que a programar se empieza con lápiz y papel, y habiendo pensado todo un par de días antes.
¿Donde está el límite entre profesión y ciencia en esto de la informática?
Comment by proclamo — Wednesday 29/8/2007 @ 22:27
Un comentario sobre el artículo de “Piensa antes de escribir código”. En el dominio en que el autor trabaja (criptografía) es muy importante tenerlo todo muy claro, pero para otros proyectos de software no es tan cierto.
No digo que haya que lanzarse a picar código sin saber que es lo que quieres lograr y una idea de como quieres hacerlo, pero el pretender “hacerlo bien” a la primera, es pecar de ingenuos. Pasado un cierto punto, cualquier reflexión sobre como debe funcionar un software, se vuelve puramente especulativo: Para avanzar hay que ver el producto funcionando. No queda otra que “ensuciarse las manos” y escribir una primera versión o un prototipo.
Creo que, como al escribir, la manera más fácil y eficiente, es hacer borradores e ir mejorándolos. (No creo que nadie hubiera podido escribir meneame - en su sestado actual - a la primera).
Comment by JuanPablo — Wednesday 29/8/2007 @ 22:32
#1, #2, Llamosí lo que enseña es “ciencias de la computación”, es de lo que sabe (un huevo) y le gusta (creo).
Comment by gallir — Wednesday 29/8/2007 @ 23:07
Me he quedado un poco frío con el post. No entiendo muy bien qué quieres transmitir.
Me gustó mucho el artículo de Spolsky sobre la contratación de programadores. El tema de los punteros y la recursividad es un clásico de los programadores de C. No puedes programar C como toca sin conocer estos aspectos. Hay otras muchas cosas “divertidas” que la mayoría de programadores no saben (sobre todo temas de concurrencia y relacionados).
Desde luego no tengo dudas sobre que la gestión de proyectos no es una ciencia. De hecho la mayoría de técnicas que usan, las sabe cualquiera que haya estudiado cualquier carrera con cierto componente de “management”. El prolema es que algunas métricas de complejidad son difíciles de interpretar para una persona que no sea una experta en la tecnología que tiene por debajo.
Mira que me gusa poco la comparativa pero, cualquier arquitecto/aparejador/jefe de obra tiene el mismo problema para saber cuándo terminarán sus albañiles la obra. La unica manera de ser preciso es conocer al equipo y tener datos reales de problemas anteriores de complejidad similar.
También me hizo gracia el tema de “piensa antes de programar”. Sí, claro que sí. por supuesto y siempre, pero… ¿Cuántas veces no has empezado un programa escribiendo algo que haga algo y luego has ido mejorándolo? Depende del día, del problema, del programa.
¿Sabes por qué eres bueno y te das tanta cuenta de los desastres de los demás? porque llevas muchos años en esto (con interés, con dedicación, me refiero) y hay cosas quasi instintivas que sólo se adquieren con los años.
Comment by Paco Ros — Wednesday 29/8/2007 @ 23:33
Je je
“The company has maintained a 100 percent employee retention”
Que crack.
Esa sería una buena métrica a aplicarse por las empresas.
Comment by miguel — Thursday 30/8/2007 @ 9:58
Mas acerca de recursión y punteros por Joel (este tipo me cae cada vez mejor)
http://local.joelonsoftware.com/mediawiki/index.php/Riesgos_de_las_Java-escuelas
Uff! Un poco más y me equivoco y lo pongo en otro tema … ese el de ‘ingeniería del software’ … perdón, perdón
Comment by miguel — Thursday 30/8/2007 @ 11:49
Más acerca recursión, punteros y otras hierbas raras por Joel. Je, Je este tipo me cae cada vez mejor.
Comment by miguel — Thursday 30/8/2007 @ 11:54