Blog

7 lecciones de «La Catedral y El Bazar»

Portada de La Catedral y El Bazar «The cathedral and the bazaar» de Eric S. Raymond es un clásico de la literatura del Open Source. Lo leí hace unos años pero hace unos meses leí un post muy interesante de José Manuel Alarcon, del cual pude extraer 7 lecciones para el desarrollo de software:

  • Todo buen trabajo de software comienza por rascar el «picor» de un buen programador.

Si no tienes motivación, no empieces. Normalmente un día te llega una idea a tu cabeza, algo se desarrolla en tu interior, tienes que empezar a picar código. La verdad que es una sensación similar a la de leer un libro cuando te engancha o cuando tienes que escribir algo (post en un blog). Programar es sacar algo que tienes rondando en la cabeza, un picor…

  • Los buenos programadores saben qué código escribir. Los grandes programadores saben qué código reescribir.

Hacer las cosas simples es algo que cuesta mucho en nuestra profesión. Tendemos siempre a complicar las cosas, a volver a inventar ruedas que ya están escritas. A veces hasta hay programadores que no usan Velneo para hacer sus aplicaciones de gestión empresarial :). Simplemente inexplicable, nos gusta trabajar de más. Utiliza las open apps, mira lo que ya está desarrollado y ÚSALO.

  • Planea tirar al menos una vez el trabajo. Lo harás de todos modos.

Llevo 10 años de mi vida, escuchando  lo voy a tirar abajo y reescribirlo. Cuanto más pienses y más analices menos te pasará pero en nuestra profesión, nos gusta complicarnos. Te imaginas que otras profesiones digan hombre el puente ya está acabado pero lo vamos a tirar abajo que va a quedar más optimizado :).

  • Si tienes la actitud correcta, los problemas interesantes te encontrarán.

La aptitud y actitud es lo más importante, tarde o temprano la idea rondará la cabeza entonces, vete a por ella. No limites tu creatividad.

  • Es mejor tener estructuras de datos bien pensadas y mal código que al revés.

Lo mejor está claro que es tener buenas estructuras con buen código. La arquitectura es lo más importante. En un edificio los pilares son los que tienen que estar perfectos, si un alicatado no está perfecto no es tan importante como tener un pilar torcido. Pasa todo el tiempo que puedas analizando los pilares de tu proyecto.

  • La perfección (en diseño) se consigue no cuando no hay nada más que añadir, sino más bien cuando ya no hay nada más que quitar.

Es el principio KISS. Creo que esto se está convirtiendo en una obsesión para mi. Los programadores somos los primeros que ponemos opciones de más, campos de más, estructuras que sobran. Los programadores nos complicamos, cuando algo nos parece sencillo lo hacemos complicado. Nos gusta más programar que pensar y eso hace que muchas veces programemos más tiempo que analizamos ¿Para qué?, ¿Qué se va ha hacer con ese campo?, cuando un usuario nos pide algo es más fácil programarlo muchas veces que analizar cual es la necesidad real, ¿Por qué tengo que añadir el campo? ¿El informe?, al final las aplicaciones se convierten en grandes Frankenstein. ¿Crees que le puedes quitar algo más a tu app? ¿Algún campo? ¿Alguna opción? SIGUE EL PRINCIPIO KISS

  • Una herramienta debe ser útil en el modo esperado, pero una herramienta realmente buena suele dar usos que nunca habías esperado.

Eres capaz de sorprender a tus usuarios, o mejor aún te sorprende lo que tus usuarios consiguen hacer con tu software. Eso es programar abstracto. Cuando tu software es capaz de sorprender y que te sorprendan realmente lo conseguiste.

4 thoughts on “7 lecciones de «La Catedral y El Bazar»

  1. Me parecen unos buenos consejos a tener muy en cuenta.
    Solo una apreciacion al punto 2: el motivo por el que muchas veces no se utilizan las Open Apps o las Plantillas ya terminadas es poque no se ajustan a nuestras necesidades y esos «Pilares» (la estructura de la base de datos) no resulta interesante, y otras muchas veces, porque no estan lo suficientemente explicadas para entender correctamente su uso y aplicacion, y esto nos lleva al punto anterior, y no estamos seguros de que pueda adaptarse a nuestras necesidades. Y ante la duda «la mas te..» :D, ahora en serio, ante la duda, prefiero crear mi propia plantilla, que me cuesta menos que tratar de entender lo que otros han querido plasmar. Esto se solucionaria con una buena documentacion, que casi nunca llevamos a cabo.
    Un saludo
    José Luis
     

  2. @Pepeto, 100% de acuedo con tu puntualización. Sabemos que la documentación es tan importante como la propia Open App. Este caso lo comenté en la Open App para Skype http://alfonsogu.com/2010/04/28/velneo-v7-y-skype/ donde me llevó más tiempo la documentación que la propia Open App.

    De todas maneras estaremos de acuerdo que uno de los puntos diferenciales de Velneo es que es la plataforma de desarrollo donde mejor se entiende el desarrollo de otros programadores, además que es relativamente fácil cambiar estructuras o pilares.

    Como bien dices por defecto «ante la duda….», a mi me ha pasado decenas  de veces, empiezas de cero en vez de pararte un poco con el desarrollo de otra persona. Es algo normal y habitual, no es lo mismo algo que tu has diseñado de 0 que reutiizar. Además pensemos que donde se ahorra tiempo de verdad es en el mantenimiento no sólo en el desarrollo.

    Tendremos que mejorar la documentación y cambiar un poco el chip, además Velneo V7 con la herencia nos abre un mundo de posibilidades respecto a la reutilización.

    Un saludete y gracias por tu gran aportación.

  3. Me parece muy interesante el sexto punto, a demás la simplicidad debe ser un concepto global de la aplicación, no solo en la programación.
    Un exceso de información en el mejor de los casos se queda arrinconado sin usar, pero frecuentemente confunde e impide ver la información relevante.
    Y un exceso de pequeñas utilidades o herramientas añadidas en una aplicación por lo general es causa de que no nos preocupemos en tener la herramienta adecuada para esas tareas, afectando muy negativamente a la productividad de los usuarios, y complicando el mantenimiento de la aplicación  y reduciendo las posibilidades de negocio para el desarrollador.
     
    El punto séptimo es la «propina» que se recibe por un servicio bien prestado

Dejar un comentario