Una de las características que me gusta de Kindle (el libro electrónico de Amazon), es que puedes señalar en los libros párrafos o frases. Es algo que hago habitualmente, de modo que cuando no tengo demasiadas ganas de leer, me he creado la costumbre de revisar las notas o citas que yo mismo he señalado de libros que me han gustado mucho. Imagino que esta funcionalidad la tendrán también los eReaders de otros fabricantes.

Del mismo modo, cuando lees cualquier libro, Kindle te indica qué secciones han sido más subrayadas por otros lectores, lo que te ayuda quizá a detectar ideas importantes que les han llamado la atención.

Movido por la curiosidad, estos días he comprado uno de mis libros en formato electrónico, El Libro Negro del Programador, por ser el que lleva publicado más tiempo y el que más comentarios tiene en las distintas plataformas en las que se vende, precisamente para averiguar, por simple curiosidad, si tenía muchas o pocas notas, o saber aquellos párrafos que hayan podido llamar la atención a un número suficiente de lectores como para que aparezca en el Kindle con la etiqueta de "148 han subrayado", por poner un ejemplo, como la captura que se ve a continuación:

Estas son las notas más señaladas por los lectores, frases, en mi opinión, bastante inspiradoras...:

"La genialidad de un buen desarrollador de software está en saber encontrar soluciones sencillas por complicado que sea un problema a resolver."

"El desarrollo de software es una actividad altamente creativa; por tanto, necesita de un ambiente que fomente esta actividad, no que la destruya o asfixie."

"Avanzar en los desarrollos con pruebas de calidad lo debemos incorporar a nuestro ADN  de desarrolladores."

"Antes de dar algo por finalizado, como por ejemplo, una nueva clase o una funcionalidad, nos debemos preguntar si hay algo que podamos hacer para mejorarlo o simplificarlo."

"A la capacidad de aprender de los errores y reponerse del fracaso, se llama resiliencia, y dado que trabajamos en una disciplina en la que los mecanismos para cometer errores están tan a mano y son tan etéreos, un buen desarrollador de software debe tener esta capacidad sí o sí: aprendemos más de los errores que de los éxitos."

"El arte de programar requiere de un entorno altamente creativo, lúcido, tranquilo, optimista y positivo."

"No se puede crear nada, ni software, ni arte, ni siquiera plantar un huerto buscando la excelencia en un ambiente desmotivador y nada creativo."

"En software, bello y elegante significa fácil y barato de evolucionar y de mantener."

"Somos eficaces en la medida que reutilizamos y escribimos código reutilizable. Esta es una de mis frases-mantra que repito continuamente."

Difícil describir la gratificación que uno siente cuando compruebas que algunas de tus ideas han calado en otros con ánimo de mejorar en su profesión.

 

No es lo mismo programar que desarrollar una carrera profesional como programador.

De qué hablo cuando hablo de programar (volumen 1)

Hoy es un día muy feliz para mí.

Ya está por fin disponible en Amazon un nuevo libro: "De qué hablo cuando hablo de programar: Cómo avanzar mejor y más rápido en tu carrera como desarrollador", porque escribir un proyecto software no es tan solo escribir líneas de código..., existen muchísimos más aspectos "alrededor" de esta actividad.

Se trata de una primera recopilación de los artículos de esta misma web, seleccionados entre los más visitados y enlazados, y que he revisado, corregido, mejorado y hasta algunos que he escrito de nuevo para incluirlos en este primer volumen, enriquecidos con mis experiencias de los últimos años (buenas y no tan buenas).

Solo leyendo el índice, pienso que ojalá me hubiesen hablado de todos esos temas cuando terminé mi etapa académica.

Os dejo aquí el capítulo de introducción.

Más información, en la propia sección del libro.

 

No hace mucho publiqué en GitHub un pequeño repositorio de nombre Red Entities, un simple pero eficiente object-mapper de consultas, actualmente compatible con Sqlite y varios sabores de MySql.

Lo he retomado para validarlo con la última versión de Node y además porque quiero incluir compatibilidad con PosgreSQL y Sql Server, sobre todo ahora que estoy terminando de documentar Mantra Framework para liberarlo.

Y lo curioso (e interesante), es que a pesar de haber desarrollado yo mismo ese proyecto software, me ha costado un poco de trabajo volver a asumirlo, aunque está bien soportado por tests y hasta me atrevería a decir que el diseño es sencillo pero robusto y eficiente, y tampoco es una librería de tamaño grande, ni mucho menos.

Tardé algo de tiempo de recordar cómo estaba implementado el mecanismo de inyección de dependencias, cómo lo dejé preparado todo para incluir nuevos conectores de acceso a otro tipo de bases de datos y cosas por el estilo.

Aunque está documentado a nivel de API, con la suficiente información para que cualquiera lo pueda usar en un proyecto en Node, este es uno de los grandes problemas a los que nos enfrentamos en el desarrollo de software, sobre todo en proyectos más o menos complejos y grandes, y que se vuelve todavía peor cuando el diseño es deficiente y hay mucha deuda técnica acumulada; esto es, leer el código, por bien que esté estructurado y desarrollado, no te permite comprender la visión de conjunto de todo el proyecto con facilidad.

Para comprender bien un proyecto software, el código no es suficiente.

No estoy hablando de entender lo que hace una clase, o un método concreto dentro de ella, o incluso una librería de pequeño tamaño, sino de toda aquella información sobre la que se ha desarrollado el proyecto, con la que se han tomado decisiones y que no está reflejada claramente en el código, puesto que la forma y estructura de éste es consecuencia de lo primero.

Se podrá pensar que en el código está todo: clases, módulos, archivos de configuración; sin embargo, existe mucha más información que no está ni puede estar en él y que es imprescindible para comprenderlo por qué el proyecto se hizo de ese modo y para qué, más aún cuando llega el momento en que otros desarrolladores distintos de los originales lo tienen que asumir.

Esto, precisamente, ha sido algunas de las peores experiencias profesionales que recuerdo: haber tenido que retomar proyectos realizados por otros (que ya ni siquiera estaban en la organización para la que trabajaba). Recuerdo uno en concreto en java y otro en php, con miles de líneas de código y con varios años de desarrollo y evolución y con muchísima deuda técnica, y sin ningún tipo de documento de soporte: el código y punto.

Semanas de trabajo para comprender no solo lo que se había hecho por el momento, sino por qué, y sin posibilidad de preguntar a los autores, tan solo tú, el proyecto y mucha imaginación.

Retomar un trabajo hecho por otros suele ser en software una auténtica pesadilla que, en el mejor de los casos, puede llevar bastante tiempo, tan solo para comprender el proyecto suficientemente bien como para modificarlo y evolucionarlo.

Ahora bien, una vez que crees que lo has comprendido y puedes añadir cambios o hacer modificaciones, ¿de qué modo?, ¿con qué criterio en coherencia con lo que ya hay hecho?, ¿hay alguna razón desconocida por la que los antiguos desarrolladores hicieran algo concreto que tú habrías hecho de otro modo?

Lo que suele ocurrir es lo siguiente: llega un nuevo desarrollador que tiene que retomar un proyecto que no conoce y cuyos autores ya no están; se esfuerza en comprender lo que hay, cómo y por qué, pero, como digo, le falta mucha información y, si consigue echar a andar el proyecto finalmente, lo hará a su modo, seguramente añadiendo un nuevo estilo de diseño al anterior, modificando cosas sin saber por qué se hicieron de ese modo, modificando quizá el diseño original (o añadiendo uno nuevo), violando los criterios de la arquitectura (sin saberlo), aumentando así la falta de coherencia entre otros males.

Multiplica esto por varias manos diferentes y ya lo tenemos todo para un buen plato de código espagueti.

O sea, una situación bastante común en nuestro sector.

Me pregunto, ¿se puede evitar? Sobre todo, ¿se puede evitar sin necesidad de una documentación costosa y exhaustiva?

Para comprender bien un proyecto software, no solo es necesario que el código sea legible, con buena cobertura de pruebas, bien organizado, con clases o métodos sencillos, sin redundancias, limpio, sin deuda técnica, todas estas cosas que ya sabemos y de las que hablo mucho en mis libros, en concreto en El Libro Práctico del Programador Ágil.

Sobre todo en proyectos complejos y grandes, te pueden surgir preguntas del tipo siguiente:

  • ¿Cómo es la arquitectura del sistema?
  • ¿Qué criterio se ha usado para organizar los assets del proyecto? ¿Es coherente ese criterio en todo el proyecto?
  • ¿Cuál es la intención de diseño en esto y aquello?
  • ¿Cómo se crea un entorno de desarrollo y de testing?
  • ¿Qué flujo de trabajo es necesario para ejecutar todas las pruebas (si es que existen, claro)?
  • ¿Hay control de versiones? ¿Y cómo se sigue?
  • ¿Cómo se han resuelto ciertos requisitos no funcionales como la escalabilidad, restricciones, la seguridad, etc.?
  • ¿Dónde está localizada la configuración?
  • ¿Están las librerías actualizadas?
  • ¿Es compatible el proyecto con la actualización de las librerías de las que depende o hay alguna excepción?
  • ¿¡Por qué ese trozo de código está comentado!?
  • ¿Hay en algún sitio un diagrama de clases con su relación? Si lo hay, ¿estará actualizado?
  • ¿Por qué se usó esa librería en lugar de esa otra más popular? ¿Había alguna razón para ello?
  • ¿Qué criterios de usabilidad se siguió para la interfaz de usuario?
  • ¿Cómo se compila el proyecto o se pone en funcionamiento? ¿Qué dependencias hay?
  • Si el proyecto está dividido en capas o tiers, ¿dónde se localizan en el codebase?
  • ¿Cómo se escala el proyecto en un despliegue real?
  • Si existen bases de datos, ¿es su modelo suficiente para comprender su diseño?

Y un larguísimo etcétera. Si te fijas, muchas preguntas que para cualquier proyecto conocen bien los desarrolladores que trabajan en él desde el comienzo o desde hace mucho tiempo, pero para un recién llegado, esa información tan importante no existe salvo que alguien se la cuente. Claro, para el que lleva trabajando en ese proyecto un año, todo lo anterior es trivial, lo tiene todo en su cabeza a falta de documentación, sin darse cuenta de la cantidad de decisiones, asunciones y normas no escritas con las que se trabaja cada día... al margen de la misma naturaleza del código.

Esta dificultad suele aumentar cuando el proyecto lo han estado desarrollando las mismas personas durante años y no se han preocupado de simplificar y mucho menos de documentar nada, puesto que es tanto el conocimiento del mismo que tienen que no lo creen necesario, sin saber que esto precisamente puede ser un gran problema para quienes lo tengan que retomar en el futuro (y en ese futuro lejano, puede que sean ellos mismos quienes se encuentren la patata caliente después de haberlo olvidado casi todo).

Uno de mis mantras preferidos en software viene a decir algo así como que...

"Siempre tenemos que programar para que los demás comprendan lo que hemos hecho y por qué".

Pero añado algo más: no solo a nivel de código, sino también a nivel del proyecto en su globalidad.

Sin ir más lejos, recientemente he visto de primera mano la dificultad de asumir un proyecto de bajo nivel por personas nuevas en un equipo. Tanto es así y hasta tal punto puede llegar la dificultad, que en ocasiones es casi imposible asumirlo de modo que hasta se plantea la necesidad de volver a hacerlo desde cero, si es que la empresa se lo puede permitir, claro está.

Es cierto que el manifiesto ágil dice en uno de sus puntos: 

"Working software over comprehensive documentation (software que funciona sobre una documentación exhaustiva)"

Pero esto se ha interpretado mal: no quiere decir que no se documente absolutamente nada, sino que es más importante darle prioridad a que el software funciona que a crear documentación excesivamente exhaustiva, pero de ahí a documentación cero... Esto tenía mucho sentido en una época en donde esas metodologías pesadas te obligaban a presentar auténticos volúmenes con cientos de páginas con diagramas UML, etc. (que, por otra parte, nadie leía).

¿Hay entonces un camino intermedio entre no documentar nada y sobredocumentar?

¿Cómo documentar correctamente un proyecto software para que todo lo anterior no ocurra? Dicho de otro modo, ¿cómo se puede contar la historia completa sin caer en el error de documentar demasiado e innecesariamente y que no sea un coste excesivo en el proyecto?

 

Me encuentro a menudo con la siguiente situación: se desarrolla desde cero un nuevo proyecto, la funcionalidad a implementar está más o menos clara, se implementa, se entrega y... comienzan los problemas porque hay una gran cantidad de requisitos no funcionales que no se han tenido en cuenta (y que el cliente no ha indicado, claro está).

No solo estoy hablando de las necesidades de escalabilidad, rendimiento, mantenibilidad y todo eso que se denominan los conductores arquitecturales de cualquier producto software medianamente complejo. Desarrollar un nuevo proyecto implica también implementar todas las características necesarias para mantenerlo en producción, con funcionalidad específica para comprobar que todo está funcionando correctamente y con la trazabilidad necesaria para detectar dónde y cómo surgen los problemas. 

Todo lo anterior es necesario pero no suficiente.

¿Qué hay de toda esa funcionalidad al margen de la que el usuario final ve y usa? Me refiero a todo lo relacionado con la operación del sistema, algo de más relevancia aún cuando el proyecto es ciertamente complejo o tiene una gran cantidad de características.

Imagina una plataforma web como pueda ser Hub de Libros (el proyecto en el que más he trabajado en el último año): los usuarios se registran, los autores también, se pueden añadir reseñas y valoraciones de libros, los autores pueden indicar sus obras, crear su propia web de autor, los usuarios pueden seleccionar sus géneros preferidos, pueden escribir artículos, contratar servicios y pagarlos, crear estanterías con colecciones de libros y un larguísimo etcétera.

Toda esa funcionalidad, que es la que percibe un usuario que usa la plataforma, requiere de mucha más funcionalidad que éste no ve para operar el sistema. Esto es, hace falta una segunda aplicación totalmente independiente que permita actividades como: bloquear un usuario, restaurar su contraseña, aprobar valoraciones, comprobar los registros de log, gestionar todo lo relacionado con detalles internos de la plataforma (gestión de tareas, rendimiento de las bases de datos, etc.), obtención de métricas, gestionar características como "el autor del día", obtener todos los correos de los usuarios para crear una campaña de mailing, enviar un mensaje a un grupo de usuarios determinados, eliminar un libro que un autor ha publicado por error y muchas otras cosas por el estilo.

Cuando se publica un nuevo proyecto y muchas de esas actividades de operación se tienen que realizar tocando los registros de una base de datos, entonces es que no se ha planteado el desarrollo de la herramienta de operación necesaria.

Por resumirlo de algún modo: proyecto complejo = requisitos funcionales + herramientas de mantenimiento y operación.

El sistema va creciendo, en usuarios, en accesos y, afortunadamente, todo va bien y comienza su monetización: el cliente final (el dueño del proyecto) entonces requiere de cierto tipo de informes (¿cuántos usuarios hay?, ¿cuántos accesos al día?, etc.), sobre todo si se ha concebido el proyecto desde un punto de vista lean y hacen falta muchas métricas para decidir qué dirección darle con el tiempo según los resultados que se van obteniendo.

Más y más funcionalidad... de operación, claro.

Sin ir más lejos, en Hub de Libros se pueden contratar gigs para la ejecución de servicios de publicación (revisión, maquetación, creación de los archivos pdfs/epub de un nuevo libro, entre otros). Lógicamente, hace falta gestionar correctamente los gigs para que se realicen correctamente y que el usuario obtenga finalmente lo que ha contratado. Al usar Stripe para los pagos, hace falta comprobar también aspectos económicos como que las liquidaciones de esta pasarela son correctas, entre otras características tan solo relacionada con la contratación de los servicios.

Para ello, el sistema de operación debe implementar toda esa funcionalidad para su gestión: administrar la notificación de un nuevo gig contratado, comprobar su pago, enviarle mensajes asociados al gig para que el usuario los lea y muchas otras cuestiones que cualquier visitante de la web no ve, pero que está por detrás del funcionamiento de la plataforma y que además es imprescindible.

Una vez leí el comentario (en mi opinión algo tan cándido como ingenuo) de alguien que se preguntaba cómo es que Netflix tenía cientos de desarrolladores contratados puesto que la "web" o la aplicación no parecía demasiado compleja... en fin. Apuesto a que gran parte de todo ese equipo se dedica a implementar todo lo necesario para operar el sistema y dar soporte a necesidades del resto del negocio, algo mucho más allá de lo que el cliente final ve de la plataforma cuando se suscribe a ella y la usa.

En un sistema más o menos complejo, es difícil trasladarle al cliente toda esta funcionalidad en la que ni había pensado, más aún cuando las características y necesidades relacionadas con la opernación suelen ser mayores que las que se ofrecen a los usuarios finales.

La implementación de una aplicación de operación es necesaria y vital para el éxito de un proyecto, y no siempre se piensa en ella.

En concreto, en Hub de Libros existe un segundo portal de operación totalmente independiente y descoplado de el de usuarios (admin.hubdelibros.com) que permite realizar todo este tipo de operaciones y cuyo esfuerzo de desarrollo, lo puedo asegurar, ha sido mayor que el portal que ven los visitantes cuando acceden a la web.

Implementar toda esa funcionalidad de operación en segundas aplicaciones implica tener en cuenta muchos aspectos de seguridad, al tiempo que ese otro sistema (o conjunto de aplicaciones), tiene que tener acceso a los mismos repositorios que el sistema final, y, seguramente, a parte de la funcionalidad de los componentes que la constituyen. Y esto no es trivial, sobre todo si se quiere tener un sistema coherente sin que se provoque esa dispersión de aplicaciones implementadas de forma independiente, algo más costoso de mantener en el medio plazo.

Esta es una de las razones por las que implementé el framework de nombre Mantra (que, en estos momentos precisamente, estoy documentando para liberarlo en GitHub): un framework que tiene en cuenta desde su base, entre muchísimas otras características, que un mismo componente pueda implementar funcionalidad final y también de operación, sin romper la consistencia del sistema y facilitando su mantenimiento.

Recuerda: la funcionalidad de operación de un sistema es tan importante como los requisitos funcionales que el cliente exige.

 

Es cierto que estamos en la cultura de la prisa, en la que todo tiene que estar para antes de ayer, en la que los éxitos de otros se nos presentan como si hubiesen ocurrido de la noche a la mañana, generando la creencia de que nuestros objetivos más ambiciosos los podemos conseguir de una forma rápida.

Sin embargo, cuando analizamos el éxito aparentemente fulgurante de algún personaje de éxito, vemos que esa fachada mediática no es más que la punta minúscula de un iceberg que esconde en su base mucha perseverancia, fracasos, esfuerzo y tenacidad. Elon Musk, Bill Gates, Amacio Ortega, etc., por poner unos ejemplos extremos, todos comparten una historia parecida: muchas horas de trabajo, pequeños progresos y grandes resultados... después de años y hasta décadas.

Sin acaparar titulares, muchas otras personas alcanzan sus metas, que no necesariamente consisten únicamente en hacerse ricas: escribir un libro, perder peso, lanzar un proyecto emprendedor, caminar cada día, correr una maratón o plantar mil árboles.

Hace un tiempo escribí un artículo de título De qué Hablo cuando Hablo de Programar, que, por cierto, es uno de los más visitados de mi web en los últimos meses, y, por otra parte, hace poco he leído esta entrada en Medium con un título diría que hasta inquietante: Software development is a loser's game, aunque apuesto a que el autor tan solo quiere atraer a lectores con un título así.

En cualquier caso, ese artículo me ha empujado a reflexionar, una vez más, sobre qué distingue a un buen profesional de otro que no lo es tanto, en mi opinión, claro.

De modo que, si te consideras amateur o júnior, te animo a que sigas leyendo.

En los últimos años estamos viendo una avalancha de nuevas posibilidades de formación que atrae a muchísimas personas a aprender temas relacionados con el desarrollo de software, posiblemente porque hay mucho trabajo y es un sector en claro crecimiento.

MOOCs, bootcamps, diferentes itinerarios formativos (como la "FP" en mi país o módulos de ciclo superior), al margen de la formación más reglada de la universidad. Yo hice una carrera universitaria de cinco años hace más tiempo del que recuerdo y con el rimbombante título de Ingeniero Superior en Ingeniería Informática, tan solo para llegar a la conclusión años más tarde de que me sobraron al menos dos y de que lo más importante en mi desarrollo laboral y profesional lo he aprendido por mi cuenta y trabajando para empresas, esa es una verdad algo triste de aceptar, aunque este es otro debate.

Pero estamos en 2021, la pandemia ha acelerado la digitalización (por fin) de compañías, procesos y todo lo digitalizable, de modo que miles de personas, de un año para otro, comienzan a realizar trabajos de programación, de front-end, de back-end, etc., quizá con las tecnologías más de moda del momento (o aquellas en las que existe más empleabilidad) y que apuesto que en unos años habrán sido olvidadas.

Y todo esto, en mi opinión, es muy bueno, porque evidencia que nuestro sector (todo lo relacionado con IT) crece mucho más que otros. ¿Pero qué voy a objetar yo que precisamente que tengo libros y audiolibros publicados algunos de los cuales pueden ser de mucha utilidad para los recién llegados?

Sin embargo, no todo es tan bueno.

Esta avalancha de nuevos profesionales es aprovechada por compañías para tener un coste laboral menor creyendo que el trabajo que pueden realizar (productos software) va a ser el mismo que el de otros profesionales que llevan diez o más años de actividad, dinámica seguramente favorecida por clientes que no comprenden el esfuerzo en horas que hay destrás de cualquier desarrollo.

No me gustan los términos "programador júnior" ni "programador sénior", porque, ¿quién acredita que sea un "sénior" de verdad? Lamentablemente, tan solo los años trabajando no te avalan como mejor profesional, puesto que puedes haber estado haciendo lo mismo repetidamente ganando muy poca experiencia. Es más, lo que suelo comprobar, es que las personas, con honrosas excepciones, se acostumbran a hacer las cosas de la misma forma y de ahí no salen nunca.

De este modo, no me parece descabellado pensar que en nuestro sector, tan solo se pueden encontrar un 20% de profesionales aproximadamente. Esto no es un dato que yo haya calculado, tan solo es una intución mía con todo lo que he visto en mis experiencias en los últimos años. O por decirlo de otro modo, el porcentaje de profesionales de verdad en el desarrollo de software es muy inferior en relación al de juniors y amateurs.

Pero, ¿qué significa ser profesional realmente?

Este post va dirigido a todos aquellos que han llegado al desarrollo de software de un modo u otro, tanto si les gusta esta actividad como si no, o si tan solo lo ven como algo con salida en lo que trabajar como sea para pagar las facturas a final de mes. Insisto, que a mí todo esto me parece fenomenal y que lo que me anima a escribir este artículo es precisamente aportar algo de luz y aclarar que programar no es solo programar... porque lo que sí quiero destacar es qué es lo que yo considero que diferencia a un profesional desarrollador de software de uno amateur. Y no pasa nada por ser amateur, al contrario, si de verdad todo lo relacionado con el software te gusta y apasiona, entonces debes saber cómo crear proyectos con la misma calidad que el profesional en el que te quieres convertir.

La carrera y experiencia como desarrollador profesional de software no la obtienes en un año; como mucho, en ese tiempo, adquieres conocimientos teóricos, alguna práctica y poco más, algo que difícilmente te va a dar tiempo aplicar en el entorno real de una empresa en productos y proyectos reales.

Tan solo poner el dedo en la llaga, eres un programador amateur si...

  • No te gustan los estándares (esto es, en tu departamento vas a tu bola y haces las cosas como quieres sin seguir las guías o normas establecidas, si es que las hay...).
  • Crees que escribir software es crear una nueva funcionalidad y pensar que lo que has hecho "a la primera" es intocable y que nunca tiene que ser modificado.
  • Ignoras la naturaleza incremental (y de artesanía) del desarrollo de software.
  • Te cuesta trabajo volver atrás para mejorar o simplificar algo que ya hiciste (algo implícito en el punto anterior).
  • No te preocupas de que tu código sea legible para otros porque ignoras todo lo relacionado con las prácticas de código limpio, de refactorings y de patrones (antipatrones y code smells, ya que estamos...)
  • Pasas de la metodología (si es que existe en tu empresa, claro está), de modo que no sabes desglosar el trabajo en tareas e iteraciones, porque tampoco te suena todo eso de scrum, kanban, etc. Esto es, no sabes trabajar ordenadamente y bajo una planificación (o nadie te ha mostrado cómo).
  • Copias y pegas demasiado de Stack Overflow sin tratar de entender cómo funcionan esos snippets de código que te vienen bien.
  • No haces testing, ni siquiera pruebas unitarias, que es lo mínimo, quizá porque te han dicho que eso retrasa el desarrollo, cuando es justo al revés. ¿El resultado? Aplicaciones más monolíticas. (¿Mono qué?)
  • No comprendes que en ocasiones la falta de rendimiento de un sistema software se debe a un mal diseño.
  • No distingues entre un diseño monolítico y otro extensible, testeable y mantenible, porque no comprendes las ventajas de esto último.
  • Hablando de diseño, no has oído nunca el concepto de diseño emergente a medida que se incluye nueva funcionalidad.
  • Eso de documentar no va contigo, pero sí llenar el código de comentarios innecesarios porque es difícil de entender.
  • No usas bien la orientación a objetos, utilizando las clases como mero sumidero de funciones.
  • Eso de programar teniendo en cuenta todo momento los principios S.O.L.I.D. y otros, te resulta demasiado abstracto.
  • No te preocupas de limpiar la organización de los assets tu proyecto, piensas que eso es perder el tiempo.
  • Ignoras también que para crear una tubería de integración continua, necesariamente esto afecta al diseño del código.
  • No tienes cultura de equipo y suspendes en habilidades blandas (soft-skills).
  • Te cuesta eso de aprender nuevas cosas, con las que sabes crees que ya es suficiente.

Y paro porque me estoy amargando un poco :-), tampoco digo que haya que ser experto en todas esas áreas, pero sí conocer gran parte de ellas en cierta medida.

Por resumirlo de algún modo: no eres un programador porque conozcas hacer algunas cosas con el lenguaje x, aunque cada uno se autoetiqueta como quiere.

Tan solo para algunos de los puntos anteriores existe una bibliografía tan extensa que hay que digerir y poner en práctica durante muchísimo tiempo.

Lo que quiero decir es que, programar, al menos escribir código profesional en un entorno también profesional, para mí, es conocer todos los puntos anteriores (y muchos otros), y aplicarlos, claro está, algo que difícilmente se puede aprender tan solo en un par de años de formación.

Por último, otra creencia muy amateur: el de creer que todo lo anterior requiere más esfuerzo, retrasa el trabajo y hace que producir software sea más costoso...

Ahí lo dejo.

Sin ánimo de desalentar a nadie, sino más bien todo lo contrario, te animo a que si te has quedado en blanco con algunos de los puntos anteriores, comiences a documentarte y a seguir aprendiendo. Es más, la carrera de desarrollador profesional es un aprendizaje continuo en todas las áreas anteriores.

Puede que en la industria del desarrollo e ingeniería del software, algunos de los conceptos peor tratados (y peor entendidos), sean los de la arquitectura de un proyecto y el papel de un arquitecto software. En esos campos reina la confusión, las concepciones contrarias y una visión, me temo, poco práctica.

Es más, el mismo concepto de arquitectura software es dado a muchas interpretaciones (tantas como la misma evolución de cómo se afrontan proyectos durante las últimas décadas, me atrevería a decir), viniendo a crear aún más debate y falta de consenso claro la poca literatura que existe al respecto y que se centra más en patrones de arquitectura que en el papel real de un arquitecto dentro de una organización, cuando el trabajo de un reputado autor se contradice con el de otro igualmente alabado.

Para empeorarlo más, también se cree ingenuamente (formentado por la errónea cultura de muchas organizaciones), que ser arquitecto software supone un paso adelante en la escalera corporativa (más prestigio, mejor salario, etc.), de ahí el rechazo visceral de muchos desarrolladores a aceptar que venga alguien con un papel así cuando se entiende como una jerarquía tan pronto como perciben que su trabajo estará más o menos condicionado, definido y encorsetado desde la torre de marfil de un arquitecto.

Pero no tiene por qué ser así.

En El Libro Negro del Programador, dedico un capítulo ligero a este asunto sin profundizar (de título "El Mal Entendido Rol de Arquitecto de Software"), sin entrar demasiado en detalles, claro está, porque para mi mala suerte, una parte importante de mi experiencia con arquitectos ha sido más bien un desastre, y no lo digo con ánimo negativo o de devolver ningún agravio, cuando yo mismo he asumido ese papel en los últimos años en los productos que he dirigido y proyectos en los que he estado al frente.

Es un tema, digamos, delicado y controvertido, puesto que no existe una definición formal (te animo a que la busques, pronto te darás cuenta de que hay tantas como opiniones personales). Tanto es así, que en diferentes organizaciones nos podemos encontrar ese rol, pero con responsabilidades totalmente diferentes, cuando no ciertos equipos que se autodenominan ágiles creen que no hace falta cierta visión de arquitectura de los productos y proyectos que diseñan, o bien te encuentras al desarrollador al que han ascendido y por esa razón cree que sus decisiones van a ser mejores que la de sus antiguos compañeros de departamento (vamos, que se le ha subido el tema a la cabeza, quizá porque suena mejor decir que "eres arquitecto" a "soy programador").

Por otra parte, siento decir que se puede ser ágil, y al mismo tiempo, necesitar una arquitectura definida, y no es una contradicción (al menos en los términos que voy a indicar a continuación).

Para enredar más el asunto, antiguas prácticas sobre cómo a afrontaba el desarrollo de software hace unas décadas, siguen persistiendo en el inconsciente colectivo de los denominados arquitectos, me temo. Para muchos, todo lo que habla de arquitectura tiene que estar relacionado con diagramas UML tan espesos como inútiles que poco aclaran y estructuras en las que necesariamente todo el desarrollo debe encajar necesariamente (tan solo recuerdos de dinosaurio sobre cómo se afrontaba el desarrollo de software hace mucho tiempo pero que aún perduran), siendo más un obstáculo que un inconveniente. En otros equipos (lo digo porque me los he cruzado en algún momento de mi carrera profesional), sencillamente ignoran que exista tan siquiera ese concepto: el software de desarrolla de forma monolítica y se despliega como sea y punto (puff...), cuando no se confunde el diseño con la arquitectura, algo también muy habitual.

Puede que precisamente por todo lo anterior, no haya escrito hasta ahora demasiado sobre esto (ni me haya mojado en el asunto, para ser sincero), por suponer un concepto muy dado a la malinterpretación e incluso susceptible de acumular poder en ciertos entornos corporativos; no obstante, voy a hacer a continuación algunas aclaraciones que confío que ayuden un poco a tener una idea más clara de lo que para mí es un arquitecto software y que, afortunadamente, he visto confirmados en autores seguramente con más experiencia que yo (como Simon Brown y George Fairbanks).

El arquitecto software no es un puesto, sino un rol.

Llevo muchos años diriendo equipos de desarrollo, y siempre les digo lo mismo a mis compañeros: no soy el jefe de nadie, tan solo tengo el rol que me corresponde y mi trabajo consiste en ayudar a que el suyo lo hagan lo mejor posible. Del mismo modo, un arquitecto software no se puede parapetar tras un cargo, sino que asume un rol activo con determinadas funciones y responsabilidades. Tanto es así, que no es mejor profesional por tener ese rol que un desarrollador. Otra cosa es cómo se valore dentro de una compañía, pero en mi opinión lo único cuantificable económicamente debe ser la experiencia y el valor de lo que se aporta.

Un buen arquitecto no vive en su torre de marfil, sino que también programa.

El desarrollo de software no es como otras profesiones; no podemos seguir el símil de arquitecto de edificios / aparejador / albañil, etc., puesto que un arquitecto puede no haber tocado un ladrillo en su vida. No obstante, en software, un arquitecto debe haber desarrollado mucho software a lo largo de su carrera, y, además, en cuantos más proyectos diferentes se haya involucrado, mejor aún.

Es más, abandonar tu papel como desarrollador y dedicarse solo a la arquitectura, lo hace alejarse seguramente de ahí donde es bueno, de modo que para mí un buen arquitecto debe seguir implicado necesariamente a nivel de código en el proyecto.

El arquitecto conoce perfectamente el dominio.

El arquitecto debe conocer perfectamente lo que el cliente necesita o el universo del negocio que se va a modelar con el sistema que se pretende construir, ¿de qué modo si no se van a tomar las decisiones de arquitectura más relevantes?

Gestión de riesgos: no siempre hace falta una arquitectura.

La regla es sencilla: cuanto más grande va a ser un proyecto software y más largo su ciclo de vida (años), más necesario es la perspectiva de la arquitectura que se va a seguir.

Un proyecto pequeño no necesita el papel de un arquitecto.

Esto es, hay una relación directa entre la gestión del riesgo, tamaño del proyecto y su proyección a largo plazo.

Se confunde arquitectura de despliegue IT con la arquitectura de un producto/proyecto.

En ciertos entornos, he visto cómo se confundía una cosa con la otra. La arquitectura de un sistema software no es lo mismo que la arquitectura IT de despliegue final del sistema a desarrollar, pero están relacionados, obviamente. Si sabemos que el despliegue se va a realizar en una infraestructura IT cloud, o bien en un único servidor, la arquitectura propuesta puede cambiar.

Una mala arquitectura (o ausencia de ella) puede costar mucho dinero.

Lo he visto: un sistema que tenía que evolucionar pero cuyos desarrolladores trabajaban sin ese horizonte temporal y orden que pudiese proveer una arquitectura correcta para ese proyecto. El resultado era que esa falta de perspectiva (o inexperiencia) más muchos déficits de diseño, se cubría con muchos euros en hardware.

No hay conflicto entre lo ágil y definir una arquitectura al comienzo.

Así es, léelo de nuevo por si esta afirmación a estas alturas te choca. Como siempre me digo a mí mismo, la virtud está en el término medio.

Por alguna razón, quizá por el abuso en tiempos pasados de todo lo que huela a arquitectura, a los equipos que defienden lo ágil dogmáticamente, les parece una aberración plantearla, creyendo erróneamente que ésta emergerá. No se comprende que lo que emerge es, en el mejor caso, el diseño, y que la arquitectura va mucho más allá que definir cajas, trazar líneas e interacciones entre partes funcionales del proyecto, como veremos más adelante.

Algunos puntos del movimiento ágil se han malinterpretado, me temo; desde un punto de vista del concepto de arquitectura como visión y estructura de un sistema software, lo que emerge es el diseño de los componentes o piezas de software que lo componen, no ese marco más general. De nuevo, se pierde la perspectiva cuando uno cree que un proyecto de 10 KLOCs se debe gestionar y debe crecer igual que uno de 100 KLOCs.

La arquitectura consiste también en identificar riesgos.

Un arquitecto guía, documenta, propone, ayuda al resto del equipo, etc., pero también es capaz de identificar los riesgos que pueden presentar ciertas decisiones (elección de tecnología, licencias de terceros, puntos únicos de fallo, etc.).

No es imprescindible UML para documentar una arquitectura.

Nueva sesión en directo para GeeksHubs en su canal de YouTube. En esta ocasión, basado en uno de mis libros (The Coder Habits), hablé sobre los hábitos que un desarrollador de software debe incluir para mejorar su carrera profesional: hablamos sobre soft-skills, la regla 50/50, evitar el happy path, sobre cómo trabajar concentrado y muchos otros temas que mí me parecen muy esenciales para trabajar mejor, con menos esfuerzo, siendo más productivos y generando un código de más calidad.

Puedes ver la sesión aquí aunque lo tienes embebido un poco más abajo.

Ya sabes: si te sientes atascado en un carrera como programador, quizá lo que te falta es incorporar mejores hábitos.

Gracias al equipo de GeeksHubs por invitarme a esta nueva sesión.

Este es uno de los aspectos que menos me gustan de las diferentes actividades que están dentro de mis responsabilidades.

Estimar el esfuerzo que hace falta para generar un proyecto es un arte en sí mismo, y en software, me atrevería a decir que peor aún. A continuación voy a enumerar algunas de las razones e incertidumbres por las que yo prefiero trabajar en proyectos a muy largo plazo (que van a durar posiblemente años) o productos que, en cualquier caso, tienen un ciclo de vida más largo.

En esta otra entrada, hace un tiempo comenté las ventajas e inconvenientes de trabajar en productos o proyectos, entendiendo por proyectos aquellos encargos que comienzan en una fecha, terminan en otra y se cotizan con un presupuesto cerrado.

De entre mis responsabilidades, forma parte la necesidad de estimar las horas que hacen falta para desarrollar un nuevo proyecto comenzado desde cero o bien crear un nuevo evolutivo para uno ya en producción; en más ocasiones de las que me gustaría, te encuentras en la situación de necesitar una bola de cristal para acertar lo mejor posible ya que el cliente espera que puedas fijar el trabajo que te quiere encargar a un precio fijo y tú lo único que puedes estimar es aproximadamente las horas necesarias para su realización: si aciertas, perfecto, si cotizas menos horas de las finalmente necesarias, entonces se pierde dinero en el proyecto o baja su rentabilidad, si se acaba en menos horas de las utilizadas finalmente, ésta aumenta.

Suelo comentar con mis compañeros desarrolladores que llevarán el peso del trabajo su opinión al respecto, para así tener más información que contrastar.

Sé que existen técnicas de estimación que, en cualquier caso, tratan de minimizar el peor escenario posible: que se tarde mucho más tiempo del esperado en finalizar un proyecto, incurriendo así en costes extras no cotizados para el cliente y desviaciones económicas (esto es, que se pierde dinero, vaya).

No se trata de la experiencia que tengas desarrollando proyectos o dirigiéndolos, aún conociendo muy bien la tecnología a usar o el universo del negocio relacionado con los mismos e incluso conociendo con detalle las capacidades de los desarrolladores que estarán más implicados en el trabajo.

Inevitablemente, siempre hay ciertas incertidumbres que escapan a tu control y aspectos contra los que poco puedes hacer: el cliente no tiene claro ciertas funcionalidades de lo que necesita desarrollar (los va definiendo a medida que comienza a ver algo en marcha, algo también comprensible), el cliente no quiere esforzarse demasiado en consensuar un documento de especificación (y tú, puesto que quieres que te encargue el proyecto, tampoco eres demasiado pesado para afinar los detalles al máximo, o sea, que te ves un poco entre la espada y la pared), como el que compra una caja de material de cualquier tipo, el cliente quiere un precio cerrado y un tiempo de desarrollo, salvo que tengas mucha disciplina y una mano muy amable para conseguirlo, intentas minimizar las reuniones al máximo (en donde se van muchas horas), si en el mismo proyecto existen dependencias de terceros, éstas van a condicionar también el esfuerzo necesario, aunque al principio, cuando estás cotizando, no tienes ni idea de cuánto.

En pocas palabras, incertidumbre + incertidumbre + incertidumbre...

Esto es, muchas veces, vas en cierta medida a ciegas, lo que no deja de ser un contrasentido cuando el cliente quiere un precio cerrado y tú manejas una incertidumbre de más menos el 30% en el tiempo (por decir algo).

O peor aún, y algo típico en compañías grandes: esa estimación no la ha realizado nadie relacionado con el equipo técnico, sino alguien de otro departamento sin experiencia suficiente.

Y todo puede emperoar aún más porque para el cliente no eres el único proveedor candidato: mi experiencia me muestra (y ojalá que no sea la misma para todo el mundo), que en última instancia, variables como el compromiso, confianza y calidad, se supeditan irremediablemente al coste final, o lo que es lo mismo, te eligen por el precio/hora como única variable de selección.

Ya sabemos que la productividad de los desarrolladores depende de muchos factores, no únicamente del talento o experiencia que tenga cada uno. Sobre todo en pequeñas compañías, es habitual que un mismo desarrollador tenga que hacer frente al mismo tiempo a más de un proyecto o el día menos pensado hay que apagar algún fuego, añadiendo así una pérdida de tiempo al cambiar de contextos y terminar tareas de un proyecto u otro diferente (tiempo imposible de estimar).

Por otra parte, también sientes la presión añadida de que el cliente quede con un grado alto de satisfacción para que así recurra a ti o tu compañía en otra ocasión, algo en ocasiones difícil de gestionar con clientes difíciles.

Por si no te habías dado cuenta hasta ahora, existen clientes buenos malos (y no siempre los puedes elegir, me temo): los primeros se ajustan más a lo especificado y se esfuerzan mucho para permitir que tú trabajes lo mejor posible porque te ven parte de su equipo (están comprometidos con el proyecto), los segundos esperan que les leas la mente y se toman el derecho de cambiar especificaciones en cualquier momento haciendo que el equipo pierda horas al modificar lo ya realizado (tiempo no cotizado) o no comprenden que cuando se entrega un proyecto, tu parte termina ahí a no ser que exista un acuerdo para el mantenimiento del mismo. Estos últimos tan solo están implicados en el proyecto, y tú, como responsable del mismo, tienes que actuar en ocasiones como paraguas para evitar que el cliente cambie demasiadas cosas en reuniones con cierta tensión.

Es posible que te identifiques claramente con el escenario anterior: te piden que cotices y construyas un edificio pero no te dicen cuántas plantas se tiene, el tamaño de las ventanas te lo dicen después y ya veremos si lleva garage o no, y eso sí, la fecha de entrega es inamovible.

Siento si te estás agobiando al leer hasta aquí, pero todo lo anterior forma parte de la dinámica muy común de muchas compañías cuyo modelo de negocio consisten únicamente en contratar proyectos, a precio cerrado, con fecha de inicio y de fin, y que al tratar de manejar toda la incertidumbre anterior, al final de la cadena, se tiene a desarrolladores estresados, haciendo rápido lo que requiere de mucho más tiempo de dedicación y haciendo que las cosas en producción no se caigan en cualquier momento.

Es cierto que siempre existe cierta indeterminación cuando se especifica, de ahí que el enfoque ágil sea una herramienta maravillosa para reducir esa incertidumbre, pero la cuestión es que casi siempre, terminas infracotizando el esfuerzo real por uno u otro motivo.

Por muy bien que apliques las buenas prácticas de diseño, preparando tu proyecto software para el cambio, con una buena arquitectura y una calidad de código excelente, no se va a poder amortiguar toda esa incertidumbre fácilmente.

Siendo así las cosas, se explica perfectamente que en ocasiones se entreguen proyectos con un diseño deficiente y mucha deuda técnica, por falta del tiempo necesario para hacer iteraciones de mejora o exigencias de tiempo del cliente imposibles de abordar. Sencillamente, a veces es imposible cuadrar el círculo.

No siempre se tiene el margen suficiente para elegir los proyectos que tienes que desarrollar o dirigir, puesto que el negocio manda y hay que rentabilizarlo para pagar gastos, nóminas, etc.

Por todo esto, cuando me encuentro algún proyecto con graves deficiencias, nunca apunto a los desarrolladores que lo hayan realizado, sino más bien a las condiciones en las que lo han hecho. Y, sorpresa, casi siempre hay detrás una dinámica de trabajo en la que todo tiene que estar para antes de ayer, sueldos reducidos o proyectos infracotizados y mal especificados.

Para evitar el máximo esta dinámica desagradable, yo siempre trato de identificar a la persona coordinadora por parte del cliente y lo implico al máximo para que valide lo que se avanza en iteraciones pequeñas (de una a dos semanas), pero la experiencia también me muestra que los proyectos se cogen al principio con muchas ganas y poco a poco, ese esfuerzo recurrente de validación, ese coordinador termina viéndolo como una tarea pesada más (porque tiene otras que atender de su propia organización, claro).

¿Cuál es tu papel entonces como director de proyectos como es mi caso?

A mí no me cabe la menor duda: no soy ni el jefe y no me gustan las jerarquías ni tampoco me gusta ordenar como un general que manda a los soldados como carne de cañón. Yo tengo claro que mi papel asume toda la responsabilidad en el buen desarrollo del proyecto y su entrega con la suficiente calidad y que mi principal misión es favorecer las condiciones en las que los desarrolladores trabajan, lo que también implica que el cliente haga su papel (en ocasiones no es sencillo).

Como ya sabemos, un trabajo creativo requiere de ciertas condiciones para su realización, y éstas es responsabilidad de todos los miembros de una compañía para conseguirlas, también del cliente.

¿Y entonces? ¿Es posible escapar de la dinámica anterior de trabajar en proyectos infracotizados la mayoría de las veces (igual a presión)? ¿Cómo asegurar entonces la rentabilidad de cada proyecto?

En este primer post del año, quiero reflexionar acerca de una característica que llevo observando en los proyectos que implemento o dirijo desde hace más tiempo del que recuerdo, pero que quizá no se tenga demasiado en cuenta cuando estamos desarrollando software.

Si has tenido alguna vez la sensación de que se han implementado funcionalidades o características similares de un proyecto a otro, entonces puede que tengas la oportunidad de extraerlas de un modo útil para su reutilización. No en vano, no tiene sentido implementar un nuevo proyecto totalmente desde cero (sin usar ningún tipo de framework y librerías de terceros), reinventando la rueda una y otra vez, a no ser que se esté experimentando o aprendiendo.

Aunque pueda sonar algo extraño, el denostado y fatídico 2020 ha sido para mí un año muy productivo y creativo; al margen de todo lo relacionado con estos tiempos agitados que estamos viviendo con pandemia, confinamientos, derrumbe económico, etc., puedo decir que, afortunadamente, lancé varios proyectos que espero que vayan mejorando en los próximos meses; algunos de ellos se venían gestando desde el año anterior, otros, como mis libros y que también considero proyectos, fueron surgiendo a medida que acumulaba temas sobre los que hablar y que pudiese sintetizar en ese formato, sobre todo después de lanzar Hub de Libros.

Siempre he animado a todo el mundo a estar trabajando en proyectos personales y no solo dedicarse exclusivamente a aquellos por los que les pagan como empleados en sus compañías o los que te contratan como freelance: la riqueza que se obtiene de dedicar tiempo a ellos siempre me ha parecido que es incluso superior a la de realizar cursos, seminarios y leer libros.

Tanto es así, que, con el tiempo, comienza a diluirse la frontera de lo que es un proyecto personal y lo que no, ya que yo, a estas alturas, lo considero parte de mi trabajo profesional y me tomo tan en serio tanto lo uno como lo otro, independientemente de mi condición de freelance y consultor independiente. Es más, proyectos que inicialmente eran personales y realizados casi por juguetear un poco, terminaron convirtiéndose en productos comerciales y corporativos, como Picly.io.

En mi propio cocktail de autoformación continua, siempre tengo uno o dos libros que estoy leyendo (tanto técnicos como de muchos otros temas), podcasts que escucho regularmente y algún que otro curso, cuando no aplico ese principio que dice que aprendes lo que enseñas, de ahí que regularmente trabaje en un nuevo proyecto literario, y este nuevo año tengo ya varios proyectos en mente. Y, sin embargo, y como decía antes, lo que percibo como más enriquecedor es realizar un proyecto de verdad, porque, lógicamente, se aprende leyendo, escuchando podcasts y haciendo cursos, claro está, pero lo que has aprendido solo se consolida en conocimiento cuando lo has puesto en práctica. Obvio.

Leer esta bien y es necesario, qué duda cabe, pero aplicar lo aprendido es todavía mejor.

Sin embargo, hay una característica de realizar proyectos (tanto dentro de una empresa como personales) que me viene a animar todavía más para realizarlos y que requiere de trabajar con cierta actitud porque afecta incluso al modo en que los enfocas y diseñas.

En software, la reutilización es un concepto fundamental: nada peor que encontrar redundancias dentro de la misma solución. Eliminarlas es importante para mantenerla un poco más limpia y mejor estructurada; tanto es así, que en la metodología (una de tantas) que propongo para modernizar proyectos heredados en mi último libro (Legacy Code: Cómo modernizar en catorce pasos código heredado o proyectos software que han crecido demasiado rápido), le dedico un capítulo completo.

Hay diferentes niveles en esta reutilización de la que hablamos: puede afectar a simples funciones, clases de ayuda o componentes, pero también a grupos funcionales de mayor importancia dentro del proyecto.

Un paso más allá consiste en tener cierto nivel de abstracción y ver, concretar y diseñar dentro del mismo proyecto, otros de menor tamaño en los que se apoya.

En Hub de Libros, sin ir más lejos, se utiliza un potente gestor masivo de archivos que, poco a poco, fui extrayendo como un proyecto propio y que lo tengo publicado con el nombre de files-repo en GitHub; del mismo modo, el framework en el que se basa (Mantra), fue generando poco a poco una librería a modo de ORM que, también, extraje como proyecto independiente (se trata de RedEntities), y algunos más que aún no he publicado.

De este modo, un mismo proyecto ha generado diversos subproyectos independientes que, sin duda, reutilizaré a menudo y que quién sabe a dónde me conducirán.

La dificultad de extraer un subproyecto no radica en copiar y pegar sencillamente un conjunto de clases o componentes, sino en implementarlo de modo que no esté vinculado al proyecto padre de donde surgieron para así aportar una solución que se pueda integrar con naturalidad y no forzadamente en otros proyectos.

Con el tiempo, mantener esta actitud de detectar lo que puede ser un nuevo subproyecto, tiene ventajas inesperadas, ya que de ese modo, cuando te enfrentas a un nuevo desarrollo y que, como yo, tienes la responsabilidad de estimar el esfuerzo y hasta de determinar las bases de su diseño y arquitectura, piensas y lo enfocas ya no solo como un conjunto de componentes que se orquestarán de algún modo, sino que los abordas también con un conjunto de subproyectos que se desarrollarán independientemente y que serán integrados a su debido tiempo.

De este modo, animo a trabajar con esto en mente y a detectar qué partes homogéneas de una solución se pueden extraer como proyectos independientes.

Esto, además, puede ser hasta una estrategia comercial para obtener más productos de lo desarrollado en uno de ellos, algo que también he hecho en los últimos años tratando de rentabilizar librerías y desarrollos que se hicieron específicamente para ciertos clientes.

Conclusión: si pensamos en un nuevo desarrollo tratando de distinguir algunos subproyectos que se integran en él, lo podremos rentabilizar mejor y la reutilización de éstos nos permitirá avanzar más rápido en los siguientes proyectos y hasta plantear nuevos productos independientes.

Páginas

Mis libros en todas las tiendas:

Amazon
Google Play
Apple
Kobo
Barnes and Noble
Scribd
Smashwords
Payhip
Gumroad

Rafael Gómez Blanes Rafael Gómez Blanes
¿Hablamos?

 

Trabajo en...

Archivo

Mis novelas...