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.