Software Practices - Sandwich Design

Today, I was reading a colleague's blog. In his last post (in Spanish) he defends the programmer as a software professional and provides a great outlook of its —generally misconceived— role, duties and difficulties. That immediately reminded me about the opposite figure: the architecture astronaut as described in Joel Spolsky's article. At some companies both roles officially exist (software astronauts not being desing as such but in other pompus terms). Sometimes they even group them into separate buildings, Kilometers away from each other.

What does all this has to do with this post's title?. Well, I dare say that officially separating both roles warps each individual's mind towards two software design approaches. Top-down and bottom-up. Analysis and synthesis.

Astronauts deal with ideas, designs and hopes. They analyse a problem. They concieve a view of the solution and try to put it somewhere, somehow. Call it a UML diagram or whatever. They generally don't care too much about technological or programming issues, as every difficulty can be overcome, and think the hard work is done. Remember, top-down. Once decomposed it should be easy.

If you ever wrote a line of code in a medium-sized project —which you might not if you're in the Cosmo Team— and you're humble and honest —scarce virtues— you know that, at this point, the process just reverses and it's not easy at all.

Programmers need to deal with lines of code and machines. They are forced to syntethise, given their circumstances. They take some sort of specification, design —when lucky—, a technological environment in form of software and hardware and need to combine all this to produce something that works —or, at least, appears to—. In some way, it's pure bottom-up. The programmer's materials for the building process are existing technologies, libraries, language primitives, etc. that must be mixed together "upwards" to match the design, functionality or specification. The same materials that might have been overlooked during the analytical process.

This is the main reason why, when left alone —probably by inertia—, most programmers take the bottom-up approach. The bad news is that they generally forget that the bottom-up approach is also a design approach that also involves an analytical process. But they generally rush to code. When the main program and some tricky parts are outlined the hard work is done. Remember, bottom-up. Design will magically arise and every piece will fit. Once a few things are outlined or coded it should be easy.

Same dog, different collar?. Sure. Now a different set of problems arises: forgotten functionalities, huge refactoring efforts, this-is-not-what-I-expected user dissatisfaction, etc. but that's another story.

So, why don't we take the best of both worlds and use 'Sandwich Design' practices?. Let's analyze the problem without overlooking or ignoring the building materials, skills or details. Let's take a wider point of view and try to provide a solution from both sides, from the top and from the bottom.

In the software development world you'll often see architecture astronauts proposing completely absurd, complex or already solved solutions. You'll often see programmers who excel at programming and know about tiny pieces of technology that could potentially solve complex problems but who don't care at all about what the general problem is.

I think that working from both ends, analysis and synthesis will converge more easily, also mitigating friction among teams and processes and providing a shorter schedule.

This is much easier to achieve in small or medium-sized companies that take a more integrated approach in Software Development. In fact, I believe the best ones really forget about prejudices and myths, roles and methodologies and, aware or not, are using Sandwich Design all the time.

"Cosas", por Paul Graham

Tras muchos meses de parón propongo una nueva traducción. Como es habitual, casi siempre hay alguien que se adelanta y/o escribe las cosas mejor de lo que uno lo haría. En este caso se trata de Paul Graham hablando sobre la acumulación de "cosas".

El artículo original se titula "Stuff".

Tengo demasiadas cosas. Le ocurre a la mayoría de los americanos. De hecho, cuanto más pobre es la gente, más cosas parece que tiene. Poca gente es tan pobre como para no poder permitirse llenar su jardin de coches viejos.

Esto no siempre ha sido así. Las cosas solían ser escasas y valiosas. Todavía pueden encontrarse evidencias si se buscan. Por ejemplo, en mi casa de Cambridge, construida en 1876, las habitaciones no tienen armarios. En aquellos tiempos las cosas que tenía la gente cabían en una cajonera. Incluso hace sólo unas décadas, la gente tenía muchas menos cosas. Cuando veo fotos de los 70 me sorprendo de lo vacías que parecían estar las casas. Cuando era niño tenía lo que creía que era una flota enorme de coches de juguete, una cantidad ridícula comparada con la cantidad de juguetes que tienen mis sobrinos. Todos mis Matchboxes y Corgis (coches de juguete) juntos ocupaban un tercio de la superficie de mi cama. En la habitación de mis sobrinos la cama es el único lugar que queda libre.

Las cosas se han abaratado muchísimo pero nuestra actitud hacia ellas no ha cambiado. Sobrevaloramos las cosas.

Esto era un gran problema para mí cuando no tenía dinero. Me sentía pobre y las cosas parecían valiosas, así que las acumulaba casi instintivamente. Los amigos se dejaban algo cuando se trasladaban, veía cosas en buen estado abandonadas en la basura alguna noche, me encontraba con algo casi nuevo por una décima parte de su precio que alguien vendía en su garaje. Y, zas, más cosas.

En realidad estas cosas gratuitas o casi gratuitas no eran ninguna ganga porque valían menos de lo que costaban. La mayoría de las cosas que acumulé no valían nada porque no las necesitaba.

Lo que yo no entendía era que el valor de una nueva adquisición no era la diferencia entre su P.V.P. y lo que yo pagaba por ella. Era el valor que yo obtenía de ella. Las cosas son activos extremadamente ilíquidos. Si no se tiene un plan para vender esa cosa tan "valiosa" comprada tan barata, ¿qué es lo que la hace valiosa?. La única forma de obtener algún beneficio de ella es usándola. Y si no se le da un uso inmediato es probable que nunca se le dé.

Las empresas que venden cosas han invertido enormes sumas de dinero en hacernos pensar que las cosas todavía son valiosas. Pero sería más cercano a la verdad tratar las cosas como si no valieran nada.

De hecho, es peor todavía, porque una vez acumulada una determinada cantidad de cosas, las cosas empiezan a poseerle a uno, en vez de ser al revés. Conozco a una pareja que no pudo retirarse a su pueblo favorito porque no podían permitirse una casa lo suficientemente grande como para albergar todas sus cosas. La casa no es de ellos, es de sus cosas.

Y, salvo que uno sea extremadamente organizado, una casa llena de cosas puede resultar muy deprimente. Una habitación desordenada y revuelta mina el espíritu. Una razón, obviamente, es que hay menos sitio para la gente en una habitación llena de cosas. Pero hay más. Creo que los humanos examinamos constantemente nuestro entorno para construirnos un modelo mental de lo que nos rodea. Cuanto más difícil de analizar es la escena, menos energía queda para los pensamientos conscientes. Una habitación revuelta es literalmente agotadora.

(Esto puede explicar por qué el desorden no parece molestar tanto a los niños como molesta a los adultos. Los niños son menos perceptivos. Construyen un modelo menos elaborado de su entorno y esto consume menos energía.)

La primera vez que me di cuenta de la carencia de valor de las cosas fue cuando viví un año en Italia. Lo único que me llevé fue una gran mochila llena de cosas. El resto de mis cosas las dejé en el ático de mi casera en Estados Unidos. Y, ¿sabes qué?. Sólo eché de menos los libros. A final de año ni era capaz de recordar qué más tenía almacenado en el ático.

Y cuando volví sólo me deshice de una caja de cosas. ¿Tirar un teléfono de disco?. Puede que algún día lo necesite.

Lo realmente triste de todo esto no es que acumulara toda estas cosas inútiles, sino que generalmente me gastaba dinero que necesitaba desesperadamente en cosas que no necesitaba.

¿Por qué lo hacía?. Porque la gente que se dedica a vender cosas es realmente buena en su trabajo. Un joven de 25 años no es rival para empresas que han invertido años investigando cómo hacer que te gastes dinero comprando cosas. Hacen de la experiencia de comprar cosas algo tan agradable que "comprar" se ha convertido en una actividad de ocio.

¿Cómo protegerse de estas personas?. No puede ser fácil. Soy una persona bastante escéptica y aun así sus trucos han funcionado conmigo hasta bien entrado en la treintena. Pero algo que puede funcionar es preguntarse, antes de comprar algo, "¿esto va a hacer que mi vida sea notablemente mejor?".

Una amiga mía se curó de su hábito de comprar ropa preguntándose a sí misma antes de comprarse algo "¿voy a ponerme siempre esto?". Si no era capaz de convencerse a sí misma de que lo que estaba pensando comprar era una de esas cosas que siempre se pone, no lo compraría. Creo que esto funciona para cualquier tipo de compra. Antes de comprar algo, pregúntate: ¿voy a utilizar esto constantemente? ¿o simplemente es algo bonito? o, todavía peor, ¿es simplemente una ganga?.

Las peores cosas a este respecto son las cosas que no se usan mucho porque son demasiado buenas. Nada posee más a uno que las cosas frágiles. Por ejemplo, la "porcelana" que tantas familias tienen y cuya cualidad que la define no es que sea divertida de utilizar, sino que uno tiene que ser especialmente cuidadoso para no romperla.

Otra forma de resistirse a comprar cosas es pensar en el coste total de poseerlas. El precio de compra es sólo el principio. Hay que pensar en esa cosa durante años—quizá durante el resto de la vida. Todo lo que uno posee resta energía a un mismo. Algunas cosas proporcionan más de la que restan. Ésas son las cosas que merece la pena tener.

Yo ya he parado de acumular cosas. Excepto libros—pero los libros son diferentes. Los libros se parecen más a un fluido que a objetos individuales. Tener varios miles de libros no es un inconveniente especialmente grande, mientras que si poseyeras miles de cosas aleatorias serías famoso en tu vecindario. Salvo libros, ahora intento evitar activamente las cosas. Si alguna vez quiero gastar dinero en darme algún capricho, lo emplearé en servicios y no en bienes.

No alego esto porque haya alcanzado algún tipo de indiferencia tipo zen acerca de las cosas. Hablo de algo más mundano. Ha habido un cambio histórico y ahora soy consciente. Las cosas solían ser valiosas, pero ya no lo son.

Pasó lo mismo con la comida a mitad del siglo veinte en los paises industrializados. Conforme la comida se abarataba (o nos enriquecíamos; es indistinguible), comer demasiado comenzó a ser más peligroso que comer poco. Ahora hemos alcanzado ese mismo punto con las cosas. Para la mayoría de la gente las cosas han llegado a suponer una carga.

La buena noticia es que, si llevas una carga encima sin saberlo, tu vida puede ser mejor de lo que imaginas. Imagina que has estado andando con pesas de dos kilos en los tobillos durante años y que te las quitas de repente.

12 pasos hacia un código mejor

Hace ya seis años Joel Spolsky escribió un artículo titulado "The Joel Test: 12 Steps to Better Code", proponiendo un pequeño test para evaluar el lugar donde trabajamos o vamos a trabajar.

Gracias al wiki para traducciones que abrió Joel, pude contribuir facilmente a su traducción.

Creo que sigue siendo un artículo vigente; he aquí un pequeño extracto:

¿Te suenan las siglas SEMA?. Es un sistema un tanto exótico de medir lo bueno que es un equipo de desarrollo de software. No, ¡espera!. ¡No sigas el enlace!. Te costaría unos seis años solamente entenderlo. Por eso he creado un cutre-test altamente irresponsable de mi propia cosecha para medir el nivel de calidad de un equipo de desarrollo. Lo bueno que tiene este test es que hacerlo cuesta unos tres minutos. Con todo el tiempo que te ahorrarás, puedes aprovechar y estudiar medicina.

El Test de Joel

1. ¿Utilizas software de control de versiones?
2. ¿Puedes generar el producto en un solo paso?
3. ¿Compilas el producto diariamente?
4. ¿Tienes una base de datos para los bugs?
5. ¿Corriges los bugs antes de añadir más código?
6. ¿Tienes una planificación actualizada?
7. ¿Tienes un documento de especificaciones?
8. ¿Están los programadores en un lugar tranquilo?
9. ¿Utilizas las mejores herramientas que puedes comprar?
10. ¿Tienes gente para probar los productos?
11. ¿Haces escribir código a los nuevos candidatos en las entrevistas?
12. ¿Haces pruebas de usabilidad "de vestíbulo"?

La traducción completa está aquí.

Si los arquitectos fueran ingenieros de software

Para iniciar una serie de reflexiones acerca del desarrollo de software, propongo como aperitivo un texto que se acerca bastante a la realidad de quien se enfrenta a tareas de desarrollo de software.

Se trata de un paralelismo que muestra a lo que tendría que enfrentarse un arquitecto si las cosas funcionaran como lo hacen en el mundo del desarrollo software.

El texto original no es mío. Se titulaba "If architects had to work like web designers" y ya no sé muy bien cuál es la fuente original, así que los interesados tendrán que buscarla.

Dejo una traducción de mi propia cosecha aquí:

Querido Sr. Arquitecto,

Por favor diséñeme y constrúyame una casa. No estoy muy seguro de cómo la quiero, así que lo dejo a su discreción. Mi casa debería tener entre 2 y 45 habitaciones. Simplemente asegúrese de que sea fácil añadir o quitar habitaciones en cualquier momento. Cuando me enseñe los planos ya le comunicaré mi decisión final. No se olvide de traerme el estudio de costes para cada configuración y así pueda elegir la que más me convenga.

Tenga siempre en cuenta que la nueva casa que elija debe ser más barata que en la que estoy viviendo ahora. Asegúrese, sin embargo, de que no sufre de las mismas deficiencias que mi casa actual (el suelo de la cocina vibra al andar sobre él y las paredes no tienen aislamiento suficiente).

Mientras va diseñando, también recuerde que quiero que los costes de mantenimiento sean mínimos. Esto puede implicar la incorporación de materiales fuera de presupuesto como aluminio, vinilo, etc… (si finalmente decide no utilizar aluminio debería justificarme su decisión en detalle).

Por favor asegúrese de que posea un diseño actual y de que se utilicen los materiales más modernos en la construcción de la casa, pues quiero que sea una muestra de los métodos e ideas más vanguardistas. Le aviso de antemano de que el diseño de la cocina tiene que tener en cuenta, entre otras cosas, la instalación de mi frigorífico de hielo de 1952.

Para asegurarse de que está construyendo la casa correcta para nuestra familia no olvide hablarlo con nuestros hijos y también con nuestra familia política. Mi suegra le dará unas buenas pautas de cómo debería diseñar la casa, ya que nos visita al menos una vez al año. Asegúrese de que valora todas estas ideas con especial cuidado para tomar la decisión correcta. Sin embargo, no olvide que soy yo quien tiene la última palabra.

Por favor no me moleste con detalles sin importancia ahora. Su trabajo es planificar la construcción de la casa: ver las cosas de forma global. Éste no es el momento adecuado, por ejemplo, de elegir el color de la moqueta. Por cierto, no olvide que a mi mujer le gusta el azul.

Tampoco se preocupe en este momento de los recursos necesarios para construir la casa en sí misma. Su prioridad absoluta es diseñar los planos y las especificaciones detalladas. Una vez que le dé mi visto bueno, sin embargo, espero que la casa esté construida en 48 horas.

A pesar de que está diseñando la casa totalmente a mi medida, no olvide que antes o después acabaré vendiéndola, así que debe ser atractiva para una gran variedad de potenciales compradores. Por favor asegúrese antes de terminar los planos de que existe consenso positivo en mi barrio acerca de las características de mi casa. Le aconsejo que se acerque a la casa que le construyeron a mi vecino el año pasado. Nos gusta mucho. Tiene muchas cosas que nos gustaría que la nuestra también tuviera, especialmente la piscina de 25 metros. Con un poco de esmero, supongo que podrá incluirla también en nuestra casa sin que influya en los costes finales.

Por favor, prepáreme un conjunto completo de proyectos. No hace falta en este momento que el diseño sea el final, puesto que por ahora sólo se usarán como promoción comercial. Le aviso, sin embargo, que será usted el responsable de cualquier incremento en los costes como resultado de rediseños posteriores.

¡Debe estar usted emocionado de trabajar en un proyecto tan interesante como éste! Poder utilizar las técnicas y materiales de última generación y poseer toda esa libertad para diseñar es algo que no ocurre a menudo. Contacte conmigo lo antes posible para contarme sus ideas y entregarme los planos.

PD: Mi mujer me acaba de decir que no está de acuerdo con muchas de las instrucciones que le acabo de dar en esta carta. Como arquitecto, es su responsabilidad resolver estas diferencias; yo ya lo he intentado en el pasado y jamás he sido capaz de lograrlo. Si no es usted capaz de aceptar esta responsabilidad, tendré que empezar a buscar otro arquitecto.

PD2: A lo mejor lo que realmente necesito no es una casa, si no una auto-caravana. Si cree que es el caso, comuníquemelo lo antes posible.

Actualización (29 de mayo de 2006):

Esta traducción la tenía almacenada desde hace tiempo y la he publicado directamente. Al parecer ya había sido traducida por otra persona en Mundo Geek

What is NOT beta software

From Wikipedia:

"A beta version or beta release usually represents the first version of a computer program that implements all required features although additional features may be added. It is likely to be unstable but useful for internal demonstrations and previews to select customers, but not yet ready for release."

Yes, we all confuse terms from time to time but, come on, this one is easy. Isn't it?

What is NOT beta software:

• An idea you had while having some beers with a couple of friends at the local pub which led to a wonderful (but empty) web site to announce it. (Great way to confuse and disappoint people).
• An attempt to show how cool you are in a new language or framework by creating a new, incomplete and buggy implementation of a useless program which you never think to finish or mantain. (Does it make sense to call something beta if you're not following a development cycle?).
• Three lines of code at sourceforge.net that you want other people to develop and finish for you without event knowing exactly what you want. (Do the words 'analysis', 'design' or 'specification' mean something to you?).
• A program which constantly shows error messages when you're using it as expected. (That's not unstable, that's crap).
• Desktop software without any kind of documentation, tips or hints on how to install it or use it, that only works on your computer. (Great way to distribute it!).
• A way to publicize other products or projects by means of a powerpoint presentation about a non-existing program which shows a couple of screenshots you designed the day before. (No comments).
  

Software development is hard and anyone can do whatever he wishes, but fortunately English is a very rich language. Some other useful terms that may describe some programs more accurately include (from Wikipedia again):

"Pre-alpha: Sometimes a build known as pre-alpha is issued, before the release of an alpha or beta. In contrast to alpha and beta versions, the pre-alpha is usually not "feature complete". At this stage designers are still determining exactly what functionalities the product should have. Such builds can also be called development releases or nightly builds."

"Alpha: The alpha version of a product still awaits full debugging or full implementation of all its functionality, but satisfies a majority of the software requirements. It often lacks features promised in the final release, but demonstrates the feasibility and basic structure of the software."

"Vaporware (...) is software or hardware which is announced by a developer well in advance of release, but which then fails to emerge (...). The term implies deception, (...) it implies that the announcer knows that product development is in too early a stage to support responsible statements about its completion date, feature set, or even feasibility."

Snake oil is a Traditional Chinese medicine used for joint pain. However, the most common usage of the words is as a derogatory term for medicines to imply that they are fake, fraudulent, and usually ineffective. The expression is also applied metaphorically to any product with exaggerated marketing but questionable or unverifiable quality."

So could we all please stop spreading the wrong meaning of 'beta'?

Your IT degree is over. Some advice for a smooth transition.

Yep, you finally managed to pass all your exams and deliver your final project on time. Five or more years dealing with complex algorithms, software engineering practices and countless other topics which give you a solid base and a bit of fun. Now you should be prepared to face reality with a relatively high degree of comfort. Are you sure?.

A math teacher recently told me that all formal studies are taught based on the supossition that when you finish that stage, you'll continue studying. Primary School is a preliminary to High School, High School to University, University is your career towards your PhD, and so on. So, what happens when you find a job, thus breaking the education link?.

Your mileage may vary, but I bet most of us felt really annoyed during that transition. Reality can be very different to what you had imagined. You need to get used to it.

With your permission, here's some advice that can make the transition smoother:

1. Learn English (and learn it well). If you're in the IT field, no matter in which country, English is no longer a plus. It's a must. Just as nowadays you can't conceive a computer with no network, think of English as the mean of communication in the field. Superficial understanding of a technical article is not enough, so make a little effort if you need to improve it.
   
2. Find a good mentor. This is a difficult one, but try hard to find a mentor inside your organization if you can. He can be your boss, a colleague or maybe even someone from other department. An experienced, willing-to-teach person can solve your doubts, clear your thoughts, refer you to good information sources and guide you towards the right direction.
   
3. Search the Web. Yeah, the web can be full of rubbish but, believe me, it's also full of invaluable information and incredibly smart people. To begin with, don't miss a single article from Joel Spolsky . Browsing through his weblog you'll learn how to write a specification, how to schedule a project, etc... in a useful and realistic manner, far away from formal methods that are rarely used (another lesson you'll learn when you face reality). This is just an example, have a look and you'll find other superb sources of information.
4. Read books. Fortunately, superb books are available on every conceivable topic. I don't recommend you to buy very technical books, cause they are expensive and they'll get outdated in a year. These are the kind of books that should be bought by your company. Instead, spend a few bucks in classic or more pleasant to read books that you can leave on your bedside table. There are lots of them, but maybe you can begin with "Peopleware: Productive Projects and Teams" or "The Pragmatic Programmer", depending on your interests. Buy them in English and always check an on-line store before paying extra money at some expensive bookstores.
   
5. Be patient and humble, but believe in yourself. Your career dind't begin at University. It begins now. So be patient and humble, ask when you need it and learn as much as you can. Experience is important, but don't underestimate yourself when you hear or read from others, cause you might surpass their abilities in a short period of time. Many people exaggerate (or even lie), so be critic and believe in yourself as much as you believe in others.
   

This is just a little introduction that I hope can help you through this process, but don't forget that your experience is the one that matters. So go for it.

PS: How was your transition from University to your first job? Any advice? Share your story with us!


Feedback from readers:

25 May 2006, Ghost:

1. Play with as much as possible as you can - do a Ruby On Rails application, write a Python script, make a modification to a PERL program and contribute to a SourceForge Java application. It's not going to hurt and you will learn different techniques that you may not be officially taught at Uni.
2. Have at least one demonstration program you can reference in your resume and show off when asked. Preferably this should be something in the field that you want to get into. If it's desktop applications - make sure you have a version that runs on your laptop backed by a MySQL or Access database, if it's web based make sure that your name is on the site somewhere and include the URL in your resume as well as having a local test copy on your laptop.
3. Always take your laptop to interviews with you. Make sure it's loaded with code, you have a local copy of MSDN or the JRE runtime reference, or the Python library reference as well (preferably all of them). Be prepared to show off your own code if that answers a question in more detail than you could yourself (Remember - actions speak louder than words).
4. SourceForge projects may be considered lame - but they are very public and it is quite easy to send a link to a list of contributions that you have made. It also shows that you can work in a team, respond to externally submitted bugs and make your own contributions. All of this is important.

My very first blog entry

Writing is hard. Writing in a language you learnt at school and you seldom use is even harder. Just add about ten years of scientific-oriented education and you can get an idea of what a challenge this can be.

I'll write in English or in Spanish depending on the subject, my mood, my abilities or who knows what.

This blog is focused towards the IT world, especially project management and software development, but don't expect to find a technology freak here.

Just take a look at the blog title again and don't despair if you find me writing about the most stupid things you could probably imagine.

Please feel free to send any comments on any mistakes (especially in English), opinions or suggestions.