Las 5 cosas que llevan a la chingada un proyecto de software

From: quickmeme.com
From: quickmeme.com

Después de varios años en el negocio creo que tengo la licencia de opinar desde el punto de vista de un desarrollador de software el tema sobre que lleva a la perdición a un proyecto de software y por ende el producto final que se le entrega a un cliente incauto (O no). Y todo esto despues de leer el libro negro del programador, que aunque concuerdo con todas sus observaciones quiero hacer enfasis en las que hicieron mayor eco en mi.

  1. Hacer líder al desarrollador Senior: La gente encargada de la gestión de proyectos a veces es bien ocurrente y cree que la evolución natural de un desarrollador Sr (El fulano que sabe mas) es convertirse en el líder absoluto de un grupo de developers resentidos que es posible que le hagan la vida imposible al nuevo “jefe”. Ademas, no por ser un buen programador esto quiere decir que sea bueno en el manejo de personal, métricas y buenas practicas para mejorar el rendimiento del equipo.
  2. Falta de comprensión del líder con sus subordinados: Mi favorito, cuando explicas porque no se puede hacer algo en el tiempo estimado y la respuesta es: “Pero lo necesitamos para el Viernes” y eso es mañana. Eso produce mal software, porque al desarrollador no le quedara otra mas que tirar código como loco sin pensar en las consecuencias a mediano o corto plazo. Es decir, estas sumando tiempo al futuro si es que el proyecto logra salir avante a mas de un caso similar.
  3. Pensar que el software es como una linea de ensamblaje: Es muy común cometer este pecado, ya que los managers como dije son bien ocurrentes. Cuando los tiempos son cortos, el personal poco capacitado o saturado de actividades siempre saldrá a la palestra la idea de: “Contrata mas gente”. Esto solo pasa en los proyecto mal gestionados, no se alarmen, pero puede ser un buen indicador para salir huyendo.
  4. No colocar a la gente de acuerdo a sus competencias: Todos tenemos habildades y fortalezas especificas, aunque todos seamos desarrolladores de software. Sin embargo en ocasiones esto no es entendido por los lideres, ya sean tecnicos o gerenciales, lo cual da como resultado un proyecto destinado a la perdicion.  En software esto se traduce a colocar a novatos/becarios en tareas donde se necesita alguien con cierto nivel de experiencia solo por ahorrar presupuesto, esto a la larga generara errores graves de costes enormes y la gente que medianamente sabia que hizo quizas ya haya sido dada de baja por los tipicos recortes a medida que el proyecto “madura”. Los desarrolladores tenemos parte de la culpa cuando engordamos nuestros CV con habilidades que no tenemos o que apenas y hemos rozado la punta de las mismas, pero que a la hora de estar frente al reclutador las presentamos como de nuestro total dominio.
  5. “Managers” de $3 pesos: Cuando los cuatro puntos se juntan lo mas seguro es que la persona que esta la cabeza sea un completo desastre. Alguna vez un amigo me conto la teoria de la cubeta de popo (seria excelente material de otro post), que basicamente es no saber resolver los problemas a tiempo (la mierda) y en su lugar juntarla en una cubeta (metaforicamente) hasta el punto que se desbordara y pasara a las cubetas de los niveles inferiores de la organizacion, asi hasta alcanzar a los desarrolladores que quedaran hundidos hasta el cuello con los errores de los niveles gerenciales. Esto pues no es mas que un resumen de lo que sucede dia a dia en algunos proyectos donde las cabezas toman malas decisiones por inexperiencia o miedo a presentar numeros negativos. La mayoria de estos casos se caracterizan por lideres cuya actitud es pensar que estando mas horas en la oficina se lograra cumplir con las metas y que nunca piensan a mediano o largo plazo: Al final lo que les importa es tener numeros positivos y no la calidad del producto.

Por supuesto que hay mas, pero sirva esto como un punto de vista de lo que te puede estar pasando a ti ahora mismo. Y vamos, un recordatorio para mi, ya que es facil caer en estos circulos infernales pues las pistas se encuentran una vez que estas dentro del proyecto de forma activa.

Mi consejo, y el de este libro para un ambiente asi es: Sal de ahi rapidamente.

From: dragonball.wikia.com
From: dragonball.wikia.com

Netbeans es el IDE para los tontos

Mi verdad, opinion personal

Yo uso Netbeans, pero no entiendo porque ese afan por menospreciarlos de algunos Java developer o chicos cool.

nb-darcula
https://github.com/Revivius/nb-darcula

Mi historia con Netbeans comenzo en la universisad, pero no para hacer “hola mundo” en Java, mas bien fue para aprender, de la forma incorrecta, PHP. Y las opciones que tenia alla afuera eran eclipse, Dreamweaver (Si, esa madre) y otros simples editores de texto de los 90’s cuyo nombre la verdad no recuerdo.

Al pasar los años, ya entrando en mi vida profesional, eclipse tenia una hegemonía marcada en el mundo de Java pero yo continuaba haciendo mis proyectos personales con PHP en Netbeans y la verdad le he tomado carino al IDE y poco conflictivo al tener una lista muy limitada de plugins comparandolo con eclipse por ejemplo. Pero para proyectos de Java es una buena alternativa tambien y una comunidad dispuesta a ayudar a pesar de que sea un producto de Oracle al cual se le mantiene vivo de una forma no agradable.

Por que Netbeans?

  1. Una herramienta comunitaria: Solo se necesita un JDK/JRE, descargarlo e instalarlo para comenzar a trabajar con un robusto entorno de desarrollo que permite trabajar con proyectos pequeños o de mediana envergadura. Al igual que eclipse, no hay que pagar regalias por el uso de esta herramienta y es un recurso ideal para escuelas o empresas. Ademas, a pesar de un notorio estancamiento en los ultimos años, continua su mejoramiento constante apoyado por una comunidad basado en contribuciones: https://netbeans.org/community/contribute/code.html.
  2. Todo en una misma caja: Cuando uno usa Netbeans, realmente no se dedica a instalar plugins adicionales a los que defacto son incluidos en el bundle seleccionado.
    netbeans_2
    Y si, Eclipse tambien ofrece paquetes adicionales, pero es muy comun instalar plugins extras al pasar el tiempo y que sin lugar a dudas su abanico de personalizacion es enorme.
    netbeans_3Sin embargo, a veces plug and play de una caja semi-cerrada es mejor a intentar entender que necesitas, sobre todo cuando eres estudiante y necesitas un primer contacto confiable y seguro para comenzar.
  3. El JAR final es igual en Eclipse o Netbeans: Cuando vamos a un restaurante no vamos a la cocina a preguntar que tipos de utencilios se usaron en la preparacion de la comida; al final es la habilidad del cocinero en el uso de sus herramientas e ingredientes lo que dara un resultado positivo o no. Si mi JAR al final cumple con las expectativas entonces no importa si trabaje en uno u otro IDE, todo depende donde me siento mas comodo trabajando, pues hasta el codigo tiene impregnado la personalidad del desarrollador.
  4. Herramientas bien modernas: Compiling, Building, Debugging and Profiling, que a nivel proyecto es fundamental. Ademas de control de versiones de codigo con la integracion de SVN o GIT, Pruebas unitarias con Junit o PHPunit, code assistance y multiplataforma. Lo mismo que ofrece eclipse, pero en una presentacion distinta.
  5. Mas estable, mas cerrado: Me caga configurar el eclipse.ini, pero es necesario cuando de un proyecto enorme se trata, pero si lo que quiero es hacer una libreria o trabajar con un proyecto PHP con composer y un framework ligero, no quiero pensar en eclipse como opcion. Cuando trabajo me gusta escribir codigo rapido, que la herramienta me ayude a que la integracion de cambios sea muy simple (con colorcitos) y no me interesa mucho la configuracion, porque solo quiero programar y ver resultados positivos. Desgraciadamente, eclipse al ser tan flexible a dado al mundo adefecios como RAD, Oracle Workshop, Lotus designer o el viejo Android Studio, que funcionan bien al inicio pero comienzaban a ser una piedra en el zapato al pasar de las semanas y meses por ser adaptaciones de eclipse.
  6. Usar un IDE/Editor de texto cool: Al seleccionar una herramienta nos dejamos llevar por aquello que esta de moda, no con eso digo que todos comenzamos a trabajar con Vim o nano y desintalemos todo editor con asistencia, porque ese no es el camino. Sin embargo, no es cambiar por cambiar de entorno de desarrollo, una vez mas quiero decir que si uno se siente comodo con una herramienta y esa cumple con las ambiciones del momento no hay porque comenzar una nueva curva de aprendizaje.

No se porque termine con 6 puntos cuando pensaba en 5 …

Netbeans no es la panacea, no quiero pensar asi porque iria en contra de lo que trato de explicar. Pero mucho menos quiero que se siga diciendo que es una herramienta para mongers o subnormales.