Mostrando las entradas con la etiqueta Gestion. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Gestion. Mostrar todas las entradas

Top 10 de cosas que molestan a los programadores

viernes, 29 de octubre de 2010
Este post fue escrito por Kevin William Pang en Agosto del 2008, al ver su contenido me identifique en cada una de sus palabras y me vi obligado a pedirle su autorización para compartir este top 10 en español.
La versión en ingles esta aquí

10. Comentarios que explican el "como" y no el "porque"
Los niveles introductorios de programación siempre recomiendan a los estudiantes que deben poner comentarios a su código constantemente. La idea es la de tener tantos comentarios como se puedan en vez de no tener ninguno. Desafortunadamente algunos programadores se toman muy a pecho este precepto y comentan cada linea de código, es por eso que muchas veces encontraras este tipo de lineas de código.
Se entiende que es lo que hace el código? Si bien hay muchas lineas de comentarios describiendo lo que el código hace, no hay ninguna que diga por que lo hace.
Consideremos la misma porción de código con un enfoque de comentarios diferente:
Mucho mejor! De todas formas no tenemos un entendimiento exacto del propósito del codigo pero ya tenemos un punto de partida para entenderlo.
Los comentarios se suponen que están para ayudar al lector a entender el código, no la sintaxis. Esta bien  asumir que el lector tiene un entendimiento básico de como funciona un loop, no hay necesidad de escribir un comentario como "iterar la lista de clientes". Con lo que el lector no estará familiarizado es por que tu código funciona de la forma en la que lo escribiste.
Snippet extraído del post de Jeff Atwood "Coding without comments"

9. Interrupciones
Muy pocos programadores pueden ir de 0 a codificar en un parpadeo. En general, el programador tiende a ser mas como una locomotora que como un Ferrari; es posible que nos tome un tiempo comenzar a codificar, pero, una vez que empezamos podemos realizar una gran cantidad de trabajo. Lastimosamente es difícil entrar en tal concentración cuando tu tren de pensamientos se ve descarrilado constantemente por clientes, administradores y compañeros.
Simplemente hay demasiada información que mantener en mente mientras trabajamos en una tarea como para poder dejarla, atender otro asunto y luego volver en el punto que habíamos dejado sin perder el ritmo. Las interrupciones matan nuestra concentración y retomarla es una tarea que consume tiempo, frustranrte y lo pero de todo es que produce errores.

8. El monstruo del alcance
[El Síndrome del lavadero o Arrastramiento del alcance (Scope creep en inglés) en gestión de proyectos se refiere a aquellos cambios no controlados en el alcance de un proyecto. Este fenómeno puede ocurrir cuando el alcance de un proyecto no se define, documenta, o controla correctamente.
Típicamente, el aumento del alcance consiste en productos nuevos o nuevas características de productos ya aprobados que hacen que el equipo de proyecto se desvíe de su propósito original. Debido a su tendencia a centrarse en solamente una dimensión de un proyecto, el arrastramiento del alcance puede también dar lugar a que el equipo de proyecto exceda su presupuesto y cronograma originales. Mientras el alcance de un proyecto crece, más tareas se deben terminar con el mismo coste y cronograma que la cantidad original de tareas del proyecto.]
El arrastramiento del alcance puede tornar un requerimiento simple en un monstruo complejo y horrible que consume nuestro tiempo. Es solo necesario un par de "teclazos" por parte del ingeniero de requerimientos para que esto suceda:
  • Versión 1: Mostrar un mapa con la ubicación
  • Versión 2: Mostrar un mapa 3D de la ubicación
  • Versión 3: Mostrar un mapa 3D de la ubicación por el cual el usuario pueda navegar
Lo que habría sido una tarea de 30 minutos se ha convertido en un sistema complejo que puede llegar a tomar cientos de horas hombre. Aun peor, la mayormente los arrastres de alcance ocurren durante el desarrollo, lo que requiere de re-trabajo, refactoring y muchas veces botar código que ya se había escrito días antes.

7. La administración no entiende de programación
La administración/gestión no es un trabajo facil. La gente es dificil; Mantener a un gran grupo de programadores contentos y unidos es una tarea titanica. Sin embargo, eso no quiere decir que la administración deba mantenerse fuera de un entendimiento básico del trabajo que se esta realizando. Cuando la administración no puede entender el desarrollo encarado es muy probable que se arrastren los alcances y fechas limites poco realistas. y, en general, frustración en ambos lados de la mesa. Esta es una queja común entre los programadores. Esta es una queja común entre programadores y también la fuente de muchos miedos 

6. Documentar nuestras aplicaciones
Si, existen aplicaciones que generan la documentación del código que escribimos, esa documentación es buena para otros programadores. Si trabajamos con una aplicación que sera utilizada por gente normal va a ser necesario escribir una documentación que una persona promedio pueda entender (por ejemplo, como funciona la aplicación, manual de usuario, etc.).
No es difícil ver que esta tarea es una carga muy pesada para los programadores. Fíjense en todos los programas Open Source que hay disponibles, cual es el común denominador en las tareas que mas ayuda solicitan? Documentación. Creo podre hablar en nombre de todos los programadores cuando digo "Puede alguien mas hacerlo?"

5. Aplicaciones sin documentación
Nunca se dijo que no somo hipócritas. Lo programadores están siempre solicitando librerías de 3ros para integrar en su trabajo. Y para poder hacer eso "necesitamos documentación". Des afortunadamente, como mencionamos en el punto 6 programadores odian escribir documentación. No, la ironía no se ha perdido.
No hay tarea mas frustrante que tratar de usar una librería de 3ros cuando no tenemos la menor idea de que es lo que hace la mitad de la función que queremos usar. Cual es la diferencia entre funcionPobrementeNombrada() y funcionParecidaPobrementeNombrada()? Necesito verificar nulos antes de usar la PropiedadX? Seguramente sera con prueba y error...

4. Hardware
Cualquier programador que alguna vez fue llamado para depurar un error extraño en la base de datos o por que el controlador RAID no funciona correctamente sabe que los problemas de hardware son dolorosos. Parece haber una mala concepción que si un programador trabaja con computadoras, seguramente sabemos como arreglarlas. Esta bien, esto puede ser cierto para algunos programadores, pero reconozco que la gran mayoría de nosotros no nos importa una vez que el assembly ya esta compilado. Nos concentramos en las tareas de alto nivel de tal forma que las cosas funcionen como deberían en ese estrato.

3. Ambigüedad
"El sitio web no funciona". "La funcionalidad X no funciona correctamente". los requerimientos ambiguos son dificiles de concretar. Va a ser siempre una sorpresa para mi como la gente ajena a la programación se exaspera al tratar de explicar como reproducir un problema a un programador. Pareciera que no entienden que "esta roto, no funciona, arregla lo" no es suficiente información para solucionar el problema.
El software es (mayormente) determinístico. Y nos gusta de esa manera. Dennos el gusto al hacernos saber que paso del proceso esta mal en lugar de pedirnos que "lo arreglemos".

2. Otros programadores
Los programadores no siempre se llevan bien entre ellos. Impactante, pero cierto. Este podría ser fácilmente el #1 así que solo nombrare algunas de las situaciones mas comunes que molestan a sus colegas de programación:
  • Ser gruñón al punto de ser hostil
  • No entender que hay un tiempo para discutir la arquitectura del sistema y tiempo para hacer las cosas.
  • Imposibilidad de comunicarse efectivamente y confundir la terminología
  • Apatía hacia el código base y el proyecto
Y como broche de oro la molestia mas grande para un programador

1. Código propio después de 6 meses
Alguna vez volteaste a ver algún código viejo tuyo con cara de dolor? pero que estupidez! como pudiste? quémalo... quémalo con fuego...!
Buenas noticias, no estas solo.
La verdad es, el mundo de la programación es un mundo en constante cambio. Lo que consideramos buenas practicas hoy puede ser obsoleto mañana. Simplemente no es posible escribir un código perfecto por que los estándares que se usan para juzgar el código están en constante evolución. Es difícil aceptar que to código, por muy lindo que sea hoy, probablemente sea ridiculizado en un futuro. Es algo frustrante ya que no importa cuanta investigación hagamos con las ultimas herramientas y tecnología, diseños, frameworks y buenas practicas siempre vamos a ver que falta algo mas. Para mi, esta es la cosa mas molesta para un programador. La fragilidad de lo que hacemos es necesaria para impulsar a las mejoras, pero no puedo dejar de sentirme como uno de esos monjes que pintan con arena.
Bien, ahí están. Top 10 de cosas que molestan a los programadores. Si ves que falta alguno por favor envía tus comentarios.

Off Topic 1 billion hungry

lunes, 25 de octubre de 2010
Por favor apoya a este movimiento, Únete a la red de lucha contra el hambre.


www.1billionhungry.org/andresurena/ 








Ideas que valen

martes, 23 de marzo de 2010
Las grandes ideas, proyectos novedosos y técnicas revolucionarias para hacer software vienen de todas partes del mundo, pero que pasa con el tercer mundo?

Muchas grandes ideas están flotando en el éter esperando a que alguien las tome y no solo las explote de manera adecuada, sino que también la registre y patente a su nombre, pero, es aquí donde aparece la gran interrogante que hace tirar por el suelo el anhelo de la idea. “es demasiado sencillo para ser una patente”.

FALSO, completa y absolutamente falso, una buena idea no tiene por qué ser complicada, sobretodo en el rubro del desarrollo de software, entonces, que es lo que pasa con los Ingenieros de sistemas y de Software que no están generando evidencia de sus ideas? Fácil es el temor al rechazo, este puede venir de un comité evaluador o de sus propio pares “para que vas a registrar esa idea si es de lo mas básica”, “ese proceso es por demás simple, no amerita una patente” y demás excusas que he escuchado muchas veces.

Que sucede, o estamos muy por encima del resto de los mortales que todo nos parece una banalidad o se nos está escapando la liebre por no tener la suficiente autoestima para decir que nuestras ideas son buenas.

He tenido el honor de trabajar con profesionales excepcionales que han tenido ideas que a nadie más se le han ocurrido, y han dejado que se les vaya la oportunidad de trascender en el tiempo registrando esa idea bajo su nombre, es más, me atrevo a formular la pregunta, ¿A quién no se le había ocurrido antes que una aplicación web sea consumida como un servicio (antes que aparezcan los web services) por ejemplo?

Muchas de estas ideas están siendo desperdiciadas por muchos grandes pensadores del mundo del software, quiero aclarar que no necesariamente los grandes pensadores son viejos barbudos y despeinados que se la pasan 25 horas al día frente a la computadora re-pensando y re-haciendo las cosas una y otra vez hasta llegar a un punto máximo de optimización, he conocido estudiantes de los primeros años que tienen ideas claras, frescas y sobretodo innovadoras de cómo hacer las cosas de forma diferente para aprovechar un aspecto más del software siendo desarrollado.

Para Argentina existe una oficina de Marcas y Patentes (su sitio web http://www.marcasypatentes.net/registrodemarcas.htm) en la que se detalla la forma en la que una idea o producto puede ser patentado.
Para Estados Unidos la oficina de Marcas y Patentes del departamento de comercio del gobierno del mismo país se encuentra en http://www.uspto.gov/
Para México el Registro de marcas, patentes, derechos de autor y dominios esta en http://www.marcas.com.mx/

Cada oficina de registro de marcas y patentes tiene sus propias restricciones para los postulantes, pero, la cosa no es tan fácil si uno trabaja en relación de dependencia en una empresa de software. A veces (y sin el conocimiento del empleado) el propietario de la empresa puede hacer uso y abuso de las ideas y sub-productos que salgan de los proyectos en los que se trabaja, es aquí donde aparece una figura legal que protege a la empresa en esta situación que es el convenio de confidencialidad y propiedad intelectual, hay que conocer bien como está planteado este convenio y su alcance; en el peor de los casos uno no puede ni decir donde trabaja ni cuánto gana, en el mejor de los casos se le permite al empleado compartir conocimientos siempre y cuando no se revele la receta secreta.

Para aquellos que tengan gente a su cargo en un proyecto de software y que de este salgan sub-productos, no les vendría mal que registren esas ideas (no sin antes verificar que otro no la haya registrado antes) posiblemente terminen ganando unos $$$ extras porque algunos de los desarrolladores creó una herramienta muy simple que le ayuda a realizar su trabajo.

Metodología ZEN para el desarrollo de software

jueves, 23 de abril de 2009

Aunque a muchos les parezca que esto no tiene sentido alguno, es necesario comprender que el desarrollo no solo es un proceso artesanal, sino que hasta podría considerarlo artístico. Sé que esto puede malinterpretarse pero en las siguientes líneas tratare de explicarme tan claro como el lenguaje escrito me lo permita.

La idea de un sistema, programa, herramienta de software o como quiera denominarse a una pieza de código compilado que cumple una función especifica es la de solucionar un problema o una situación dada para el manejo de información y/o cumplimiento de un proceso que puede o no ser administrado por una persona/s.

Esto puede llegar a ser una explicación muy simple en lo que a la cantidad de cosas que una pieza de código puede hacer, para alguno, para otros la explicación calza bastante bien; pero la idea de estas líneas no es la de tirar una verdad absoluta o de intentar conquistar los cerebros de los desarrolladores, sino, la de establecer una forma de entendimiento al momento de encarar el análisis de un proyecto de esta índole.

Es conocido por todos que el ser humano es el único ser de la creación que no es capaz de llevarse bien con su entorno, al plantear esta idea saltan a mi mente todos los conflictos bélicos y demás cosas que no son parte de este articulo, salvo que, hablemos de la forma en la que entablamos las negociaciones. Que tiene que ver esto con el desarrollo? bueno al momento de analizar una situación en la que es necesario implementar una pieza de cogido, es 100% seguro que deberemos entrar en negociaciones no solo con la persona que está encargando esta pieza, sino con el mismo equipo con el que se trabaja. Tenemos dos tipos de equipos de trabajo los cuales se dividen a su vez en más partes, definamos las primeras dos clases:

Grupos pequeños

Los grupos pequeños tienen a ser muy agiles, claro está, si es que este equipo se conoce bien, a fondo, conocen sus fortalezas y sus debilidades. En este punto quiero hacer hincapié.

Un equipo que conoce sus debilidades puede usarlas para fortalecerse a sí mismo al trabajar sobre ellas.

Un equipo pequeño que no tenga conciencia de sus debilidades es por lo general un equipo susceptible al conflicto, cada uno de los integrantes de este ve en su compañero de trabajo no a una persona que trabaja a su lado sino a una persona que le puede quitar su trabajo. Suena duro, pero así se presentan las cosas. Es sobre este tipo de equipo que me explayare y analizare cuales son los factures que debiesen tomar en cuenta sus integrantes para comenzar a fortalecerse.

Cada uno de los integrantes del equipo debiese conocer a todos sus compañeros, no solo en el ámbito laboral, sino como persona, esto podría parecer que no tiene relevancia y ahora explico porque si la tiene.

Al encarar una negociación muchas veces no logramos exactamente lo que queremos hacer, es en este momento que la personalidad de cada uno manifiesta su estado de ánimo de diferente manera. Algunos entablan una negociación en la que tanto uno como el resto salgan ganando, esta es la negociación ideal, así todos quedan contentos y el trabajo se aliviana tremendamente. Pero qué pasa si un miembro del equipo no está conforme con lo que se le asigno, o como termino la negociación, este miembro del equipo no ha ganado, es mas siente que ha perdido, he aquí el inicio de un problema muy grave.

El hecho que evite que no nos sintamos orgullosos del trabajo realizado comprende un fracaso tanto en lo personal como en lo profesional

Muchas veces me he encontrado en la situación en que uno de los miembros de mi equipo se siente frustrado por la forma en la que la negociación ha concluido, y es necesario que esa frustración sea:

Comunicada (de la mejor forma posible)

Tratada (entablar una negociación)

Solucionada (no puede quedar así)

Si estos pasos no son ejecutados tenemos una bomba de tiempo dentro del equipo, no porque aquella persona que no está "feliz" con el trabajo sea la bomba, sino por la situación en la que esta se encuentra, es necesario que el equipo se mantenga como tal.

Como comunicar frustraciones:

Al sentir que estamos perdiendo cada quien demuestra su sentir de diferente manera, depende de muchos factores, estado de ánimo, carácter, entorno, retribuciones, etc. la única forma de transmitir este sentimiento de frustración es hablando francamente con el equipo, mejor aun si se lo hace antes de cerrar la negociación (ideal) pero de no poderse tratar este asunto en una mesa redonda, el equipo de trabajo es como una familia, ya que durante un tiempo (tiempo de vida del proyecto) tendrán que compartir sus experiencias y verse las caras a diario.

(Continuará...)

Metodologìa ZEN de trabajo en grupo (Cont.)

Como ya se había tratado de establecer en un post anterior la forma de trabajar con Ingenieros de sistemas (y ramas anexas) para poder realizar un proyecto en grupo, debe obedecer a ciertos lineamientos que todo ser humano debe seguir para tener exito en todos los proyectos que emprende (si, se a determinado científicamente que el Ing. de sistemas es un ser humano :D)

Grupos grandes.

Entendamos como grupo grande a un conglomerado de personas que manteniendo su individualidad pretenden afrontar un reto en el que todos deben dirigirse a un mismo punto desde diferentes caminos. aunque este enunciado suene algo rimbombante, es eso lo que se pretende cuando se trabaja en grupo.

Tomemos el punto de vista de la teoría de sistemas; cada sistema puede estar en el marco de un sistema mas grande, es esta relación simbiótica la que permite que un macro sistema compuesto de muchos subsistemas pueda realizar una tarea específica por ejemplo el cuerpo humano. Imaginen que uno de los pulmones no esta de acuerdo con el funcionamiento de el corazón, o que un riñón decide dejar de funcionar sin ninguna razón aparente, ésto causa problemas no solo a esos organos sino a todo el cuerpo ocasionando un sinfin de síntomas que evitan que el resto del cuerpo funcione como deba. se podría decir que esto es una enfermedad.

Asi como las enfermedades el hecho que uno o varios de los integrantes de un equipo de trabajo no se sienta bien ya sea con el trabajo que realiza, con su grupo de compañeros, con el entorno en el que trabaja o algun otro elemento de su mundo laboral, causa que el equipo entero comience a experimentar los síntomas de una enfermedad comunmente llamada "empleado descontento".

Sintomas claros de esta "enfermedad" son:

Trabajo mediocre.-

Podría calificarse de trabajo mediocre al resultado de:

  • La falta de comunicacion de abajo hacia arriba
  • El empleo de mas horas de lo planificado para una tarea de baja complejidad
  • El rehusarse a la utilización de las herramientas de control del proceso de trabajo (conciente o inconcientemente)
  • La pérdida de tiempo en actividades no propias del trabajo en horario laboral
  • Descontento con cualquier cambio en el entorno laboral

Las sutilizas del comportamiento humano deben ser bien identificadas, y es en este campo donde se deben realizar reuniones unipersonales con el equipo para recibir un "feedback" de la situación de "la persona" que esta detras del empleado, es muy factible que las inconformidades que ese empleado tenga sean muy fáciles de satisacer o de negociar, las negociaciones deberán encararse de forma Ganar - Ganar, es decir que ni la empresa ni el empleado deben sentir que despues de una negociación han perdido algo.

Si, como lo debes estar pensando, estas trabajando con un grupo grande de gente el hecho de reunirse con cada uno de ellos sería un problema logístico de proporciones bíblicas(bueno no tanto) entonces ¿que se debiera hacer?

DIVIDE Y VENCERAS

Hay formas(muy prácticas) de poder dividir al personal que esta asignado a un grupo de trabajo de tal forma que la comunicación ya sea de abajo hacia arriba o vice versa sea fluida y sin distorciones; una sola persona no es capaz de tener toda la visibilidad en detalle de la gestión de un proyecto y de recursos humanos.

Una de estas técnicas es la de dividir los grupos de trabajo, demasiado sencilla, pero, es muy efectiva, de esta forma podemos afrontar el reto de tener una idea muy clara de que pasa con el equipo de trabajo desde diferentes ópticas. Ahora, hay que saber que preguntar y como preguntarlo.

Muchas veces nos vamos a encontrar con desarrolladores y analístas que son muy sueltos y relajados al momento de hablar, con estas personas es muy poco probable que tengamos problemas al momento de la entrevista de feedback(llamemoslo asi por ahora); donde es posible que encontremos algo de dificultad en la comunicación es en esas personas que por alguna razón se sienten intimidados ya sea con el jefe o con el líder de proyectos. Es aquí donde el equipo de recursos humanos entra en acción y se encarga de las entrevistas, lo ideal sería comenzar por los mas juniors hacia arriba.

Esta temporada de entrevistas debiera tomar como máximo un par de semanas... sí solo un par y esto debido a que si se emplea demasiado tiempo en esta etapa la muestra recogida puede no estar del todo real, ya que la coyuntura se ha distendido y muchas situaciones pueden darse (ya se positivas o negativas) que afecten la información.

"... Como mantener a sus recursos rentables..."

La frase que acaban de leer es uno de los temas a tratar en una convención de dueños de empresas de diferentes rubros. Si bien el término rentable esta ampliamente aceptado, no es el correcto (o por lo menos para los recursos que son rentables).

En algún punto las empresas dejaron de contratar personas y empezaron a incrementar su bienes inmuebles? la respuesta a esa pregunta es un categórico NO, una de las cosas que podrian hacer para "mantener a sus tan apreciados recursos rentables" es dejar de considerarlos un mueble o un equipo que se conecta a la empresa de 9-5 (o el horario que sea) y empezar a tratarlos como personas.

SI SEÑORES los empleados son personas (aunque hay varios que clasificaron con la mínima nota), muchas veces el empleado migra a otra empresa en busca no solo de un sueldo mas alto, sino de un trato mas digno o de mejores oportunidades de crecimiento.

Quiero terminar con ese ultimo parrafo ya que este tema da para mas

 

(Continuará)