You are currently browsing the category archive for the ‘Humor y desperación’ category.

Cada página debería tener una declaración de privacidad – aunque sólo sea para declarar que el usuario realmente no tienee privacidad. Esta declaración a continuación puedes usar como ejemplo para una página tuya albergada en algún proveedor de tipo aspiradora de datos. Seguramente no prometes demasiado (poco) aquí.

Sus datos privados son importantes. Por eso intento obtener un máximo de ellos en esta página. Como no tengo ni conocimientos técnicos ni derechos de acceso suficientes a la base de datos de esta aplicación web para poder espiar su uso de navegador, subcontraté el tratamiento de sus datos al proveedor de estas páginas.

El proveedor, sus representaciones nacionales y sus partners, llamados simplemente “proveedor” a continuación, usan la declaración de privacidad que puede encontrar en cualquiera de sus páginas. En corto dice que el proveedor puede – o no – tratar sus datos para saber más sobre usted y poder ofrecerle la mejor publicidad y “servicios”. Como el proveedor no tiene capacidad de hacer todo esto solo, puede pasar o no – sus datos a empresas subcontratadas en su país u otro lado que, a su vez, pueden pasar o no – sus datos a empresas subsubcontratadas que posiblemente no están localizadas en su país, su continente o su planeta. Por supuesto, para los partners de su proveedor valen las misma reglas estrictas como para el proveedor.

Además, el proveedor está obligado a dar acceso a sus datos a las “autoridades” si alguna ley en algún país le obliga. Sobre esto no hay más explicaciones en la declaración de privacidad de su proveedor, porque, en EEUU y otros países, está prohibido por ley de admitir la colaboración con las “autoridades”. Las “autoridades” de EEUU y de otros países tienen un derecho general de copiar todos sus datos y pasarlos a base de alguna ley real o deseada a “autoridades” o “instituciones” en otros países amigos o no tan amigos. Estos países se han obligados a proteger sus datos con la misma diligencia. En otros países más allá no es necesario advertir de las posibilidades de las posibilidades de espionaje, porque el servicio secreto está omnipresente y sus poblaciones acostumbrada a que toda la comunicación por Internet o teléfono será supervisada por “su seguridad” por los señores en el poder.

Para que el proveedor pueda mostrarle la publicidad que más eficazmente le hace comprar, usted debería usar este y los demás servicios del proveedor al máximo – en particular la búsqueda por Internet para que el proveedor sepa que le mueve y la aplicación de red social para saber lo que le ha movido. Por conveniencia no necesita introducir todos los datos en todas las aplicaciones de nuevo. Gracias a una cookie con su identificación de usuario, que cordialmente se ha ofrecido a su ordenador, el proveedor puede conectar todos sus datos introducidos en cualquier aplicación. Usted sabe que hizo todo bien, cuando encuentra en diversas páginas web publicidad para los medicamentos contra la enfermedad sexual que recientemente ha buscado en la máquina de búsqueda del proveedor.

Está invitado a hacer click en todos los botones de “compartir” que suelen aparecer al final de la página para distribuir sus datos igualmente a todas las empresas y prevenir así un monopolio de datos potencialmente malo para la economía. Por supuesto, sus amigos en las demás redes sociales también están curiosos que usted divulga en Internet. En el caso de sus amigos, usted podría incluso llegar a tener la sensación que es usted quien controla el acceso a sus datos.

Si usted no está conforme con distribuir sus intereses de esta forma, entonces usted debería volver a escribir cartas en papel o comprar los periódicos en un quiosco en lugar de perder su tiempo en Internet.

Lectura adicional

Supongo que sabes programar, pero te falta crear alguna historia interesante para un juego de rol. Aquí te explico como crearte una.

Los juegos de rol suelen tener un guión complicado. Debes ir a ver un sabio que te dice que hay otro sabio que sabe donde hay una cueva donde se esconde un artefacto que debes traer al rey para rescatar a su hija. Cuando estás en la cueva delante el artefacto, un enano te lo roba delante tus ojos que al final te obliga hacer una excursión al imperio de los enanos. El enano ladrón te dejaría el artefacto en cambio de otro que algún sabio más sabe donde. Cuando al final consigues traer el primer artefacto al rey, la hija ya se ha ido con algún vampiro romántico patético aunque se sospecha no de todo voluntario. (O al menos es lo que el rey quisiera sospechar.)

A primera vista parece que hace falta un guionista coreano para inventar un guión así de complicado, pero realmente basta cualquier funcionario con el papeleo correspondiente subyacente. Por ejemplo, una historia de complejidad similar es la siguiente:

Debes ir a la recepción de oficina que te envía a otra oficina que sabe donde está el departamento donde puedes conseguir el formulario con que puedes obtener el permiso de conducir. Cuando estás en el departamento ese, un funcionario no te concede el formulario por un detalle que al final te obliga ir al ministerio de minería. Ahí te darán un certificado que confirma que este detalle está en regla en cambio de otro formulario sobre que algún recepcionista más sabe donde puedes conseguirlo. Cuando al final consigues el formulario para obtener el permiso de conducir, la oficina correspondiente está cerrada por jubilación del funcionario en cargo.

Es fácil convertir la primera historia y en la segunda y vice versa. Sólo hace falta establecer correspondencias entre fomularios y artefactos, entre funcionarios y enanos y hijas de rey y el permiso que quieres conseguir. Para el primer nivel de tu juego de rol déjate inspirar para registrarte como autónomo en hacienda y la seguridad social. Jugadores más avanzados serán más atraído por contraer un matrimonio internacional o conseguir un pasaporte cuando están registrados como fallecidos.

Conviene también emparejar las características del jugador: A los puntos de fuerza en el juego de rol corresponde la paciencia en la oficina. La mágica se convierte en la capacidad de memorizar conceptos judiciales y, por favor, en lugar de luchar con la espada de fuego contra los habitantes malvados en la cueva aprovecha tu amistad con un abogado o el primo del ministro para hacerte respecto entre los oficiales. ¡No quiero incitar a acciones ilegales!

Lo curioso es que el juego de rol entretiene mientras el papeleo no. Igual será porque relaja más ser atacado por un vampiro rabioso que enfrentarse a un funcionario.

No olvides poner en los créditos que los caracteres que aparecen en el juego sólo tienen una semejanza con personas vivas por coincidencia – a menos que planificas una versión realmente dura de tu juego: una que no reemplaza los funcionarios y oficinas por vampiros y cuevas. Así tus jugadores tendrán un juego que asusta por su realismo y tú tendrás alguna denuncia que te daría publicidad para la primera parte de juego – y un guión para la segunda.

Así, ¡muchas suerte con tu juego de rol con muchos papeles de rollo!

Lectura adicional

Más formas para conseguir un buen guión para tu juego
Cómo hacer cosas más inteligentes

Hay muchos artículos sobre lo que unos consideran programar bien, y por eso han inventado muchos conceptos para conseguirlo: encapsulación, modularización, convenciones de nombres, orientación a objetos, comentarios de documentación y muchos más. Así de bonita la teoría.

En la vida real nos encontramos con líneas de código que no caben en una pantalla (y a veces ni en cinco), con funciones de mil líneas, con nombres de variables de una letra y, desde luego, todo sin comentarios. No es que los autores de tanta monstruosidad dirían que programaran bien – lo que hacen es “no perder tiempo con cosas innecesarias”.

Lo curioso es que programadores así muchas veces tienen éxito. Su criterio no es un buen diseño sino “que funcione”. Muchas veces llegan a hacer los programas funcionar antes que los informáticos afectados por conceptos académicos los suyos. Y el primero vende. Puede ser que el programador ordenado triunfa en un concurso de la NASA. En el mercado libre triunfa quien sabe vender. El primero vende su programa y los errores que quedan ya se arreglarán en la segunda versión – a saber cuándo y por cuánto – pero el consumidor ya tendrá la paciencia si una vez está acostumbrado a un producto.

Ahora me pregunto: ¿por qué gente con tanto éxito no escribe libros sobre cómo lo han tenido? Tenemos libros sobre cómo programar bien y otros cómo hacerte rico, pero ninguno sobre cómo hacerte rico programando. ¿Por qué no hay ningún artículo que te cuenta que el secreto no está en programación orientada a objetos sino en la programación orientada a objetivos?

“Orientado a objetivos” es una forma fina de “lo importante es que funcione”. Y no es una idea esotérica: hay bastantes ofertas de trabajo que lo piden – sobre todo para puestos de jefe. Si es así de deseado, ¿entonces por qué no se enseña la programación orientada a objetivos en la universidad? ¿Por qué nadie nos revela el secreto?

Tengo varias teorías:

  • Los profesores no tienen la preocupación de “a ver si gano lo suficiente al fin de mes” y por eso no se sienten lo suficientemente expertos para explicar la programación orientada a objetivos.
  • Hay una conspiración de programadores orientados a objetivos que mantiene secreto el saber de hacerte rico programando.
  • Un programador orientado a objetivos no es realmente un genio sino alguien que dispone de un algún colega ordenado con genio que le arregla los fallos en el código. La razón porque los programadores orientados a objetivos se hacen jefes es más bien porque el puesto de jefe es el único en el departamento de informática en que no hay que escribir código.
  • Personas que trabajan orientadas a objetivos se orientan a objetivos que han establecido otros. Mientras no hay nadie que les da el objetivo de escribir un artículo sobre “por qué es mejor no perder tiempo con buen diseño”, no lo van a hacer.

Pero me queda la esperanza que este artículo inspire a algún veterano de compartir su sabiduría. Cuando reconozco no haber llegado a entender como uno se puede sentir cómodo arreglando a una función con mil líneas, me atrevo a adivinar el verdadero fin de la programación orientado a objetivos: ¡psicología! No programas para un ordenador sino aprovechas las emociones del usuario final!

  • El fin de un programa no es un buen producto sino una buena venta.
  • Los consumidores no compran algo nuevo porque es bueno sino porque es novedoso. Aquellos que siguen la moda tecnológica más de cerca se interesan por lo que su nuevo capricho podría hacer. Para saber si realmente lo puede hacer no tendrán el tiempo suficiente hasta la próxima versión.
  • Las insuficiencias de un programa permiten ofrecer (y vender) una nueva versión del programa que a su vez puede contener nuevos errores.
  • Sacar nuevas versiones frecuentemente da más impresión de mejora continua que un producto que ya funciona bien desde el principio. Cuando más versiones en menos tiempo, menos posibilidades tienen los usuarios a descubrir los errores de una versión en concreto.
  • Siendo el primero en sacar un nuevo producto te convierte automáticamente en “experto” para el dominio. Te asignarán empleados que te ayudan a mantener el código que tú pronto dejarás de entender. Esto permite elogiar a tus colegas como los verdaderos expertos de tu código.
  • Algún empleado igual de listo como tú sabe que una larga lista de errores fijados encantará al director. Y por lo tanto asegurará que siempre habrá una lista larga. Así se cualifica para liderar pronto un equipo.

En todo caso es una estimación y reconozco mi insuficiencia en la materia. Antes de conocer a un experto del tema no me quedará otra que seguir programando como alguien a que castigan a volver a leer y entender su propio código una y otra vez.

Lectura adicional

Para los programadores orientados a objetivos
Para los demás

Entre la interfaz de usuario y la base de datos se encuentra la “inteligencia” del programa: es el código que calcula a base de las entradas del usuario y los datos en la base de datos los nuevos datos y la salida a presentar en alguna pantalla. No me gusta usar la palabra “inteligencia” para esta parte, porque pueden surgir conversaciones pocos amigables entre los programadores involucrados.

– No funciona la inteligencia. ¿Has tocado la inteligencia?
– ¿Yo? ¡Noooo!

– ¿Tú entiendes algo de la inteligencia?
– No. Estoy con otra cosa.

– ¿La inteligencia está lista para entregársela al cliente?
– Todavía no. En dos semanas a lo mejor.

– Tú, que no has tocado nada de la inteligencia todavía, ¿qué te parece?
– Um, no sé, parece demasiado difícil.

– La inteligencia es lo peor que he visto en mi vida laboral. ¿A tí también toca trabajar con ella?
– Yo ya no trabajo con la inteligencia desde hace meses.
– ¡Qué suerte!

La duda que surge es, qué palabra podría sustituir a la “inteligencia”. Al menos el sinónimo “lógica” que se usa a veces no es una mejora: Lo que he hecho no tiene nada que ver con la lógica. ¡Seguro!

Pues, parece que nos toca seguir trabajando con la “inteligencia”.

Lectura adicional

A veces no sabes si algunos mensajes te deben hacer llorar o sonreír. Algunos avisos en la informática se encuentran en esta categoría. Aquí un ejemplo de un mensaje de error de Rational Application Developper para Websphere que lo dice todo.

Diálogo con mensajes de error
Si todavía queda alguna duda, entonces se puede desplegar los detalles para más información.

Diálogo con detalle de error
Si todavía no queda claro, entonces considera las penurias que a veces tiene tu ordenador con lo que tú le dices a él.

Más entretenimiento

Ya hace tiempo que el lenguaje de programación Java ha destronado a C++ como el lenguaje más popular. No extraña que recién titulados carecen de conocimientos profundos sobre C++ y están mal vistos por veteranos que carecen de conocimientos en Java.

Érase una vez que estos veteranos eran los recién titulados y se enfrentaron con problemas similares aunque con lenguajes de programación distintos. Antes del paradigma de orientado a objetos se disfrutó de un lenguaje bien estructurado – donde lo nuevo era el bien: El artículo Real Programmers Don’t Use Pascal fue escrito cuando Java se llamaba Pascal y C++ Fortran. No te dejes escapar el enlace a la historia de Mel dentro de este artículo para los tiempos pre-informáticos cuando el lenguaje Fortran era el Java y el C++ de entonces no tenía ni nombre.

Aunque C++ ya no es el lenguaje más popular, su ráiz, el lenguaje C, está todavía presente en el fondo de todas las plataformas. Un artículo clásico sobre como una broma se hizo seria es Creators Admit Unix, C Hoax.

Aunque a primera vista puede parecer algo para teorías académicas, se comprueba que los lenguajes esotéricos de programación son algo para gente creativa con el tiempo suficiente para escribir programas en Brainfuck, dibujarlas (!) en Piet o hacerlos comprensibles para orang utans en Ouk. También en la forma de desarrollar un tema clásico, los programadores no necesitan quedarse fuera en los premios Nobel de la literatura, aunque sea para decir algo tan simple como hola mundo.

Y finalmente una explicación, porque ya no podemos seleccionar la zona temporal en Microsoft Windows con un mapa del mundo. Pues, es posible que esto incluso ha evitado conflictos fronterizos armados.

Honestamente, el título confunde: Este artículo comenta mucho los comentarios.

Programadores están obligados a hacer su código funcionar. Una restricción que les quita mucha creatividad. Sólo una minoría privilegiada, que escribe comentarios en el código, tiene la posibilidad de expresarse con libertad.

Por qué comentarios

Miles de programadores (bueno, quizá más bien unos veinte) no tienen mayor preocupación que su aparición como coautor en este artículo. Por este motivo evitan el uso de comentarios en su código. Mientas tanto disfrutan el resultado simple y exacto de cada función, que devuelve 3 cuando el parámetro var1 es “OK” y var2 guarda 15. Tres significa que la máquina va a arrancar, el robot gira a la izquierda, el programa va a terminar o el contrario de esto – o todo a la vez o una combinación arbitraria de esto. Depende del contexto, el cual puedes encontrar 150 líneas más arriba o en otro fichero del programa. Mala suerte, si la función está mal y debería devolver 4, que es algo diferente que 3 o lo mismo. Depende del contexto. Hay muchas maneras de escribir código inmantenible.

No te entiendo

Usando comentarios trae la cuestión de lo que es un buen comentario. En general, yo consideraría un bueno comentario alto que explica la semántica y no la sintaxis. Alguien que sabe programar no necesita un comentario como

// Incrementa x en uno
x = x + 1

Sin embargo, es un comentario obligatorio cuando sería el único en una función de 1500 líneas.

Explicar la semántica puede ser difícil a veces. A continuación sigue una lista con ejemplos de la vida real, que muestran lo que no es probablemente un buen comentario.

bool ProcesaTeclaUsuario(void)
// de momento es global por problemas con los punteros

En este programa no hubo ninguna función no-global. Pero, por supuesto, puede haber una razón de no ser global diferente para cada función.

num_mens_control++;  //TODO tiene sentido???

¿Tiene sentido lo que haces ahí? Mientras funciona, todo tiene sentido. En este contexto me es grato presentar la definición

Un científico sabe por qué no funciona. Un ingeniero no sabe, por qué funciona.

Mientras cambias código y no estás seguro si el cambio fue bueno, puedes dejar las líneas originales comentadas y marcar la modificación con una palabra especial. Si tienes mucho que cambiar, entonces un poco de variación puede resultar más gratificante. Estos ejemplos son de un fichero con unos 2000 líneas:

//TODO
//XXX TODO
//WORKAROUND
//WORKAROUND TO DO IT BETTER
//XXX BAUSTELLE
//XXX BAU 28.06

Baustelle es alemán para “obras”. El aviso “constantemente en obras” en una página web es igualmente significativo. Quién esperaría que una página web cambiase.

!! rules necesarias para el correcto funcionamiento:
rule void Nr_Set_Visible_Displayed(object Ob_Strip input)

A diferenciar de las rules no necesarias y las rules para el funcionamiento incorrecto.

!!  start of Md_GbMDW_FPL needed rules

¿Escribes código que no es needed?

!! END OF RULE EXPERIMENTAL

Vale. Lo haces.

Cuando la comunicación falla, todavía te queda decir a otros lo que deben hacer por código fuente.

!! Note: move this(Ob_GbManCoord) to strip model.
export variable object Ob_GbManCoord;

Por supuesto, lo podrías hacer tú mismo, pero ¿por qué?

!! New model for waypoints line
model MdGb Md_Gb_Waypoints

O este comentario es actualizado frecuentemente o este modelo será nuevo para siempre.

!! Study assigment of colours
if Ob_Fp_Strip.In_Flag_Un_Flag_Field then

A veces, un ordenador toma un respiro se pregunta: ¿En qué color debería pintarlo?

!! Rule to solve the STR-1207: Panning in Playback mode

Resuelto. Una vez y por todas. Ni piensas en que este código podría ser útil para otro propósito.

//declarar el objeto, es importante inicializarlo a NULL
TStringList *Valores = NULL;
Valores = new TStringList; //crear instancia del objeto

Esto es un comentario importante. De otra forma el lector podría llegar a pensar que no vale la pena asignar NULL a un puntero que será sobrescrito inmediatamente después.

Como comentar mejor

En general podrías tener en cuenta las siguientes ideas para escribir un código.

  • Como un programador ya sabe el lenguaje de programación, no necesitas explicárselo de nuevo. Una excepción sería si usaste el lenguaje de una forma rara y sorprendente como, por ejemplo, sobrecargar el operador + sin la connotación de “más”. No obstante, en este caso deberías considerar cambiar el código y no el comentario.
  • No repitas código en tus comentarios. “Añadir cinco a x” no aporta ninguna información nueva a “x + 5”. Céntrate en el significado de x, por ejemplo “añade 5 metros a la posición x.
  • No olvides que identificadores (variables, tipos y nombres de funciones) ya deberían contener su semántica en si mismos. Un comentario puede todavía ser necesario para explicar el contexto en que una operación tiene lugar, por ejemplo un comentario a send_to_printer(document) podría ser “Aquí el documento debe estar en un formato adecuado para la impresora”.
  • ¿Tiene importancia cuando el código o el comentario fue escrito y cuantas veces fue cambiado? Ten esto en cuenta antes de escribir una fecha en el código. “Nuevo” y “viejo” dan una idea de que algo fue cambiado, pero no cuando. No obstante, no tengas miedo en que comentarios podrían caducar en el próximo cambio de código. Todavía pueden dar una pista importante y un programador sabe que lo que hace un programa funcionar es el código y no el comentario.
  • No olvides limpiar el código. Muchos de los ejemplos anteriores se “olvidaron”. Eran marcadores durante el desarrollo que perdían su sentido cuando el trabajo concluyó.
  • Si tus ficheros usan una cabecera, sólo escribe cosas ahí para que habrá suficiente disciplina para actualizarlas. Un fichero guarda una fecha de última modificación, el último “autor” es probablemente uno de tu grupo de trabajo, y la versión del fichero fuente inútil. Un fichero ejecutable tiene un número de versión y todos los ficheros fuente para crearlo tienen este mismo número de versión automáticamente. A menos si vendes ficheros fuentes y no programas que funcionan.
  • No es mala idea de usar comentarios para separar código visualmente en secciones (con barras o incluso con títulos). Es sabio usar el mismo estilo para el mismo tipo de sección.

Referencias

¿Qué es la diferencia entre un científico y un ingeniero?

Un científico sabe, porque no funciona. Un ingeniero no sabe, porque funciona.

¿Cómo se sabe si una ecuación forma parte de la matemática, la física o la ingeniería?

Matemática es hallar una ecuación sin más razón. Si se encuentra alguna
utilidad para ella, se llama física. Si encima la utilidad es algo que gente quisiera usar, se llama ingenería.

El matemático demuestra que una ecuación es válida para todos los elementos pensables. El físico se limita a calcular que la aproximación de la ecuación dé un error menor que la tolerancia de medida para todos los elementos reales en el vacío. El ingeniero se limita medir que un objeto útil no requiere una ecuación más complicada que a = b·c. El informático asume además que b y c sean valores enteros menores de 32000.

Saber idiomas es esencial para poder moverse en el mundo laboral. Aquí viene un pequeño listado con “frases celebres” y su sentido.

Expresiones en el mundo laboral
Expresión Significado
Lo importante es que funcione.
  1. No te quiero ver haciendo cosas que no se ven inmediatamente en la pantalla.
  2. Lo importante es que el cliente pague aunque sea por engaño.
Debemos hacer calidad. Lo importante es que funcione.
Programación orientado a objetos. No sé lo que es programación orientado a objetos, pero debemos hacer calidad.
Lo más importante es la estabilidad. Pon la nueva funcionalidad pero sin errores. Mañana hay entrega.
Cuando el cliente nos lo pide, hacemos la documentación. No pierdas tiempo apuntándote cosas. Un buen empleado lo tiene en la cabeza.
Cuando tenemos tiempo… Nunca.
A estas alturas del proyecto Dos semanas después del comienzo
Tenemos una fecha de entrega
  1. Nosotros quiere decir: yo pongo la fecha y tú la entrega.
  2. Es posible que el cliente no comprará el ordenador necesario hasta dos días antes.
¿Qué podemos hacer para dar un empujón al proyecto? ¿Podrías hacer horas extras?
Esto es un trabajo en equipo. Nuestro código es como un piso de estudiantes: la limpieza impone el más guarro.

En cada proyecto existe un flujo de trabajo, en se recurren de forma secuencial varias etapas.

  1. Se genera una idea general de que debe hacer el proyecto. Por ejemplo un programa que controla los movimientos de trenes en una estación.
  2. Los ingenieros de sistema elaboran con los clientes un cuaderno de carga y traducen los requisitos a un diseño. Por ejemplo:  El programa tiene una ventana en que se puede editar el horario del tren. Tiene un botón “Aceptar” que copia los datos en la ventana en la base de datos.
  3. Los programadores escriben un código que hace esto.
  4. Los ingenieros de prueba comparan el comportamiento del programa con los requisitos en el cuaderno de carga

¿Esto no suene totalmente lógico? Pensar qué quieres, cómo lo quieres, hacerlo y comprobar si lo has hecho bien. Lógicamente es un ideal que en una empresa de alta tecnología no se puede conseguir siempre. Por lo tanto, el ciclo de desarrollo suele tener típicamente más bien el siguiente estilo.

  1. El director general de los tuyos y de los suyos firman un contrato, donde aparece por primera vez una fecha de entrega.
  2. Los ingenieros de sistema comienzan a ingeniarse un sistema y avanzan a buen ritmo.
  3. El jefe de los ingenieros de sistema se da cuenta que el buen ritmo haría duplicar el tiempo previsto para esta fase y pide que se diseñen los componentes en dos en lugar de cuatro semanas.
  4. Como los ingenieros de sistema no llegan, los programadores empiezan a programar aunque todavía no está de todo claro qué.
  5. Los programadores avanzan a buen ritmo.
  6. A la medida que los ingenieros de sistema completan el diseño del programa, los programadores deben modificar el código.
  7. Los ingenieros de prueba comienzan a probar el programa que a veces falla porque las partes en cuestión aún no están programadas.
  8. Entre fijar los errores reportados por los ingeniero de prueba y modificar el diseño del programa hay tímidos intentos de adaptar el programa para hacerlo más legible, orientado a objetos, modular y tal. Por alguna coincidencia hay de repente dos días enteros para esto porque el programa ya contiene todo para la primera entrega parcial al cliente.
  9. El cliente está contento porque ve que están todas las ventanas aunque los botones no funcionan. Los ingenieros de sistema sugieren un cambio propuesto por los programadores de reducir el número de
    los botones “Aceptar” a uno por ventana.
  10. Los programadores lo cambian.
  11. Mientras añaden componentes adicionales a la funcionalidad, el cliente se muestra preocupado por el elevado número de errores detectados por los ingenieros de prueba. El jefe del programa promete reducirlo.
  12. Como el tiempo entre arreglar errores y programar nuevas partes con más errores se hace corto, el jefe del grupo prefiere aumentar la rapidez. Lo que se podría dividir en dos ficheros también cabe en uno, además a estas alturas del proyecto ya no conviene agrupar los ficheros en directorios por tener una mejor modularidad.
  13. El cliente se da cuenta que no se puede configurar la aplicación. Pide editores para que los parámetros fijos sean variables inicializadas con un fichero de texto.
  14. Los programadores empiezan a reescribir su código para que todos los arrays sean de un tamaño variable.
  15. El jefe del programa se muestra preocupado, porque que fallan partes del código que funcionaban antes.
  16. Los ingenieros de sistema adaptan su documentación de diseño a lo que realmente hay programado.
  17. El programa se cuelga tres veces en una prueba con el cliente. Esto tiene máxima prioridad y justifica que al final, sí, se dividen los ficheros en varios directorios.
  18. Aún falta un 20% de la funcionalidad. La lista de errores ha crecido porque todos los programadores estaban ocupados por los fallos fatales de la semana pasada. Al mismo tiempo, se ponen por lo menos tres errores por anomalía reportada para que el número de errores parezca más pequeño.
  19. Un programador detecta que la ventana de configuración debe tener opciones que son técnicamente imposibles de realizar. Después que el programador descubra como se podría hacer algo similar, el ingeniero de sistema propone que el programador le diga como lo haya programado para que pueda adaptar el documento de diseño.
  20. El programa se cuelga sin más razón aparente cuatro días antes de la prueba final. Las revisiones de los programadores durante el fin de semana fallan por la documentación incompleta de bibliotecas externas. El cliente no acepta el programa a pruebas.
  21. Tras haber codificado toda la funcionalidad, el cliente quiere que todos los mensajes de textos sean leídos desde un fichero. Realmente ya lo quería desde el principio, pero como esto no añade funcionalidad, nunca se hizo.
  22. Tres programadores se quedan con los errores no resolubles. Uno de ellos tiene también la tarea de inventarse los comentarios para que parezca que al menos un 30% de líneas sean comentarios.
  23. Supuestamente, el cliente usará el proyecto y no se puede excluir que también será documentado.

¿Qué conclusiones podemos sacar? Pues, la primera es ciertamente que hagas un repaso a tus ideales juveniles pero sin deprimirte. Aunque parece imposible de cambiar el mundo entero, sí, es posible que al menos tú hagas lo mejor posible.

Por ejemplo, el cambio que podrías enfocar desde ahora es dejar de quejarte de que la imprevisión e la improvisación son la regla (a pesar de lo que diga tu jefe), sino que se planifica en tiempo real. Suene muy bien y es una pieza para obtener la actitud adecuada para que algún día tú serás el jefe.

Te deseo mucha suerte.

Escribe tu dirección de correo electrónico para suscribirte a este blog, y recibir notificaciones de nuevos mensajes por correo.

Únete a otros 46 seguidores

Archivos

mayo 2017
L M X J V S D
« Ene    
1234567
891011121314
15161718192021
22232425262728
293031