Archivo

Archivo para diciembre, 2007

Regina ExLibris sobre literatura infantil

martes, 11 de diciembre de 2007
Comentarios desactivados en Regina ExLibris sobre literatura infantil

A la caza de niños-lectores – Blogs 20minutos: Regina ExLibris

Buenos consejos para estas fiestas. Sé que son buenos porque ¡me los he leído todos! (en mi ya lejana infancia)…

ocio

Modelos en arcilla

martes, 11 de diciembre de 2007
Comentarios desactivados en Modelos en arcilla

Me ha gustado mucho la comparativa que ha hecho Doods entre la industria del automóvil y la producción de software. Producir software no es como esas líneas de dedicados robots y humanos especializados, en las que es fácil determinar cuántos coches (idénticos, bien definidos…) salen por hora de la factoría. En realidad, es más parecido al tipo que se encarga de hacer el modelo en arcilla:

«Have you seen a car ad that shows a design studio with a clay mock-up? That’s like software development. The guy on the factory floor can easily know how long it takes to assemble an automobile. It’s much more difficult for the guy sculpting clay to predict how much work and how many revisions it will take to get to the final design».

Esto confirma la idea acerca de la auténtica esencia del software: la información y el conocimiento. De hecho:

«Software development is an exploration. It’s learning about the problem domain, the customer’s needs, and how a solution can be realized with the available resources. Learning requires space and time for experimentation and failure«.

¡Es algo fundamental! ¡Nadie aprende por acertar! Si ahora aciertas, es porque antes has fallado de muchas maneras distintas. ¿Por qué no aprendemos a fallar? Creo que tiene que ver con que nos han educado para esperar un castigo si hacemos algo «mal»… No hay que castigar si uno se equivoca… Hay que castigar cuando uno se equivoca reiteradamente. Y ni siquiera en esos casos. Defiendo en esos casos una buena herramienta: enseñar.
Y ya para terminar, categórica, la auténtica definición de «manufactura del software»:

«Software manufacturing, at its least adorned, is a file copy operation».

Ahí queda eso [las negritas son mías].

diseño, profesión

Declaración de variables al principio de un método

lunes, 10 de diciembre de 2007
Comentarios desactivados en Declaración de variables al principio de un método
Cada vez estoy más a favor de declarar las variables justo antes de que sea utilizadas. Un argumento a favor de ello, entre otros, es que no provocas que el lector del código se pregunte “¿para qué se usan estas variables?” antes de tiempo… Si declaras las variables justo antes de que sean usadas, la respuesta viene casi inmediatamente…

Por contra, favoreces el diseño CopyPaste, que es pecado.

profesión

Sencillez (aparente)

jueves, 6 de diciembre de 2007
Comentarios desactivados en Sencillez (aparente)

No sé dónde lei que cuanto más sencilla es una aplicación para el usuario, más complicado es para los desarrolladores construirla. Y también es cierto que cuando un stakeholder te presenta sus necesidades, el primer modelo mental que se construye es francamente sencillo (o sea, poco detallado).

Cuando por fin vas pasando de un análisis del problema al diseño de una solución, el número de detalles aumenta naturalmente. Este tipo de detalles tiene muchas veces que ver directamente con el problema y siempre con los requisitos del usuario, tanto funcionales como no funcionales. Así, lo que antes era sólo introducir información se transforma en un conjunto de decisiones relativas a la validez de esos datos, a su tipo, a la estructura entre ellos, a qué hacer cuando los datos son parcialmente incorrectos. Sin decir nada sobre los mecanismos de seguridad, que determinan quién puede introducir qué datos y cuando. ¿Habrá un proceso de introducción por una clase de usuarios y otro de validación por parte de otra clase distinta? ¿Se querrá registrar quién introdujo la información? ¿Sólo la última modificación, o un histórico de ellas?

Para los que diseñamos y construimos sistemas de gestión, un síntoma de este Big Bang que transforma un problema primordial en un universo de soluciones galácticas (y el energético proceso que pasa de una a otra) aparece cuando tenemos que agregar «un campo más». Un campo más, es revisar desde la base de datos hasta todas las capas de presentación (incluyo informes), qué partes se ven afectadas… Sí, es cierto, es la más fácil de las modificaciones… 🙂 Imagínate cualquiera otra…

Por cierto, me niego a traducir «stakeholder» por tenedor de apuestas. Creo que la traducción más cercana podría ser «implicado en» o «interesado por» un proyecto. ¿Alguien tiene alguna otra sugerencia?

diseño

Anhelar el vasto e interminable mar

miércoles, 5 de diciembre de 2007
Comentarios desactivados en Anhelar el vasto e interminable mar

En uno de los posts el blog de Reginald he leído una frase preciosa de Saint-Exupery, sobre «liderazgo».

«If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea». —Antoine de Saint-Exupery (1900–1944), “The Wisdom of the Sands

¡Cuán lejos estamos de esto!

profesión

Un ingrediente esencial de la Felicidad

miércoles, 5 de diciembre de 2007
Comentarios desactivados en Un ingrediente esencial de la Felicidad

«El animal humano, como otros animales, está adaptado a una determinada lucha por la vida, y cuando con grandes riquezas el homo sapiens puede satisfacer todos sus caprichos sin esfuerzo, la nueva ausencia de esfuerzo hace que en su vida se [elimine] un ingrediente esencial de felicidad. El hombre que adquiere fácilmente cosas por las que siente no más que un deseo moderado, deduce que el logro del deseo no proporciona la felicidad. Si tiene aficiones filosóficas, deduce que la vida humana es esencialmente miserable, puesto que el hombre que consigue todo lo que quiere sigue siendo desgraciado. Olvida que la falta de algunas de las cosas que desea es un elemento indispensable de felicidad«

Bertrand Russell, en «La Conquista de la Felicidad», página 44, 1930. Editorial Espasa Calpe, S. A.

Las negritas son mías. He sustituido la palabra «remueve» por «elimine», que me parece un término más adecuado. Imagino que la palabra en el original en inglés sería «remove», que significa eliminar.

Por lo demás, estoy totalmente de acuerdo con el texto.

mens sana

Mort, Elvis, Einstein, y tú

lunes, 3 de diciembre de 2007
Comentarios desactivados en Mort, Elvis, Einstein, y tú

Jeff Atwood sobre una manera de aplicar la ley de Pareto a los programadores, contestando a otro post anterior que ha provocado un montón de respuestas.

profesión

"La" manera de hacer las cosas versus "una" manera de hacer las cosas

lunes, 3 de diciembre de 2007
Comentarios desactivados en "La" manera de hacer las cosas versus "una" manera de hacer las cosas

Lo reconozco, estoy muy negativo. Esta entrada es negativa.

Acabo de leer en el blog de James Fallows una entrada (via raganwald), y comparan la forma en la que unos japoneses repostan un avión, con la forma en la que lo hacen unos chinos. Como bien dice, no es un estudio científico, pero a pesar de ello concluye que:

With usual caveats against sweeping generalization, what this made me think was: Japan is all about the way of doing things. Practice, ritual, perfectionism, as much fanatical attention to the process as to the result. China is all about finding a way to do things. Improvisation, little interest in rules, putting up with whatever is necessary to attain the result.

[El subrayado es mio, las negritas suyas]. Opino que la conclusión puede extenderse también a la idiosincrasia nacional: nos preocupa mucho lo que vayamos a conseguir, pero no tanto cómo lo conseguimos. En el mundillo informático en el que me muevo, el paradigma de «una» manera de hacer las cosas es «pero funciona», mientras que «la» manera de hacer las cosas ni siquiera se piensa, mucho menos se documenta ni se practica.

No lo veo ilógico. En el ámbito laboral, no prima tanto cómo haces las cosas (la manera en la que haces las cosas), sino qué resultados has conseguido en última instancia. Y en particular, tanto mejor si lo consigues en el menor tiempo posible, aunque eso suponga saltarse pasos «innecesarios» que luegon afectan directamente a la calidad de los resultados, o al (invisible) trabajo que hay que rehacer más adelante debido a la baja calidad de lo producido.

Tom deMarco y Tim Lister ya nos lo adelantaron en su libro Peopleware el año 1999. En su capítulo 4 (Quality, if time permits) nos sugieren que hagamos un experimento. Preguntad por ahí a 100 personas que os digan un país asociado a la alta calidad, y es muy probable que el país sea Japón. Y luego preguntad también por ahí qué país está asociado con una alta productividad. Y es muy posible que el país también sea Japón. ¿Alta calidad y alta productividad a la vez?

A ver si la influencia oriental del Japón se nota más allá de la creciente conversión de la gente al budismo.

diseño

Malicia e incompetencia

lunes, 3 de diciembre de 2007
Comentarios desactivados en Malicia e incompetencia

raganwald recoge una cita en una entrada de su blog que me ha encantado: ¡la ley de Gray!

Any sufficiently advanced incompetence is indistinguishable from malice.

¡Genial!

mens sana