Have you ever heard of SEMA? It’s a fairly esoteric system for measuring how good a software team is. No, wait! Don’t follow that link! It will take you about six years just to understand that stuff. So I’ve come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. With all the time you save, you can go to medical school. ...
Fue a Bjarne Stroustrup a quién le leí que “un sistema grande y complejo que no ha evolucionado a partir de otro más simple que funcionaba bien, no funciona y, además, es imposible arreglarlo para que funcione” (creo que esto es del libro The Design and Evolution of C++ publicado en 1994). Tal hipótesis se comprobó empíricamente muchas veces en el siglo XX y es por eso que se cambió el foco a proyectos ágiles. ...
Ever wondered why programmers are known as nightbirds? Why we stay up all night? Because it allows us to get into the zone, it allows us to focus on one thing and not have to worry about being interupted by someone - because they are all asleep. It’s a long stretch of the day where no one is up and no one is calling or trying to talk to us. It’s a great time to program, and think. ...
What would ”nice looking”—or ”beautiful”, for that matter—actually mean when referring to source code? I asked some programmer friends what they thought that meant. Their answers were obvious, but still worth stating: Code should be locally coherent and single-functioned: One function should do exactly one thing. It should be clear about what it’s doing. Local code should explain, or at least hint at the overall system design. Code should be self-documenting. Comments should be avoided whenever possible. Comments duplicate work when both writing and reading code. If you need to comment something to make it understandable it should probably be rewritten. » Shawn McGrath | kotaku.com
En mi opinión el origen de todos los males que afectan a la profesión del desarrollo de software (no me meto en otras cosas), o mejor dicho del programador (evito eufemismos tipo ”arquitecto”, ”ingeniero software”, ”desarrollador” o similares) es el desprecio a programar, el desprecio de la labor del programador frente a otros tipos de tareas. » Jose María Arranz | saveinformaticos.reeelab.com
;`El camino a un mejor programador;’ es un libro que recopila artículos sobre ingeniería informática escritos por Esteban Manchado Velázquez, Joaquín Caraballo Moreno y Yeray Darias Camacho. La mayoría de los artículos tratan sobre pruebas automáticas de una manera u otra, pero el tema común es mejorar como profesional de la informática. » emanchado.github.com
As a result of a long sequence of coincidences I entered the programming profession officially on the first spring morning of 1952 and as far as I have been able to trace, I was the first Dutchman to do so in my country. In retrospect the most amazing thing was the slowness with which, at least in my part of the world, the programming profession emerged, a slowness which is now hard to believe. But I am grateful for two vivid recollections from that period that establish that slowness beyond any doubt. After having programmed for some three years, I had a discussion with A. van Wijngaarden, who was then my boss at the Mathematical Centre in Amsterdam, a discussion for which I shall remain grateful to him as long as I live. The point was that I was supposed to study theoretical physics at the University of Leiden simultaneously, and as I found the two activities harder and harder to combine, I had to make up my mind, either to stop programming and become a real, respectable theoretical physicist, or to carry my study of physics to a formal completion only, with a minimum of effort, and to become….., yes what? A programmer? But was that a respectable profession? For after all, what was programming? Where was the sound body of knowledge that could support it as an intellectually respectable discipline? I remember quite vividly how I envied my hardware colleagues, who, when asked about their professional competence, could at least point out that they knew everything about vacuum tubes, amplifiers and the rest, whereas I felt that, when faced with that question, I would stand empty-handed. Full of misgivings I knocked on van Wijngaarden’s office door, asking him whether I could ”speak to him for a moment”; when I left his office a number of hours later, I was another person. For after having listened to my problems patiently, he agreed that up till that moment there was not much of a programming discipline, but then he went on to explain quietly that automatic computers were here to stay, that we were just at the beginning and could not I be one of the persons called to make programming a respectable discipline in the years to come? This was a turning point in my life and I completed my study of physics formally as quickly as I could. One moral of the above story is, of course, that we must be very careful when we give advice to younger people; sometimes they follow it! ...
Tu jefe lo quiere para ayer, pero más vale que cumpla con los standards de mañana. Los clientes quieren todas las características que se puedan imaginar, pero no te atrevas a confundirlos dándoles todos los botones que desee. Tus compañeros programadores quieren que documentes tu código, pero ellos simplemente responden ”tl;dr” (Too Long; didn’t read) a cualquier cosa que escribes. Así como la tecnología evoluciona, también lo hacen los dilemas que enfrentan los desarrolladores. Cada elección, desde la plataforma hasta el almacenamiento de datos, incluyendo a cuánto control darle a los usuarios, está cargada de preguntas. Y gracias a la nube, el crecimiento de la tecnología móvil y la acelerada vanguardia, pareciera como si el mundo de la programación enfrentara una nueva elección – y dilema – a un ritmo creciente. ...
¿Qué desarrollador de software nunca ha estado una semana programando a toda velocidad, casi sin saber que hace, ya que la fecha de entrega está cerca y todo tiene que estar terminado ”para ayer”? ¿Quién no se ha encontrado en la situación de saber que está programando una chapuza, pensando que otro día lo mejorará, y ese día nunca llega? ¿Quién alguna vez, al ver una porción de código fuente no ha exclamado indignado: ¡qué narices hace este código! o ¡quién leches lo ha programado!? A todo este código lo solemos calificar como chapuzas, apaños, ñapas, mierdecillas¦ Su problema es que, por lo general, se va extendiendo de forma exponencial y acumulándose a lo largo del desarrollo de un proyecto. Y en consecuencia tenemos como resultado un código fuente que es muy difícil de mantener, extender y reutilizar; y un aplicativo que funcionalmente tiene problemas. ...