Mini proyecto D3: Calendario laboral 2016

calendariojbr

Como parte de mi plan para tratar de hacer de 2016 un año mejor que los anteriores y basándome en la experiencia del año pasado he pensado que debería contar con un calendario completo, algo fácil de visualizar, fácil de tener a mano, con posibilidad de usarse a nivel de múltiples proyectos cortos y largos, que incluya información a nivel de mes y semana, etc.

Tras pensarlo, decidí que los calendarios tradicionales no eran adecuados, por lo que decidí buscar uno mejor. Al no encontrarlo, pero sabiendo que D3.js permite hacer uno a medida, decidí implementarlo basándome en algunos parecidos ya existentes. En realidad podría haberlo hecho en Excel, pero tengo otros planes en marcha que hacen deseable la opción de usar D3.js.

La forma en que estoy empezando a usar este calendario es en formato impreso para tener a mano y marcar hitos. De esta forma tengo facilidad para tenerlos a la vista, junto con días no laborables y otros eventos (jornada intensiva, etc.). También puedo llevar mejor control de a qué altura del año estamos dado el formato de fila con 7 columnas que tiene.

El usar la semana basada en lunes en la parte inferior facilita visualizar los fines de semana y los colores oscuros indican festivos, siendo los claros usados para marcar mi jornada intensiva o para resaltar los fines de semana.

En resumen creo que este calendario impreso puede resultar de ayuda para mantener a la vista el año completo y los diferentes hitos tanto a nivel de proyectos como de actividades recurrentes.

Para quien esté interesado en el código puede obtenerlo de mi repositorio de GitHub: Noradrex/D3Calendar

Para quien solo necesite una imagen que imprimir puede usar la que encabeza el artículo, aunque dada la personalización que tiene, recomendaría modificar los datos embebidos en el código y usar el calendario resultante. Es sencillo.

Por ultimo, si alguien tiene curiosidad por como lo estoy usando, este sería el aspecto de mi planificación en 4 categorías de todo el año, desenfocado para preservar cierta información. Haré más, pero es interesante lo mucho que me recuerda a una partitura.

WP_20160110_001

 

 

 

Anuncios

Libro: UX design for startups

uxdesign

Título: UX design for startups
Autor: Marcin Treder
Editorial: UXPin

Encontré este libro/PDF en alguna de las fuentes RSS que sigo habitualmente, pero me temo que no recuerdo en cual. Según mi OneNote, tengo pendiente esta reseña desde Marzo de este año por lo que creo que va siendo hora de ponerla online ahora que tengo unos minutos de Wifi en una biblioteca pública (a lo Remote).

Se trata de un libro de letra grande y cómoda de leer, por lo que a pesar de sus poco más de cien páginas se lee muy rápido. El contenido no es especialmente profundo obviamente, pero se trata de un buen resumen de lo que implica dedicarse a la UX y creo que puede suponer un buen punto de partida para quien quiera iniciarse en ella.

Dado que el libro se encuentra online, es gratuíto y esencialmente es un resumen de un universo de conocimiento en expansión, simplemente querría dejar constancia de su existencia y del objetivo que cubre. Muy recomendable.

Como curiosidad, la portada me recuerda mucho a la de Principios Universales de Diseño que comenté en 2008.

Por último, algunas citas que me gustaría recordar en el futuro:

[…] the Business Model Canvas (BMC).
This eight-field table can do what an extended business plan struggles to achieve: it can explain your business. It revolves around the Unique Value Proposition (a single, clear sentence describing the way you’re different from your competitors and why you’re worth buying) and the canvas depicts your idea, key partners and resources, and your model of revenue. This is the single most productive page you’ll ever come across in your business endeavours.

 

-o-

 

The term ‘mockup’ was used for years in regard to high fidelity, static, design representation. It’s a kind of draft (or even a final version!) of visual design used to get a buy-in from stakeholders.
Suddenly the term started to lose its meaning and become close to wireframes.

 

-o-

 

A prototype is often confused with both a wireframe and a mockup. In actual fact, though, it’s totally different. A prototype is a middle-to-high fidelity representation of the final product, which simulates user interface interaction. It’s interactive and dynamic.

 

-o-

 

If your prototype is static, it’s either a mockup or a wireframe. A prototype is not the final product though. It’s a simulation of the final interaction between the user and the interface. It might not look exactly like the final product, but should be vastly similar (it’s definitely not a greyish, sketchy thing).

 

-o-

 

In your own startup some things are unnaturally hard, because you care too much. Caring too much brings chaos on board. Chaos makes the simple complicated. Next

thing you know: you’re in trouble.

 

-o-

 

“A design isn’t finished until somebody is using it,” said Brenda Laurel, a great designer who used to work for Atari, among others, in the 80s. This is a condensed truth. Great designs don’t just look beautiful: they let people succeed in their endeavours.

 

 

Libro: Diseño y cultura, una introduducción.

Libro: Diseño y cultura, una introducción. Desde 1900 hasta la actualidad.

Editorial: GGDiseño

Autor: Penny Sparke

Debido a mi interés en el diseño de Metro (ahora Modern) que Microsoft aplica a sus productos (Windows, Windows Phone, Office, Xbox…), hace poco llegué al punto de querer saber más sobre su filosofía e historia, más de lo que cuenta la propia Microsoft. Y eso implicaba buscar algún libro sobre diseño industrial, diseño moderno, Bauhaus y 1930-1940. Dado que este libro trata precisamente de diseño en general desde 1900, parecía una apuesta segura. Pero me equivoqué.

A pesar de que el libro es en efecto una introducción histórica al diseño, me temo que trata de abarcar muchas cosas en pocas páginas y lo hace de una forma dispersa, hilando muchos datos inconexos, describiendo apenas lo que sostiene y con lo que me parecen pocos ejemplos prácticos o históricos relevantes. Tampoco me parece que haya una gran selección de imágenes o una estructura general coherente. Es como si el autor se hubiese puesto a divagar sobre diseño, sin mucho interés en hacerse entender y sin ánimo de comunicar o entretener. Tan es así que terminarlo me ha supuesto un incómodo esfuerzo.

Pero bueno, el lado positivo es que ahora tengo alguna noción adicional sobre historia del diseño, y he de decir que me recuerda, y mucho, al panorama del desarrollo de software. No en vano siempre digo que el desarrollo de software es diseño de software, y en mi rama profesional en particular hay un componente importantísimo en el aspecto de este. Así que aunque el libro no me haya servido para ahondar en el diseño de Microsoft (o ahora Google también con todo eso del flat design) sí que permite dar un vistazo a la evolución de una profesión similar a la de desarrollador: la de diseñador industrial. Al final vas relacionando a los artesanos del Art Noveau con los desarrolladores craftmanship, o el diseño industrial con las guías de diseño de las grandes factorías de software. Vas entendiendo como todo avanza poco a poco, sin sobresaltos y como todo el sistema realimenta unas partes con otras: tecnología, diseño, economía, moda… todo influye.

Recomendaría esta lectura a alguien MUY interesado en la historia del diseño, con mucho tiempo libre.

Citas de interés:

[Esto me trae a la mente los materiales de diseño de Nokia y Apple] El plástico se desarrolló como un sustituto de otras sustancias más caras, como el ámbar, el azabache y el jade, de los que había gran escasez. El aluminio, por su parte, no tuvo aplicación en el momento de su descubrimiento, y por lo tanto fue señalado como “una solución para un problema inexistente”. […] En la década de los treinta, sin embargo, ambos eran considerados por los diseñadores y los consumidores como los materiales modernos por excelencia […]. Roland Barthes escribía que “el plástico es la quintaesencia de la alquimia”.

-o-

El plástico era un material ideal para la producción en serie, y su evolución a lo largo del siglo XX estuvo estrechamente ligada a la idea del producto democratizado, hasta el punto de que, después de 1945, perdió su aura al ser considerado responsable de la aparición de objetos baratos y horteras fabricados en lugares como Hong Kong. Los plásticos tuvieron que ser rescatados y devueltos al ámbito seguro de la alta cultura por una serie de relevantes diseñadores italianos en las décadas de los cincuenta y sesenta.

-o-

[Hablando del streamline, los diseños con curvas bordes y esquinas] fue consecuencia de que en la fabricación de productos de plástico resultaba difícil extraer de los moldes las esquinas agudas. Además, las superficies sobresalientes servían para compensar la ilusión óptica de que la superficie de un producto de plástico se hundía hacia adentro.

-o-

[Algo que me recuerda a muchos desarrollos de software] En la fabricación de productos que dependían de las nuevas tecnologías para su existencia como para sus modos de fabricación, el diseño como práctica artística era menos patente en este periodo y se dejaba que fueran los ingenieros quienes determinaran la apariencia de este tipo de productos. En el caso del diseño primitivo de automóviles, por ejemplo, los ingenieros eran los responsables de la creación del chasis y de todos los elementos que debían funcionar en el producto. Todo ello había que combinarlo posteriormente con la carrocería, que era confeccionada a mano por constructores de carruajes tradicionales que, sencillamente, trasladaban sus técnicas al nuevo contexto.

-o-

En ocasiones, como ocurrió en los casos de William Morris en Inglaterra, Charles Rennie Mackintosh en Escocia, Henrry van de Velde en Bélgica, Frank Lloyd Wright en Estados Unidos y Eliel Saarinen en Finlandia, la extensión del papel del arquitecto hacia las artes decorativas y el diseño fue un resultado directo de su deseo de establecer sus hogares o los de sus familiares y de la imposibilidad de encontrar los objetos y el mobiliario adecuados para su propio entorno doméstico y personal. Para remediar este problema, empezaron a diseñar todo lo que necesitaban para sí mismos (desde tejidos a cuberterías) y a buscar la manera de fabricarlo.

-o-

De este modo, en los años 80 y la venta, los “vaqueros de diseño” (con los nombres de Vanderbilt, Armani, Versace, Calvin Klein o Donna Karan en su etiqueta) eran prendas hibridas: estandarizadas y producidas en serie, pero, al mismo tiempo, personalizadas y distinguibles de las del vulgo por estar asociadas a un diseñador concreto.

-o-

Sin embargo, la burbuja de la cultura del diseñador comenzó a estallar en la década de los 50, Cuando Vance Packard y otros empezaron a criticar a los diseñadores norteamericanos Por su papel en el proceso de obsolescencia del producto. No obstante, no fue sino hasta finales de los 60 cuando, junto a los sistemas políticos y económicos dominantes, los diseñadores empezaron a ser blanco de críticas en Europa.

-o-

Aunque la cultura del diseñador sirvió para crear una ilusión de individualismo creativo dentro del mercado de masas al ensalzar un nombre, había muchos otros diseñadores que trabajaban de manera anónima, fuera del star system. A lo largo de los años 80 y no venta, los diseñadores sintieron una creciente necesidad de trabajar en una serie de áreas comerciales nuevas, como el branding, la identidad corporativa, el software, los videojuegos, el diseño multimedia, el diseño web, la dirección de arte, el diseño de exposiciones y eventos y el marketing de estilos de vida, en las cuales se daba más importancia al trabajo en equipo y a la interdisciplinariedad que a la aportación individual.

-o-

Los defensores más optimistas del movimiento postmoderno afirmaban que no querían dejar de hacer juicios de Valor, sino más bien relajar las antiguas normas que eliminaban la posibilidad de valorar equitativamente distintos tipos de manifestaciones culturales, aunque fuera con criterios divergentes. Según sugerían, ya no se debería hablar más del “buen diseño”, sino de uno y “diseño apropiado”.

En ningún lugar tenía más importancia a este debate que en las discusiones relativas a la delicada cuestión del “justo”. Durante mucho tiempo, la división estricta entre lo que se consideraba “buen gusto” en oposición al “mal gusto” (o kitsch) el sirvió para mantener las diferencias de clase y de género dentro de las sociedades occidentales. La idea de que todos los gustos pudieran considerarse igualmente válidos, aunque diferentes, había sido un anatema para los teóricos de la escuela de Frankfurt.

-o-

Otro ejemplo de colaboración entre gobierno e industria para renovar la imagen de una población, en este caso una ciudad que una región distintiva, más que un estado guión nación, fue el de Barcelona en los años 80 en la venta. Tras la caída del régimen franquista, España inició un programa de modernización similar al emprendido por Italia casi tres décadas antes. Sin embargo, mientras que Italia había modernizado su identidad en el contexto del movimiento moderno tardío, Barcelona experimentó un proceso similar dentro de un contexto posmoderno global, posindustrial y orientado al consumo. Cataluña pretendía diferencias al del resto de España apoyándose en el antiguo prestigio de su diseño progresista y en la situación de Barcelona como centro de producción. De forma más significativa, supo entender la importancia del consumo y de satisfacer a una clase media acomodada que se había visto privada de la experiencia de “consumir modernidad” bajo el régimen franquista. La regeneración económica y cultural de Barcelona fue un proceso complejo que supuso colaboraciones públicas y privadas e innovaciones en el diseño de los productos, los entornos de venta y los espacios públicos. Fue un ejercicio concienzudo, que se benefició considerablemente de la decisión de celebrar en la ciudad los juegos olímpicos de 1992; lo que proporcionó la palanca para conseguir una renovación completa de la ciudad. Lo más importante, sin embargo, a la hora de lograr este cambio fundamental fue el impresionante ejercicio de re-branding

Dibujos animados e interfaces de usuario

Gracias a mi hija presto, desde hace algún tiempo, más atención a los dibujos animados que de costumbre. Esto unido a mi interés por el diseño de interfaces de usuario, y el debate entre el skeumorfismo, diseño Metro (o plano, minimalista, limpio), las metáforas y lo digital, ha hecho que me fije que parece haber cierta relación entre el diseño de interfaces y los dibujos animados. Probablemente se trate de algo débil de una cierta moda en diseño, pero ahí está.

Dibujos animados 3D, imitación a la realidad

Resulta que ahora mismo veo algunos dibujos animados que son esencialmente dibujos 3D, con sus degradados, brillos, perspectiva y líneas curvas. Todo bien renderizado para que las texturas y las sombras den una atractiva imagen de “realidad de juguete”.

Dentro de esta categoría de dibujos “realistas” en 3D puedo recordar los siguientes:

Dibujos animados 2D, la importancia del contenido

Pero también veo que hay dibujos en 2D de muy alta calidad, dibujos de colores planos, líneas rectas o curvas “limpias” y perspectivas inexistentes, que digamos eliminan adornos que parecían indispensables para hacer un dibujo de calidad (degradados, 3D…) y tratan de ser lo más simples posibles, pero con argumentos y diálogos muy trabajados, como poniendo el peso en el contenido (la historia y los personajes).

En esta categoría encontramos a:

Por supuesto, hay otras categorías más extrañas e intermedias y bastante extravagantes además, como El asombroso mundo de
Gumball
 u Hora de Aventuras. Pero me ceñiré a las que relaciono con interfaces digitales, es decir las 2D y las 3D.

Skeuomorphismo de Apple VS Metro de Microsoft

Resulta que en el dominio de los interfaces de usuario, tenemos algo similar. Por un lado, desde Windows XP y Mac Os, o desde la Web 2.0, hemos ido metiendo más y más “chrome” que dicen, es decir más adornos, más marcos, o más barroquismo según algunos. Esto es: adornos visuales, como los degradados en los colores, brillos, aspecto 3D, bordes redondeados… que no aportan poco al usuario, siendo tratados como meros artificios visuales.

Y frente a esta corriente de imitación barata de la realidad (textura de piel en una pantalla digital, por ejemplo), han empezado a ponerse de moda los interfaces tipo Metro, o Windows 8, que a pesar de lo que pueda parecer, no están presentes solo en los productos de Microsoft, sino en la mayoría de los de Google (aunque lo hayan ido metiendo más sigilosamente y con menos publicidad negativa).

¿Modas?

Así que por resumir, parece haber una clara división entre barroquismo y minimalismo, tanto en interfaces digitales como en dibujos animados. En ambos casos parece haber una división entre el aspecto barroco, cargado de elementos tipo Apple (skeumorfismo), en contraste con los que minimizan a lo más esencial y potencian la calidad de la historia o el contenido, aprovechando tanto como sea posible las posibilidades de las pantallas digitales al modo claramente Metro (colores planos y brillantes, líneas rectas, tipografías).

Donde antes teníamos Windows XP o iOS, ahora tenemos Modern UI o Android 4.x. Y donde antes teníamos El tiovivo mágico en 3D a todo detalle, hemos evolucionado a la Pepa Pig De colores y perspectiva plana.

Curioso.

Libro: Piano. La historia de un Steinway de gran cola

Titulo: Piano. La historia de un Steinway de gran cola.
Autor: James Barrow 
Editorial: Alba 

Qué pasada de libro.
Imagino que no todo el mundo lo verá así, pero para mi, leer esta obra está al nivel de catarsis tras años de clases de piano practicamente olvidadas (más por imposibilidad de practicar que por desgana). Ha supuesto volver a escuchar las obras de Beethoven, Bach, Tchaikovsky o Rachmaninov con un interés adicional y un conocimiento orgánico del instrumento en si y de su historia (sin ser más que aficionado, ojo). Y ha supuesto volver a avivar con mi interés de la niñez por dos fabricantes de instrumentos: Steinway y Stradivari.
Puede que a quien no haya estudiado piano, o a quien no le interesan la fabricación (diseño, avances técnicos…) de instrumentos (no solo los musicales) no le parezca una obra tan buena, pero desde luego, es una buena obra. De ello se encarga James Barrow (perfectamente traducido), que transpira calidad al narrar el relato, ejerciendo como dios manda el oficio de periodista.
Retrospectivamente, es posible que leer este tipo de obras (aun tengo pendiente la reseña del de violín) me hubiesen animado más y mejor en el aprendizaje de un instrumento, pero esa historia ya es agua pasada, y a día de hoy su lectura me anima a educar en lo musical y en lo científico/técnico a mi hija. Así que si eres un nuevo estudiante de música (no exclusivamente de piano), un viejo aficionado, un fan de la música clásica, un fabricante de herramientas (desarrolladores de software incluidos), o incluso un aspirante a empresario, deberías leer este libro.
El siglo de historia que narra, nos acerca, no solo a la fabricación de un instrumento de precisión moderno, sino a la historia de una empresa, la de los cambios tecnológicos y económicos acaecidos, y la relación del hombre, del especialista, con sus herramientas.
Como hay más y mejores críticas en lugares como Amazon http://www.amazon.com/Piano-Making-Steinway-Concert-Grand/dp/0805078789, lo dejaré aquí, solo para recomendarlo encarecidamente y para poner las habituales citas interesantes.

La RCA comercializaba la marca de radios más vendida en la nación y Sarnoff comprendió lo que podían ofrecer: entretenimiento con solo girar un botón… No hacían falta ni clases ni talento y las radios eran más baratas que los pianos, que los Steinway en particular. [Tras haber sobrevivido al fonógrafo y al tocadiscos…] en 1933 dos terceras partes de los hogares estadounidenses tenían receptor de radio.

-o-

Incluso los clientes que querían comprar un piano de cola no querían modelos grandes. Las casa adosadas iban desapareciendo en Nueva York y, en su lugar, surgían edificios de apartamentos. Henry Z. Steinway nación en un piso del edificio que se erigió en el solar de la Cuarta Avenida que ocupaba la primera fábrica Steinway. Lo que mantuvo a Steinway & Sons cuando la gente tuvo que conformarse con viviendas más pequeñas que las casas adosadas de sus padres fue el modelo M, un piano de cola que empezó a fabricarse en 1912 y que medía un metro menos que los gran cola como el K0862 (el protagonista del libro, un modelo D).

-o-

El problema de los pianos es que son orgánicos y cambian constantemente. No tienen nada que ver con la fabricación de neveras y cosas así.

-o-

[Acerca del ajuste de cuerdas en el piano] Utiliza una herramienta que tiene una especie de gancho al final y tira con fuerza. “Algunos llevamos pinzas de médico, de las que usan para cortar hemorragias, que parecen unas tijeras largas”, dice. Se refiere a las pinzas de hemostasia; algunas tienen dientes en los filos y vienen muy bien para tirar de las cuerdas.

Code as Design: Three Essays by Jack W. Reeves

 
 
 
Por alguna razón tengo en la recámara desde hace meses una versión alternativa del artículo sobre La programación como proceso de diseño. Y como creo que es bastante diferente del “original”, además de que siempre es buena idea hablar sobre desarrollo de software, lo añado a continuación. 
 
🙂
 

Code as Design: Three Essays by Jack W. Reeves

Estos ensayos con casi veinte y diez años de antiguedad, siguen siendo una verdad como un templo y comenta cosas que la mayoría de las personas en el mundo del software ignoran (y olvidamos), con consecuencias negativas a corto, medio y largo plazo.

El punto clave del ensayo es que desarrollar código, es un proceso de diseño, y es uno muy complicado.

Siempre se compara el desarrollo de software con otras ingenierías donde se diseña y construye algo físico. Pero es incorrecto. Si hacer aviones se pareciese a hacer software, entonces pulsando un botón, los planos y especificaciones de un Boeing 747 se convertirían en un avión real y en pleno vuelo en cuestión de segundos o minutos a coste cercano a cero. Si se tratase de hacer puentes, el F5 nos permitiría levantar un puente para comprobar cuanto peso aguanta con pilares de un material u otro en el mismo tiempo y al mismo coste.

La naturaleza de las ingenierías “normales” es construir algo en base a unas especificaciones. Algo caro de diseñar, pero muchisimo más caro de construir (tiempo, recursos, gente). En software la “build“, es decir el producto final construido, es cuestión de un compilador y un par de minutos (o segundos). Lo realmente caro es el diseño, y el diseño (especificaciones, planos…) es el código. Construir en base al diseño es labor del compilador y al contrario que en todas las demás ingenierías, tiene un coste en tiempo y dinero cercano a cero.

Partiendo de esa premisa, es fácil de donde vienen ciertos problemas, como las especificaciones mutantes, el scope creep, etc.


A continuación dejo algunas citas interesantes.

 

Revelation number two: it is cheaper and simpler to just build the design and test it than to do anything else. We do not care how many builds we do—they cost next to nothing in terms of time, and the resources used can be completely reclaimed later if we discard the build. Note that testing is not just concerned with getting the current design correct, it is part of the process of refining the design. Hardware engineers of complex systems often build models (or at least they visually render their designs using computer graphics). This allows them to get a “feel” for the design that is not possible by just reviewing the design itself. Building such a model is both impossible and unnecessary with a software design. We just build the product itself. Even if formal software proofs were as automatic as a compiler, we would still do build/test cycles. Ergo, formal proofs have never been of much practical interest to the software industry.

-o-

The overwhelming problem with software development is that everything is part of the design process. Coding is design, testing and debugging are part of design, and what we typically call software design is still part of design. Software may be cheap to build, but it is incredibly expensive to design. Software is so complex that there are plenty of different design aspects and their resulting design views. The problem is that all the different aspects interrelate (just like they do in hardware engineering).

-o-

[…] no other modern industry would tolerate a rework rate of over 100% in its manufacturing process. A construction worker who can not build it right the first time, most of the time, is soon out of a job. In software, even the smallest piece of code is likely to be revised or completely rewritten during testing and debugging. We accept this sort of refinement during a creative process like design, not as part of a manufacturing process. No one expects an engineer to create a perfect design the first time. Even if she does, it must still be put through the refinement process just to prove that it was perfect.

-o-

The software design is not complete until it has been coded and tested. Testing is a fundamental part of the design validation and refinement process. The high level structural design is not a complete software design; it is just a structural framework for the detailed design.

-o-

It would be nice if high level software design could be a more rigorous engineering process, but the real world of software systems is not rigorous. Software is too complex and it depends on too many other things. Maybe some hardware does not work quite the way the designers thought it did, or a library routine has an undocumented restriction. These are the kinds of problems that every software project encounters sooner or later. These are the kinds of problems discovered during testing (if we do a good job of testing), for the simple reason that there was no way to discover them earlier. When they are discovered, they force a change in the design. If we are lucky, the design changes are local. More often than not, the changes will ripple through some significant portion of the entire software design (Murphy’s Law). When part of the effected design can not change for some reason, then the other parts of the design will have to be weakened to accommodate. This often results is what managers perceive as “hacking”, but it is the reality of software development.

-o-

As just a small point, all programmers know that writing the software design documents after the code instead of before, produces much more accurate documents. The reason is now obvious. Only the final design, as reflected in code, is the only one refined during the build/test cycle. The probability of the initial design being unchanged during this cycle is inversely related to the number of modules and number of programmers on a project. It rapidly becomes indistinguishable from zero.

-o-

The generally accepted definition is that a “specification” states the what, which is followed by a design document that details the how. While there is a certain amount of flexibility allowed of the compiler in determining the how of object code, there is certainly no creativity involved. And that is where I draw the line. When the document is detailed enough, complete enough, and unambiguous enough that it can be interpreted mechanistically, whether by a computer or by an assembly line worker, then you have a design document. If it still requires creative human interpretation, then you don’t.

-o-

Back to software. We in the software industry also refine our designs, only we don’t get to call it engineering. We call it “testing and debugging”. This phase of the software lifecycle takes a long time. All too often it takes longer than planned. Unfortunately, it is often not enough and the final designs that we turn into deliverable software are still not as good as they should be. This seems like a fact of software life. Many people lament it and ask why we software developers do not “engineer” our designs better? Many explanations are offered, but never the one most obvious to me — simple economics. Software is dirt cheap to build.

-o-

I suspect that most engineers in other disciplines haven’t a clue about what percentage of their time is spent actually creating a design and what is spent on testing and debugging the result. Some industries are probably better than software. I am pretty sure that other industries are actually much worse. Consider what it must take to “design” a new airliner.

-o-

I get somewhat testy when people start making gratuitous comparisons between software design and other engineering disciplines. Major microprocessors have been shipped with bugs in their logic, bridges have collapsed, dams broken, airliners fallen out of the sky, and thousands of automobiles and other consumer products recalled – all within recentmemory and all the result of design errors.

-o-

The bottom line is that my design must be correct, or every piece of software built from it will be erroneous. Therefore I concentrate on doing it right, and it takes mental effort and skill, just like any other creative design activity.

-o-

Even the best of the traditional approaches continue to try to break software design into disjoint steps with separate notations and products, and then they continue to wonder why they have problems getting a final software product that is correct.

-o-

Same thing. Likewise, Warner-Orr diagrams, Booch diagrams, object diagrams, you name it. Each has its strengths, and a single fundamental weakness – it really isn’t a software design. Ultimately, improvements in programming techniques are overwhelmingly more important to software development than anything else.

La programación como proceso de diseño (Code as Design)

Hace unos meses que tengo pendiente comentar un poco los ensayos de Jack W. Reeves: Code as Design.

Se trata de unos textos realmente valiosos dada su relevancia a lo largo de dos décadas (el primero fue publicado inicialmente en 1992) y por la peculiaridad de que la idea fue revisada 13 años después. Pero además es decepcionante ver como aun hay muchos profesionales del sector que no tienen claro lo que comentaba Reeves ni nada remotamente parecido.

La idea central que plantea Reeves es simple en su formulación: el desarrollo de software es un proceso de diseño. Pero esa simpleza oculta multitud de ideas interesantes y de prejuicios dentro y fuera del sector que llevan a considerar al programador como un obrero más. Y así nos va.

Esa idea nos lleva a plantear la obligatoriedad de que los cambios de requisitos deberían ser caros. Y que los desarrolladores ni son albañiles, ni son intercambiables como les gusta pensar a las grandes consultoras. O que el presupuesto cerrado a la hora de entregar un software es una estupidez de base. Pero como es un ensayo corto y discutido a lo largo de 20 años, creo que será mejor que cada uno lo lea (es corto) y juzgue por sí mismo.

A continuación para tratar de animar a los mas perezosos a leerse los ensayos, pongo algunas citas interesantes:

The Unpredictability of Requirements
There’s a refrain I’ve heard on every problem project I’ve run into. The developers come to me and say “the problem with this project is that the requirements are always changing”. The thing I find surprising about this situation is that anyone is surprised by it. In building business software requirements changes are the norm, the question is what we do about it. 

One route is to treat changing requirements as the result of poor requirements engineering. The idea behind requirements engineering is to get a fully understood picture of the requirements before you begin building the software, get a customer sign-off to these requirements, and then set up procedures that limit requirements changes after the sign-off. 

One problem with this is that just trying to understand the options for requirements is tough. It’s even tougher because the development organization usually doesn’t provide cost information on the requirements. You end up being in the situation where you may have some desire for a sun roof on your car, but the salesman can’t tell you if it adds $10 to the cost of the car, or $10,000. Without much idea of the cost, how can you figure out whether you want to pay for that sunroof? 

Estimation is hard for many reasons. Part of it is that software development is a design activity, and thus hard to plan and cost. Part of it is that the basic materials keep changing rapidly. Part of it is that so much depends on which individual people are involved, and individuals are hard to predict and quantify. 

Software’s intangible nature also cuts in. It’s very difficult to see what value a software feature has until you use it for real. Only when you use an early version of some software do you really begin to understand what features are valuable and what parts are not. 

This leads to the ironic point that people expect that requirements should be changeable. After all software is supposed to be soft. So not just are requirements changeable, they ought to be changeable. It takes a lot of energy to get customers of software to fix requirements. It’s even worse if they’ve ever dabbled in software development themselves, because then they “know” that software is easy to change. 

But even if you could settle all that and really could get an accurate and stable set of requirements you’re probably still doomed. In today’s economy the fundamental business forces are changing the value of software features too rapidly. What might be a good set of requirements now, is not a good set in six months time. Even if the customers can fix their requirements, the business world isn’t going to stop for them. And many changes in the business world are completely unpredictable: anyone who says otherwise is either lying, or has already made a billion on stock market trading. 

Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan.

En serio. Si no lo has leído, léelo ya.