...alan perlis
44. "menos del 10% del codigo tienen que ver directamente con el proposito del sistema; el resto tiene que ver con la entrada y salida, validacion de datos, mantenimiento de estructuras de datos y otras labores domesticas"
-- mary shaw
45. "si tienes una funcion o procedimiento con diez parametros, probablemente hayas olvidado uno"
-- alan perlis
46. "es raro que mantener el codigo de otro desarrollador sea como entrar en un edificio de gran diseno que admiras mientras paseas por el y planeas como anadirle un ala o algun elemento decorativo. lo mas frecuente es que sea como tirarse de cabeza a un gran monton de basura maloliente"
-- bill venners
47. "la generacion de codigo, como beber alcohol, es bueno si se hace con moderacion"
-- alex lowe
desarrollo
48. "la simplicidad llevada al extremo se convierte en elegancia"
-- jon franklin
49. "un programa nunca esta completo por debajo del 90% ni por encima del 95%"
-- terry baker
50. "cuando estas en un atasco de trafico con un porsche, todo lo que puedes hacer es consumir mas combustible que el resto estando parado. la escalabilidad va de construir carreteras mas anchas, no coches mas rapidos"
-- steve swartz
51. "todo el mundo sabe el peligro de la optimizacion prematura. pienso que deberíamos estar igualmente preocupados con el diseno prematuro, es decir, el hecho de disenar demasiado pronto lo que un programa debería hacer"
-- paul graham
52. "programar sin una arquitectura o diseno en mente es como explorar una gruta solo con una linterna: no sabes donde estas, donde has estado ni hacia donde vas"
-- danny thorpe
53. "la mejor forma de predecir el futuro es implementarlo"
-- david heinemeier hansson
54. "lo realmente necesario es saberlo todo sobre los cambios en la informacion. nadie quiere o necesita que le recuerden 16 horas al día que tiene sus zapatos puestos"
-- david hubel
55. "en dos ocasiones me han preguntado: 'si pone datos incorrectos en la maquina, ¿saldran las respuestas correctas?'. soy absolutamente incapaz de hacerme una idea del tipo de confusion de ideas que pueden provocar que alguien haga una pregunta así"
-- charles babbage
56. "hazlo todo tan simple como sea posible, pero no mas simple"
-- albert einstein
57. "hoy en día la mayoría del software existe no para resolver un problema, sino para actuar de interfaz con otro software"
-- i. o. angell
58. "unas buenas especificaciones incrementara la productividad del programador mucho mas de lo que puede hacerlo cualquier herramienta o tecnica"
-- milt bryce
59. "la diferencia entre la teoría y la practica es que, en teoría, no hay diferencia entre la teoría y la practica"
-- richard moore, desarrollador de kde
errores y depuracion
60. "no documentes el problema; arreglalo"
-- atli bjorgvin oddsson
61. "por norma, los sistemas software no funcionan bien hasta que han sido utilizados y han fallado repetidamente en entornos reales"
-- dave parnas
62. "si el codigo y los comentarios no coinciden, posiblemente ambos sean erroneos"
-- norm schryer
63. "creo que es una nueva característica. no le cuentes a nadie que fue un accidente"
-- larry wall
64. "si no las capturas y procesas, cerramos tu aplicacion. esto incrementa enormemente la fiabilidad de tu sistema"
-- anders hejlsberg, sobre las excepciones en .net
65. "cuando se esta depurando, el programador novato introduce codigo correctivo; el experto elimina el codigo defectuoso"
-- richard pattis
66. "en un proyecto software con diez personas, probablemente tres de ellas introducen tantos errores que podríamos considerar su productividad como negativa"
-- gordon schulmeyer
67. "es inevitable que la gente programe mal, y la formacion no mejorara sustancialmente las cosas. tenemos que aprender a vivir con ello"
-- alan perlis
68. "el testing de componentes puede ser muy efectivo para mostrar la presencia de errores, pero absolutamente inadecuado para demostrar su ausencia"
-- edsger dijkstra
lenguajes y tecnologías
69. "la gestion manual de bloques de memoria en c es como hacer malabarismos con pastillas de jabon en la ducha de la prision: todo diversion hasta que cometes un fallo"
-- un usuario anonimo de un foro usenet
70. "no pueden existir concursos de perl ofuscado; no tendría sentido"
-- jeff polk (nota: ¡sí que los hay!)
71. "java es lo mas penoso que le ha ocurrido a la informatica desde ms-dos"
-- alan kay
72. "solo hay dos cosas malas en c++: el concepto inicial y la implementacion"
-- bertrand meyer
73. "era una broma, ¿vale? si hubieramos pensado que iba a usarse no la habríamos escrito"
-- mark andreesen, hablando de la etiqueta blink de html
74. "los servicios web son como el sexo entre los adolescentes. todos hablan de hacerlo, pero aquellos que realmente lo hacen, lo hacen muy mal"
-- michelle bustamante
75. "perl: el unico lenguaje cuyo codigo es practicamente igual antes y despues de someterlo a una encriptacion rsa"
-- keith bostic
76. "no trabaje duro para hacer ruby perfecto para todo el mundo, porque todos somos diferentes. intente hacer ruby perfecto para mí, así que puede que a tí no te lo parezca; probablemente, el mejor lenguaje para guido van rossum es python"
-- yukihiro matsumoto, aka "matz", creador de ruby
77. "xml no es mas lenguaje de programacion que unas notas sobre una servilleta de papel"
-- charles simonyi
78. "basic es a la programacion lo que qwerty a la mecanografía"
-- seymour papert
79. "se ha descubierto que c++ dispone de una gran facilidad para ocultar los detalles triviales de un programa... así como donde estan sus bugs"
-- david keppel
80. "unix es simple. solo necesita un genio para entender su simplicidad"
-- dennis ritchie
81. "algunos desarrolladores cuando se enfrentan a un problema piensan que la solucion es usar expresiones regulares. en este momento, ya tienen dos problemas"
-- jamie zawinski
seguridad
82. "pienso que los virus informaticos muestran la naturaleza humana: la unica forma de vida que hemos creado hasta el momento es puramente destructiva"
-- stephen hawking
83. "el unico sistema seguro es aquel que esta apagado en el interior de un bloque de hormigon protegido en una habitacion sellada rodeada por guardias armados"
-- gene spafford
84. "saber romper medidas de seguridad no hacen que seas hacker, al igual que saber hacer un puente en un coche no te convierte en un ingeniero de automocion"
-- eric raymond
85. "las organizaciones gastan millones de dolares en firewalls y dispositivos de seguridad, pero tiran el dinero porque ninguna de estas medidas cubre el eslabon mas debil de la ca...
Añadir a Del.Icio.Us
