Más Allá del Código: 25 Reglas Esenciales para el Éxito en el Desarrollo de Software

 

En 2010, un gran mentor en sistemas me regaló dos libros que cambiaron por completo mi visión del cómputo. Gracias a ellos, adquirí los conocimientos necesarios para probarme como líder de proyectos. Aunque originalmente leí su sexta edición, hace unos meses adquirí la décima, y estudiar y comprender las actualizaciones fue crucial para adaptarme a los cambios en cómo se desarrolla software actualmente.

 

A pesar de que muchos de mis principios provienen del software libre, inspirado por el manifiesto de The Mentor, "La Catedral y el Bazar" de Eric Raymond, y los aportes de mexicanos como Miguel de Icaza y Federico Mena, nunca se debe perder de vista que las cosas deben hacerse bien o, simplemente, no hacerse. A lo largo de los años como PMO, he observado cómo los requerimientos a menudo se desvían por intereses personales y no por las verdaderas necesidades del proyecto.

 

Escribo esto en mi blog como una guía de referencia sobre cómo hacer las cosas correctamente. No importa si te consideras un "rebelde del software" como yo; al final, alguien más va a leer tu código, alguien más querrá conocer el estatus de tu proyecto. Por eso, todos estos pasos deben seguirse y ejecutarse correctamente, sin importar el tamaño o la naturaleza de la aplicación.

 

A continuación, desarrollo un punto a punto de los 25 temas clave para lograrlo.

 

 

Reseña del libro "Software Engineering. Global Edition"

 

 

El libro Software Engineering. Global Edition es un texto clásico en el ámbito de la ingeniería de software, que ha perdurado a lo largo del tiempo. Esta obra, en su décima edición, sigue siendo relevante, a pesar de que su autor, ahora retirado, ya no planea futuras revisiones. El contenido ha evolucionado a lo largo de los años, adaptándose a las nuevas tecnologías y tendencias, lo que lo mantiene actual y valioso.

 

El libro es extenso, compuesto por 25 capítulos, y aborda prácticamente todos los aspectos importantes de la ingeniería de software. A pesar de su longitud, está organizado en cuatro partes principales, cada una centrada en un conjunto específico de temas. La primera parte, que incluye los primeros nueve capítulos, ofrece una visión completa del campo, suficiente para tener una sólida base en ingeniería de software. Las demás partes profundizan en áreas más especializadas y avanzadas. A continuación, se detalla la estructura de la obra:

 

Parte 1: Introducción a la Ingeniería de Software

 

En esta primera sección, se presentan los conceptos fundamentales y se abordan las fases esenciales de un proyecto tradicional de software. Esta parte por sí sola podría considerarse un libro independiente y comprende los siguientes capítulos:

 

- Capítulo 1: Introducción

 

Introduce la necesidad de la ingeniería de software en el desarrollo profesional, define los conceptos clave, identifica diferentes tipos de sistemas y propone una ética de la profesión, todo ello complementado con casos prácticos que se utilizan a lo largo del libro.

- Capítulo 2: Proceso de Software

 

Explica los diferentes modelos de proceso, como el modelo en cascada, el incremental y el ágil, así como las actividades clave en cada uno de ellos. Termina con una discusión sobre la mejora de procesos.

- Capítulo 3: Desarrollo Ágil de Software

 

Se centra en el modelo ágil de manera genérica, sin vincularse a un marco específico. Detalla técnicas comunes de gestión de proyectos ágiles y aborda los desafíos del escalado en grandes proyectos.

- Capítulo 4: Ingeniería de Requisitos

 

Describe la toma de requisitos, diferenciando entre los funcionales y no funcionales, y aborda cada una de las etapas del proceso: especificación y validación.

- Capítulo 5: Modelado de Sistemas

 

Presenta los modelos más utilizados en el análisis y diseño de sistemas, con énfasis en UML, y concluye con un enfoque en el modelado basado en modelos (model-driven).

- Capítulo 6: Diseño de Arquitectura

Se discuten las decisiones arquitectónicas clave, las perspectivas de diseño y varios patrones comunes de arquitectura de software.

- Capítulo 7: Diseño e Implementación

Abarca el diseño detallado y la codificación, con un enfoque especial en el diseño orientado a objetos y patrones de diseño.

- Capítulo 8: Pruebas de Software

Este capítulo cubre la verificación y validación del software, pruebas unitarias, de componentes y de usuario, incluyendo el enfoque basado en pruebas (test-driven development).

- Capítulo 9: Evolución del Software

 

Cierra la primera parte discutiendo el mantenimiento y la evolución del software, prestando especial atención a los sistemas heredados (legacy systems).

 

Parte 2: Confiabilidad y Seguridad en Sistemas

 

Esta sección, alineada con los intereses del autor en confiabilidad, abarca los siguientes seis capítulos:

 

- Capítulo 10: Sistemas Confiables

Describe las características de la confiabilidad en sistemas sociotécnicos, donde se considera tanto la tecnología como los procesos y la organización.

- Capítulo 11: Ingeniería de Fiabilidad

Aborda la disponibilidad, tolerancia a fallos y la programación para fiabilidad.

- Capítulo 12: Ingeniería de Seguridad

 

Centrado en los sistemas críticos, cubre los requisitos de seguridad y el proceso de ingeniería de seguridad.

- Capítulo 13: Ingeniería de Seguridad contra Ataques

 

Aquí, el enfoque está en la protección frente a ataques, abarcando diseño y pruebas de seguridad.

- Capítulo 14: Ingeniería de Resiliencia

Discute la ciberseguridad y la resiliencia en sistemas sociotécnicos.

 

 

Parte 3: Ingeniería Avanzada de Software

 

En esta sección se abordan temas más especializados:

 

- Capítulo 15: Reutilización de Software

Ofrece una visión general de los diferentes niveles de reutilización de software, enfocándose en frameworks, líneas de productos y sistemas.

- Capítulo 16: Ingeniería de Software Basada en Componentes

 

Explica el concepto de componentes y cómo se integran en sistemas más grandes.

- Capítulo 17: Ingeniería de Software Distribuido

Detalla la interacción en sistemas distribuidos, patrones arquitecturales y el modelo cliente-servidor.

- Capítulo 18: Ingeniería de Software Orientada a Servicios

 

Se centra en las arquitecturas orientadas a servicios (SOA) y en los modelos basados en servicios web.

- Capítulo 19: Ingeniería de Sistemas

Amplía el enfoque para abarcar el sistema completo, no solo el software.

- Capítulo 20: Sistemas de Sistemas

 

Analiza sistemas complejos formados por la interacción de varios sistemas independientes.

- Capítulo 21: Ingeniería de Software en Tiempo Real

 

Se especializa en el diseño y análisis de sistemas de tiempo real.

 

 

Parte 4: Gestión del Software

 

Esta última parte se dedica a los aspectos no técnicos de la ingeniería de software:

- Capítulo 22: Gestión de Proyectos

Se enfoca en la gestión de riesgos, personas y trabajo en equipo.

- Capítulo 23: Planificación de Proyectos

Aborda la estimación de costes y planificación de proyectos, utilizando diagramas de Gantt y enfoques ágiles.

- Capítulo 24: Gestión de la Calidad

Se centra en la calidad del software, revisiones e inspecciones de código, y estándares como ISO 9001.

- Capítulo 25: Gestión de la Configuración

 

Discute la gestión de versiones, cambios y la creación de "releases".

 

 

En resumen, "Software Engineering. Global Edition" ofrece una visión exhaustiva y actualizada de la ingeniería de software, abordando tanto enfoques tradicionales como modernos, incluyendo agile y áreas especializadas como la ingeniería de software en tiempo real. Aunque se trata de un libro técnico y sobrio, sin adornos literarios o comerciales, es una excelente referencia de estudio y consulta para quienes buscan profundizar en este campo.

 

Pero dejo mi opinión y como aplicarlo en tus desarrollo

 

 

1. Introducción

 

Opinión: La mayoría de los desarrolladores subestima la necesidad de comprender realmente el porqué de la ingeniería de software. No es suficiente "codificar bien", debes comprender el impacto estratégico y organizacional de cada línea de código. Cada desarrollador debe alinearse con la visión general del proyecto, no solo con su pequeño trozo de código. Los equipos que ignoran esto están condenados a construir castillos de arena.

 

Mejora: La ética del desarrollo debe ser un pilar inquebrantable. No se trata solo de escribir código, sino de construir soluciones que soporten la presión de la realidad empresarial. Un arquitecto de software debe ser como un ingeniero civil, anticipando cada problema posible y diseñando sistemas con fundamento robusto.

 

2. Proceso de Software

 

Opinión: ¿Modelos en cascada? ¿Modelos ágiles? Todos estos procesos son herramientas, no dogmas religiosos. El verdadero CTO sabe cuándo seguir las reglas y cuándo romperlas. Las empresas fallan no porque elijan un mal modelo, sino porque lo siguen ciegamente sin adaptarlo a su entorno.

 

Mejora: Cada proyecto debe tener un proceso hecho a medida. Aprende todas las metodologías, luego haz una mezcla personalizada. Recuerda, el éxito no está en seguir un plan, sino en ajustarlo constantemente para alcanzar los resultados esperados.

 

 

3. Desarrollo Ágil

 

Opinión: El "ágil" no es una varita mágica para la eficiencia. Se ha convertido en una excusa para la mediocridad rápida. La verdadera agilidad es la capacidad de moverse rápido sin sacrificar la calidad, pero muchas empresas se esconden detrás de "iteraciones" para justificar entregas mal acabadas.

 

Mejora: No confundas agilidad con caos organizado. Los ciclos cortos y entregas constantes deben ser ejecutados con la misma atención a los detalles que un proyecto monolítico. La verdadera agilidad implica tener bases sólidas y modularidad en la arquitectura desde el día uno.

 

 

4. Ingeniería de Requisitos

 

Opinión: Aquí es donde fallan la mayoría de los proyectos. La toma de requisitos es tratada como un trámite, cuando en realidad es la base de todo lo que sigue. Si no se especifica bien desde el principio, el software será una ruina desde el momento en que se pone la primera línea de código.

 

Mejora: Involucra a todas las partes interesadas en la toma de requisitos y exige claridad absoluta. Si los usuarios no saben lo que quieren, es tu trabajo educarlos, no simplemente aceptar requerimientos vagos. Usa herramientas visuales, prototipos, y documentación precisa para cimentar el éxito del proyecto.

 

 

5.Modelado de Sistemas

 

Opinión: El modelado es tratado muchas veces como una carga, cuando en realidad debería ser la guía principal. Sin un buen modelo, estás construyendo a ciegas. La improvisación en software es la ruta más rápida hacia el desastre.

 

Mejora: Invierte en hacer modelos sólidos y claros. Utiliza diagramas de UML solo si realmente tienen sentido para tu equipo. Asegúrate de que todos entienden los flujos y las dependencias. No modeles por cumplir, modela para visualizar cada movimiento que hará el sistema bajo diferentes condiciones.

 

 

6. Diseño de Arquitectura

 

Opinión: Este es el esqueleto de tu sistema. Y sin embargo, muchos lo ignoran hasta que los problemas empiezan a aparecer. Sin una arquitectura sólida, lo único que estás haciendo es posponer el fracaso.

 

Mejora: Cada arquitectura debe prever tanto el crecimiento como el deterioro del sistema. Diseña pensando en la escalabilidad, pero también en la degradación. Los patrones arquitectónicos no son reglas universales, elige el adecuado para el contexto, y no tengas miedo de crear uno nuevo si es necesario.

 

7. Diseño e Implementación

 

Opinión: Este es el punto donde la albañilería de software brilla. La mayoría de los desarrolladores piensa que simplemente traducir un diseño a código es suficiente. Error. Aquí es donde el código debe tener el mismo cuidado que una pieza de ingeniería de precisión.

 

Mejora: Un verdadero ingeniero de software escribe código que no solo cumple con los requisitos, sino que es flexible, mantenible y entendible. La implementación no es solo traducir, es construir un mecanismo vivo que debe ser capaz de resistir el uso en la práctica.

 

---

 

8. Pruebas de Software

 

Opinión: Muchos creen que las pruebas son una fase que viene al final. Esta mentalidad es una invitación a la catástrofe. Si no pruebas constantemente, estás acumulando errores que estallarán en el peor momento posible.

 

Mejora: Implementa pruebas desde el principio y en cada etapa. El enfoque de "Test-Driven Development" (TDD) no es solo una técnica, es una mentalidad. Cada funcionalidad nueva debe venir acompañada de sus pruebas. La cobertura de pruebas debe ser exhaustiva y automatizada siempre que sea posible.

 

 

9. Evolución del Software

 

Opinión: El software que no evoluciona está muerto. Pero la evolución no debe ser un parcheado constante. La mayoría de los desarrolladores creen que el mantenimiento es solo arreglar lo que está roto. No. Es preparar el sistema para lo que vendrá.

 

Mejora: Diseña para el cambio desde el principio. Los sistemas deben ser modulares y preparados para adaptarse. Cada cambio debe estar acompañado de pruebas y refactorización, para asegurar que el software no se degrade con el tiempo.

 

10. Sistemas Confiables

 

Opinión: La confiabilidad es el rasgo más subestimado en los sistemas modernos. Muchas veces, se sacrifica por entregar a tiempo o reducir costos. Pero la realidad es que si tu sistema no es confiable, no sirve.

 

Mejora: La confiabilidad no es negociable. Implementa redundancia, monitoreo continuo y mecanismos de recuperación ante fallos desde el principio. Un sistema confiable es aquel que puede fallar y recuperarse sin que el usuario final se dé cuenta.

 

 

11. Ingeniería de Fiabilidad

 

Opinión: Aquí entra en juego la verdadera calidad. Muchos desarrolladores confunden un sistema funcional con un sistema confiable. Son dos cosas diferentes. La fiabilidad es la capacidad del sistema para operar correctamente bajo condiciones adversas.

 

Mejora: Implementa estrategias para la detección temprana de fallos y el diseño a prueba de errores. La medición de la fiabilidad debe ser continua, utilizando herramientas de monitoreo que evalúen tanto la disponibilidad como la respuesta bajo carga.

 

 

12. Ingeniería de Seguridad

 

Opinión: La seguridad a menudo es vista como un complemento, algo que se "añade después". Este error es lo que convierte a los sistemas en trampas explosivas esperando ser detonadas por cualquier hacker medianamente competente. Los desarrolladores que no piensan en seguridad desde el principio están construyendo un castillo de naipes.

 

Mejora: La seguridad debe estar integrada en cada fase del proyecto. Desde los requisitos hasta la implementación, cada decisión debe tener en cuenta las vulnerabilidades potenciales. No se trata solo de escribir código seguro, sino de crear una cultura de seguridad en todo el equipo de desarrollo.

 

 

13. Ingeniería de Protección (Security Engineering)

 

Opinión: Los sistemas que no están protegidos contra ataques cibernéticos son simplemente irrelevantes. No importa cuán elegante sea tu código, cuán perfecta sea tu arquitectura; si alguien puede destruirlo con un ataque DDoS o una inyección de SQL, has fallado. La seguridad no es opcional.

 

Mejora: Implementa auditorías de seguridad constantes y pruebas de penetración. Los sistemas deben estar diseñados para defenderse proactivamente, no solo reaccionar ante las amenazas. Adopta un enfoque de "defensa en profundidad", donde cada capa del sistema esté protegida por múltiples mecanismos de seguridad.

 

 

14. Ingeniería de Resiliencia

 

Opinión: ¿Resiliencia? Es un término que los ingenieros a menudo desprecian, pero es la diferencia entre un sistema robusto y uno que colapsa bajo presión. La mayoría de los desarrolladores subestima la capacidad de un sistema para recuperarse ante fallos. La resiliencia no es solo un lujo; es una necesidad.

 

Mejora: Diseña tus sistemas para fallar, pero asegúrate de que puedan recuperarse sin intervención humana. La capacidad de un sistema para restaurarse automáticamente es un estándar, no una aspiración. Los mecanismos de rollback, los sistemas de monitoreo en tiempo real, y la redundancia son clave para garantizar la resiliencia.

 

 

15. Reutilización de Software

 

Opinión: La reutilización de software es, en teoría, una gran idea. En la práctica, rara vez se ejecuta bien. Muchos desarrolladores simplemente reciclan código mal escrito o desactualizado. Reutilizar basura no te convierte en eficiente, te convierte en un destructor de futuros proyectos.

 

Mejora: Reutiliza solo lo que tiene valor real. Implementa estándares rigurosos para los componentes reutilizables y asegúrate de que cada pieza de software que se reutilice haya sido completamente validada y documentada. Un componente reutilizable debe ser flexible y mantenible, no un legado de problemas futuros.

 

 

16. Ingeniería de Software Basada en Componentes

 

Opinión: En un mundo ideal, la ingeniería basada en componentes debería ser el Santo Grial del desarrollo. Pero en la realidad, los componentes son mal definidos, mal documentados, y mal implementados. Los ingenieros que no entienden el diseño modular están condenados a construir sistemas frágiles e inmanejables.

 

Mejora: La clave aquí es una definición precisa y rigurosa de los componentes. Un componente debe ser independiente, fácil de integrar, y completamente testeado. Las interfaces entre componentes deben ser claras y simples. La composición de sistemas basados en componentes debe parecerse más a ensamblar un motor de precisión que a juntar piezas al azar.

 

 

17. Ingeniería de Software Distribuido

 

Opinión: Muchos ingenieros creen que distribuir un sistema es simplemente dividir tareas entre servidores. Esa superficialidad es lo que causa caídas catastróficas. Un sistema distribuido mal diseñado es una receta para el caos.

 

Mejora: Diseña sistemas distribuidos con una atención extrema a la comunicación, la latencia y la consistencia de datos. No asumas que la red es confiable; siempre habrá fallos de red, tiempos de espera y paquetes perdidos. Implementa patrones como el de CQRS (Command Query Responsibility Segregation) y asegúrate de que la arquitectura distribuida sea capaz de resistir fallos parciales sin colapsar el sistema completo.

 

 

18. Ingeniería de Software Orientada a Servicios

 

Opinión: Las arquitecturas orientadas a servicios han sido malentendidas y mal utilizadas. No se trata solo de dividir funciones en servicios independientes. Se trata de diseñar servicios autónomos y escalables que puedan evolucionar por separado sin romper todo el sistema.

 

Mejora: Cada servicio debe estar completamente desacoplado y tener una API bien definida. La infraestructura debe permitir una orquestación clara y eficiente entre servicios. Además, ten en cuenta que el diseño de servicios no termina con la implementación; es necesario monitorear y mejorar continuamente cada servicio en producción.

 

 

19. Ingeniería de Sistemas

 

Opinión: El error común en la ingeniería de sistemas es que los desarrolladores tienden a enfocarse solo en el software, ignorando el entorno en el que operará. Un sistema mal integrado en su contexto técnico y social está destinado a fallar.

 

Mejora: No solo debes diseñar software; debes diseñar todo el sistema. Esto incluye hardware, redes, e incluso los procesos humanos que interactúan con el sistema. Adopta una visión sociotécnica, donde el software es solo una parte de un todo mayor. La verdadera ingeniería de sistemas no se limita a bits y bytes.

 

20. Sistemas de Sistemas

 

Opinión: Combinar sistemas independientes en uno mayor es un arte que muchos desarrolladores subestiman. Sin un plan claro, estos sistemas se convierten en monstruos incontrolables. El concepto de "sistemas de sistemas" debe ser tratado con respeto y rigurosidad.

 

Mejora: Al diseñar sistemas de sistemas, debes adoptar una visión holística. Los componentes individuales deben comunicarse y cooperar sin problemas. Desarrolla patrones arquitecturales que gestionen la complejidad sin sacrificar la flexibilidad. Recuerda que la interoperabilidad es clave, pero debe lograrse sin comprometer la robustez.

 

 

21. Ingeniería de Software en Tiempo Real

 

Opinión: El desarrollo de software en tiempo real es, sin duda, uno de los campos más desafiantes. El problema es que muchos desarrolladores ignoran las verdaderas restricciones temporales y asumen que un sistema puede funcionar "lo suficientemente rápido". Esto es un error fatal.

 

Mejora: Diseña siempre teniendo en mente las limitaciones de tiempo real. Prioriza el análisis de tiempos desde el principio, y asegúrate de que cada componente crítico cumple con las restricciones temporales establecidas. La simulación y pruebas de carga en entornos reales son obligatorias, no opcionales.

 

 

22. Gestión de Proyectos

 

Opinión: La mayoría de los gestores de proyectos creen que su trabajo es simplemente mover tareas en un tablero Kanban. Están completamente equivocados. La verdadera gestión de proyectos implica una visión estratégica y una capacidad implacable para eliminar obstáculos.

 

Mejora: Un buen gestor de proyectos debe entender tanto el negocio como el desarrollo. Debe saber cómo priorizar características críticas, cómo gestionar el riesgo y, sobre todo, cómo mantener al equipo enfocado y motivado. No se trata de mover post-its; se trata de liderar con determinación.

 

 

23. Planificación de Proyectos

 

Opinión: Planificar no es hacer una lista de deseos. Si tu planificación de proyectos no tiene bases en la realidad del desarrollo, estás construyendo sobre humo. Muchos proyectos fallan porque se planifican sin entender las verdaderas capacidades y limitaciones de los equipos.

 

Mejora: La planificación debe ser precisa y ajustada al contexto del equipo y del proyecto. Usa métricas reales de rendimiento y establece objetivos alcanzables. Los diagramas de Gantt pueden ser útiles, pero no te encierres en herramientas. La flexibilidad, junto con un análisis constante, es la clave para un buen plan.

 

 

24. Gestión de Calidad

 

Opinión: La calidad es a menudo tratada como una etapa final, cuando en realidad debería ser la base de todo el proceso de desarrollo. Si no se prioriza desde el principio, terminarás con un producto defectuoso que requerirá parches constantes.

 

Mejora: La gestión de calidad debe ser continua y proactiva. Implementa revisiones de código regulares, pruebas automatizadas, y auditorías constantes. No esperes a que los problemas aparezcan en producción. La calidad es el resultado de un proceso riguroso y constante, no de una serie de "ajustes" de última hora.

 

 

25. Gestión de la Configuración

 

Opinión: La gestión de la configuración es subestimada hasta que un error en la versión despliega código incorrecto o incompatible en producción. En ese momento, los equipos se dan cuenta de que la falta de control en las versiones es un suicidio.

 

Mejora: Implementa un sistema de gestión de versiones sólido desde el principio. La automatización del despliegue y las pruebas son esenciales para evitar errores humanos. Gestiona cuidadosamente las ramas y asegúrate

 

de que cada cambio esté documentado y validado antes de ser implementado.

 

Si llegaste hasta aquí, te lo agradezco profundamente. Pero, más aún, te lo agradecerán los ingenieros que en el futuro leerán tu código y trabajarán en tu proyecto. Gracias a tu esfuerzo, podrás convertir a un albañil del software en un profesional capaz de mantener y mejorar el código por años, décadas, o incluso siglos. Recuerda esto: nosotros nos iremos, pero el código permanece. Al final, no importa quién seas tú, lo que importa es la calidad y longevidad de tu código, porque alguien más tendrá que mantenerlo. Haz que valga la pena.

La Catedral y el Bazar" para Equipos de Software Privativo: Guía para los que Aún Tienen Dueños

 

Ah, La Catedral y el Bazar, ese texto sagrado de la rebelión del código abierto. Escrito por Eric S. Raymond, un verdadero hereje del control corporativo, donde se predica que el desarrollo de software es un acto de creación comunitaria, no de imposición jerárquica. Pero aquí estamos en 2024, donde muchos de ustedes aún prefieren vivir bajo la pesada bóveda de la catedral corporativa, persiguiendo metas que ni siquiera entienden. Y, para variar, creen que están innovando. 

 

Vamos a aclarar algo antes de que te quemes con el incienso de tu propia pomposidad. En este nuevo tecnofeudalismo, donde las empresas de software privativo cierran filas alrededor de sus tesoros de código fuente, hay algo que se ha perdido: el verdadero hacker spirit.

 

La Catedral: La Ilusión del Control

 

En el universo de las empresas privativas, la catedral es una metáfora muy literal. Lo tuyo es el control absoluto, el poder sobre cada línea de código, cada decisión, y la propiedad sobre todo lo que tocan tus desarrolladores encadenados. Suena seguro, ¿no? Como si el único camino a la calidad fuera pisotear cualquier chispa de creatividad. Pero, claro, aquí estás, sentado en tu trono, viendo cómo la innovación se escapa por los resquicios de esa catedral que tú creías sólida.

 

Sigue así. Seguro que el próximo comité aprobará algo nuevo. O no. Total, para qué cuestionarse cuando el control es lo único que importa.

 

El Bazar: Aquí es Donde Nace la Revolución (Y Lo Que Nunca Entenderás)

 

Mientras tanto, en el bazar, las ideas fluyen. Pero claro, para ti el bazar es un caos insoportable. Descentralización, colaboración, miles de voces creando algo juntos. Suena aterrador, ¿verdad? Que haya gente dispuesta a compartir sus ideas y recibir críticas en lugar de esconderse detrás de la burocracia corporativa debe ser incomprensible.

 

Aquí es donde fallas: el bazar no es caos, es evolución. Lo que no comprendes es que para avanzar, incluso tu rígido y estructurado castillo de software privativo necesita una pizca de anarquía. Hackers trabajando en comunidad dentro de tus filas, buscando soluciones y mejorando el sistema desde dentro. Pero claro, para ti, eso solo suena como pérdida de control.

 

2024: La Fusión de la Catedral y el Bazar en un Mundo que Exige Velocidad

 

¿Te duele un poco el ego? No te preocupes, no eres el primero. En 2024, te enfrentas a un dilema: ¿cómo mantienes la catedral de tu código privativo sin sofocar a tu equipo, que busca la agilidad de un bazar? Te diré cómo: deja que tus desarrolladores respiren.

 

Haz hackathons internos, permite iteraciones rápidas sin necesidad de una misa para cada decisión, introduce *feedback* constante y **suéltales la rienda**. Si sigues operando como si tus sistemas fueran piedra inamovible, solo estarás observando tu propia decadencia.

 

Pero tranquilo, no te estoy diciendo que abras las puertas y regales todo el código (sabemos que eso nunca sucederá). Lo que te estoy diciendo es que puedes, y deberías, adoptar lo mejor del bazar. Mientras sigues vendiendo software, puedes adoptar metodologías ágiles, fomentar colaboraciones internas como si fueran mini-bazares, y aplicar transparencia para que, al menos, tu equipo no se sienta prisionero en tu catedral.

 

¿Y El Futuro?

 

Sencillo: o te adaptas o te quedas atrapado en las piedras de tu catedral. El bazar seguirá evolucionando, lo quieras o no. El software privativo puede sobrevivir si aprende a bailar con la creatividad colectiva, aunque no estés listo para dejar el trono.

 

Pero si quieres seguir rascándote la cabeza preguntándote por qué no puedes ser como esas empresas que tienen innovación brotando de cada esquina, te recomiendo algo: busca el libro original de Raymond, La Catedral y el Bazar, y léelo. Quizá, solo quizá, te des cuenta de que, aunque tu modelo de negocio no cambie, el alma del desarrollo debería.

 

Firmado,  

Mitanef

Para los que aún creen que la tecnología debe servir al hombre y no al amo. 

(Si no sabes quién es Eric S. Raymond, te toca hacer los deberes).

 

De regreso al estudio

 No se había escrito en este sitio desde el 2007....

Parte del crecer es tener ocupaciones, no había tomado una pausa hasta esta pandemia...

en el 2020 inicio a producir de lleno en Ableton y lanzo mis primeras maquetas que suelen transformase en tracks.

pero bueno ahora tengo unos nuevos objetivo si bien todo siempre gira entorno al software libre

tengo un ubuntu 24. 

vscode

VENTAJAS DE LINUX

Hace tiempo me preguntaban que ventajas tiene linux
Ventajas de Linux

Linux es básicamente un duplicado de UNIX, lo que significa que incorpora muchas de las ventajas de este importante sistema operativo.

En Linux pueden correr varios procesos a la vez de forma ininterrumpida como un servidor de red al tiempo que un procesador de textos, una animación, copia de archivos o revisar el correo electrónico.

Seguridad porque es un sistema operacional diseñado con la idea de Cliente - Servidor con permisos de acceso y ejecución a cada usuario. Esto quiere decir que varios usuarios pueden utilizar una misma maquina al tiempo sin interferir en cada proceso.

Linux es software libre, casi gratuito. Linux es popular entre programadores y desarrolladores e implica un espíritu de colaboración.

Linux integra una implementación completa de los diferentes protocolos y estándares de red, con los que se puede conectar fácilmente a Internet y acceder a todo tipo de información disponible.

Su filosofía y sus programas están dictados por el movimiento ``Open Source'' que ha venido crecido en los últimos años y ha adquirido el suficiente fortaleza para hacer frente a los gigantes de la industria del software.

Linux puede ser utilizado como una estación personal pero también como un potente servidor de red.

Linux incorpora una gama de sistemas de interfaz gráfica (ventanas) de igual o mejor calidad que otras ofrecidas en muchos paquetes comerciales.

Posee el apoyo de miles de programadores a nivel mundial.

El paquete incluye el código fuente, lo que permite modificarlo de acuerdo a las necesidades del usuario.

Utiliza varios formatos de archivo que son compatibles con casi todos los sistemas operacionales utilizados en la actualidad.

Las 3 ventajas fundamentales de Linux que juntas le dan una gran consideración (sintesis de lo anterior):
Linux es muy robusto, estable y rápido: Ideal para servidores y aplicaciones distribuidas. A esto se añade que puede funcionar en máquinas humildes: Linux puede correr servicios en un x86 a 200 MHz con calidad
Linux es libre: Esto implica no sólo la gratuidad del software, sino también que Linux es modificable y que Linux tiene una gran cantidad de aplicaciones libres en Internet. Todo ello arropado por la inmensa documentación de Linux que puede encontrarse en la Red
Linux ya no está restringido a personas con grandes conocimientos de informática: Los desarrolladores de Linux han hecho un gran esfuerzo por dotar al sistema de asistentes de configuración y ayuda, además de un sistema gráfico muy potente.Distribuciones Linux como Red Hat/Fedora tienen aplicaciones de configuración similares a las de Windows
Razones para usar Linux:
Linux es uno de los sistemas operativos más robustos, estables y rápidos
Es austero: Linux funciona hasta en un 386
El manejo de la memoria de Linux evita que los errores de las aplicaciones detengan el núcleo de Linux.

Linux es multitarea y multiusuario: Esta característica imprescindible está en Unix desde su concepción pero le llevó a Microsoft más de 20 años ofrecerlo en su sistema operativo de consumo.

Linux soporta gran variedad de entornos gráficos (KDE, GNOME, XFCE...)
Hay miles de programas libres para Linux, adaptados a muy diversos propósitos y disponibles en internet para usarlos con GNU/Linux.

Linux permite navegar por Internet y conectar máquinas en red de manera natural (los protocolos TCP/IP ó PPP por ejemplo, están incluidos como un módulo del básico del núcleo)
Casi cualquier aplicación Unix puede usarse bajo Linux .

Para Linux existe gran cantidad de documentación libre, aunque no siempre está traducida
Las libertades de copia y modificación permiten usar GNU/Linux para facilitar servicios sin depender de terceros