Hace ya algunos años lei por primera vez este texto. Quisiera poner la referencia del autor, pero no encontré quien lo pudo haber escrito,  así que si alguien me dice a quién darle el crédito, con gusto se lo daremos Aparte de lo gracioso en sí mismo, ahora que lo leo años después, desafortunadamente es muy acertado. Digo desafortunadamente, porque tenemos que cambiar la manare de hacer proyectos de software. Urgentemente. Nuevas metodologías, nuevas herramientas, nuevos paradigmas. Actualmente el proceso de hacer software es más complicado de lo que, en mi humilde opinión, debería ser. ¿Qué piensan?

5 de enero
Hoy me han llevado al lugar de construcción por primera vez. La situación es perfecta: tiene parada de bus cercana y enfrente hay una cafetería con comida casera. El viejo edificio de apartamentos, al que va a sustituir nuestra nueva construcción, lleva un año al borde de la ruina. Mi propia empresa ha colocado varios puntales que, por el momento, han ido evitando que el caduco edificio reviente por sus múltiples grietas. La construcción de este megalito ladrillo comenzó hace cinco años, y aunque los pisos superiores nunca llegaron a recibir el agua, la electricidad y el enfoscado de las paredes, en diez meses los cimientos ya se habían desplazado peligrosamente y las vigas presentaban peligrosas fisuras. La cansada torre de viviendas ya ha cumplido su propósito y ahora nosotros la conduciremos a una muerte dulce… Por supuesto, el viejo edificio no será demolido hasta después de construir y probar el nuevo, lo que nos deja poco espacio de maniobra; pero no vamos a dejar a todas esas familias en la calle durante la construcción. De cualquier modo, los vecinos de la vieja y decadente estructura nos miran con recelo. Saben que el nuevo edificio tendrá viviendas cómodas, pero algunos de los residentes no podrán costearlas. Ni sé qué va a ser de la gente, ni es asunto mío. Llegan los primeros camiones de ladrillos.

6 de enero
Me han presentado a Matías, la persona a quien “voy a reportar”. No me han dicho si es el capataz, el jefe de obra, el aparejador, o el arquitecto; sólo me han dicho que todo lo que tenga que “reportar” se lo “reporte” a él. Así que, por donde él diga, yo zaca-zaca, como una locomotora. Esa es la definición que me han dado de nuestra metodología. He buscado “reportar” en el diccionario, y no aparece.

10 de febrero
En algo más de un mes, hemos cavado medio metro de cimientos. Ayer Matías nos dijo que empezáramos a poner ladrillos, porque el tiempo designado para la cimentación se había agotado hace dos semanas. No aceptó nuestras excusas de que las prometidas excavadoras aún no habían llegado y que nos habíamos visto obligados a cavar con las paletas de enyesar. Un compañero se trajo un pala de cavar que guardaba de una obra anterior y casi le echan por razones deontológicas. Según Matías, lo que pasa es que frecuentamos demasiado la cafetería. El asunto se ha zanjado con un “hale”, a levantar paredes y luego que cada palo aguante su “vela”. El trabajo sin planos es dificultoso. Los cimientos tienen una forma algo pintoresca. He pedido una plomada para que las paredes queden verticales y he recibido improperios poniendo en duda mi masculinidad. Ya sé que Matías no es el arquitecto, porque el arquitecto es un tal Ignacio. Pasó a supervisar la obra el otro día. Aunque aún no había nada que ver. Me han llegado rumores, aunque no son muy dignos de crédito, de que existen fotocopias de planos.

1 de junio
Anoche estuvimos hasta la siete de la mañana cubriendo con tablas y enmoquetando el espacio que algún día ocupará el despacho de la planta, aunque el edificio no es aún más que una maraña de vigas de todos los tamaños y algunas paredes que habrá que tirar más tarde están en el sitio equivocado. Hemos traído baterías para los fluorescentes y unos muebles de caoba preciosos. Por suerte, todo estuvo a punto para la demo. Izamos al cliente con la grúa hasta su futuro despacho y pudo contemplar la vista que disfrutaría desde el emplazamiento. El viento hizo que la pared oeste, que dos de mis compañeros sujetaban con la espalda, se derrumbara con gran estruendo sobre la mesa de caoba en el peor momento. Gracias a Dios, el cliente fue comprensivo: esto pasa siempre en las demos, y él está curado de espanto, dijo mientras el sacudíamos el polvo del traje. Dice que el lunes que viene vendrá a probar las instalaciones sanitarias. Supliremos con cubos la inexistencia de tuberías.

5 de marzo
Han transcurrido casi catorce meses. Llevamos ya siete de retraso y el edificio no acaba de superar el estado de “casi terminado”. Soy de los pocos albañiles que no ha cambiado de obra en este tiempo. Matías está consumido por la zozobra y se pasa el día en la cafetería trasegando Soberanos. El arquitecto no ha vuelto a pasar por aquí. Los rumores dicen que existieron unos planos, pero no eran de un bloque de pisos, sino de un polideportivo. Por lo visto, en las reuniones del comité de construcción se dijo que la filosofía era la misma y que sólo harían falta modificaciones mínimas. Ahora comprendo por qué nos hicieron instalar aros de baloncesto en el hueco del ascensor. Siempre dije que acabaríamos teniendo que quitarlos o aquello no era un hueco de ascensor, que era cuestión de lógica. Matías siempre me contestaba que no le viniera con tecnicismos. Estoy perdiendo la vocación de constructor. He decidido apuntarme por las tardes a un curso de informática, a ver si puedo cambiar de vida. Este oficio mío no es serio.

No related posts.

Si estás pensando en poner, o ya tienes, una empresa de software, tendrás que aprender un poco de marketing, mercadeo y todas esas otras ciencias ocultas que siempre viste de menos y consideras superfluas y no dignas de tu valioso y hermoso tiempo. Pero si quieres que tu empresa salga adelante, has de enamorarte (o al menos hacer que te gusta) del marketing.

En estos posts estaré tocando con cierta frecuencia el tema del marketing, porque a nosotros los tecnólogos geeks no nos gusta, no se nos hace necesario y hasta vemos de menos aquellos que lo practican. Pero tienes que tener en mente esto: si quieres hacer una empresa existosa, te conviene saber de marketing. Tu empresa puede no hacer buenos productos y mercadearse bien, y seguirá viva. Pero si hace excelentes productos que nadie conoce (o que a nadie le sirven!) estarás en problemas. Claro si haces malos productos y nadie los conoce ya sabes el destino .

El marketing te servirá tanto como si quieres hacer una empresa de 1000 personas con ventas millonarias al año, como si quieres poner tu pequeño estudio de freelancing en tu hogar y ganar lo suficiente para mantenerte y para tus chicles. Es vital para tu empresa, sea de uno o de mil, que venda. Y si lo que quieres vender es software tienes que aprender a hacerlo. Pronto te darás cuenta que lo más difícil es vender – y que – al final de los cantares el mundo del software s un mundo de ventas. 

Así que nada de hacerle caras feas al marketing y vete a comprar un par de buenos libros para devorarlos. Aquí iremos también compratiendo experiencias y dándote consejos para que vayas teniendo una guía. 

P.D. Acabo de buscar y “marketing” es considerado como correcto (aunque anglicismo) por la RAE.

No related posts.

Una de las razones por las que nació este blog es para documentar mi experiencia construyendo una nueva empresa de software y los proyectos nuevos que vayan surgiendo. Uno de los talones de Aquiles del mundo del software es la incapacidad de almacenar conocimiento, la constante invención de agua azucarada a la que todos los que nos movemos en esta bosque constantemente nos sometemos.

Un buen comienzo es ser sincero: ¿Para qué existe una empresa de software? Como cualquier empresa, la primera razón es: hacer dinero. Creo que cualquier empresa que olvide ese principio llegará a tener problemas de subsistencia. No es ser materialista, ni mucho menos, pero al final de los cantares, o como la llamaría Aristóteles, la causa final de una empresa de software es hacer dinero.  Y, siguiendo con Aristóteles, la causa material sería el software.

Un libro que recomiendo es On The Business of Software de Erick Sink. Muchas de las ideas que presentaré vienen del libro, que también tendrá su post especial….cuando tenga tiempo.

Pero siguiendo con el punto. Así como un martillo existe para martillar, una bicicleta para moverse, una guitarra para tocarla, del mismo modo una empresa existe para hacer dinero. Entonces una empresa de software existe para hacer dinero a través del software que hace.

Tipos o divisiones en las empresas de software hay muchos. Hay empresas que se dedican a hacer sistemas operativos, otras a hacer bases de datos, otras a hacer ERPs, otras para hacer páginas web, otras para integrar distintos sistemas, otras para software bancario, otras de telecomunicaciones, otras para restaurantes, otras hacen software a la medida y un gran etc.

Resumiendo, una empresa de software es una organización dedicada a hacer dinero a través de software. El siguiente punto que se debe definir es ¿qué tipo de software hará la compañía?

En el blog hablaré de mi proyecto, con las restricciones y oportunidades que tengo (el famoso FODA). ¿Haciendo qué tipo de software podré hacer negocio? Para ser realistas por el momento han de desecharse las “grandes ligas”. Es irreal suponer, diseñar y demás, una empresa que se dedique a hacer sistemas operativos, o una competencia a MS Office, a SAP, a Oracle o alguno parecido. No digo que no se pueda, lo que digo es que una empresa pequeña NO debe empezar por ahí.

¿Entonces en donde empezar? Bueno, hay nichos, muchos nichos. Hay que elegir un nicho que sea lo suficientemente pequeño que no interese a los grandes, pero que sea lo suficientemente grande para crear ganancias. Creo que una empresa pequeña será generalmente una evolución de consultorías pequeñas o medianas de software hecho a la medida. Este creo que es un buen punto de partida. Por ello hay que elegir cuidadosamente los proyectos en los que un consultor que desea crear una empresa de software se mete.

A la fecha no sé en que nicho de mercado deseo meterme, pero ya les estaré comunicando cuál. También creo que es importante definir un proyecto e intentar separarse un poco del software a la medida ¿por qué? Porque el retorno de un producto que se vende muchas veces es muchas veces mayor que estar haciendo software a la medida.

En conclusión: una empresa de software pequeña es una organización que se dedica a ganar dinero a través de pequeños proyectos de software, consolidando uno o varios productos de los que puede obtener ganancias en un mercado en el que puede competir.

Claro, esto es una simplificación. Una empresa de software, como cualquier otra empresa, tiene mucho conocimiento, muchos trucos, mucha experiencia que debe adquirir y cultivar. No es sencillo funda una empresa próspera de software: hay muchos riesgos que hay que saber identificar y manejar. Hay metodologías técnicas y administrativas que se tienen que adquirir y refinar. El software es una ciencia-arte y para que una empresa que hace algo así es necesario que se componga de artistas-científicos que la hagan funcionar.

Luis H. Fernandez
luishernan@gmail.com

No related posts.

Calidad en el software.

El término calidad siempre me ha parecido ambiguo. ¿Que hace que un bien o servicio “posea” calidad? No sé. Hay procesos de calidad, chequeos de calidad, y mil cosas con calidad, pero nadie entiende a ciencia cierta qué es calidad, aunque todos comprenden el término. Aunque para algunos es aquel software que no tiene bugs, para otros el que satisface al cliente, para otros es el que optimiza recursos, para otros el que se mira bonito, etc.

Cuando el término entra al contexto del software, la cosa se pone peor. ¿Qué hace que un software sea uno de calidad o no? Claro, debido a lo ambiguo del término, la discusión en este tema no tendrá fin.

Con todo, lo que hacemos es software, y nos gustaría hacer siempre software de calidad. Para poder etiquetar a un software como uno de calidad, debemos definir algunos atributos para poder poner el software en evaluación. Estos atributos, y sus prioridades, cambian cuando cambia el contexto de software: un sistema para hospitales se juzga de una manera distinta a una página web.

En FFSE R. Glass propone siete atributos del software que le confieren lo que llamamos calidad:
+Portabilidad: la portabilidad implica que un programa puede correr en distintas plataformas, no sólo de sistemas operativos sino diferentes versiones, diferentes ambientes y esquemas.
+Fiabilidad o confiabilidad: el software hace lo que debería hacer, y no “truena”.
+Eficiencia: que tanto recursos economiza en tiempo y espacio el software.
+Facilidad de uso: es fácil de usar?
+Evaluable: Es sencillo de examinar? Se le pueden correr fácilmente unit tests?
+Leíble: Es el código expresivo y fácil de comprender?
+Mofificable: Qué tan sencillo es modificar el software.
+Escalibilidad: pueden agregarse funciones de manera rápida y consistente?

Buscando en internet, encontré otros atributos que vale la pena mencionar:

+Compatibilidad: es el software amigable con otros sistemas?
+Seguridad: es el software seguro contra ataques externos?

Todos concordarán que los atributos anteriores son buenos parámetros para medir la calidad de un producto de software. Sin embargo el orden de estos productos varían de proyecto a proyecto. Un proyecto que maneja información confidencial puede que tenga la seguridad muy alta, una página de internet tendrá muy alta la facilidad de uso, un software bancario tomará más en cuenta la fiabilidad que la portabilidad.

El usuario y el código

Al usuario final le viene del norte en qué tecnología corre un programa, o que metodología de desarrollo se utilizó para su creación. Poco le importa si se utilizó un lenguaje de cuarta generación o assembler. El usuario toma por sentado ciertos estándares y cierta funcionalidad. Por ejemplo un usuario espera siempre que en el lugar que aparezca un disquete se grabe su trabajo. Si esto no funciona bien, el usuario tendrá una muy mala percepción del software, y por tanto el software no tendrá mucha calidad.

El otro lado de la moneda es la calidad del código. ¿Es sencillo de encontrar errores? ¿Hay un buen uso del modelo de programación? ¿Se optimiza el uso del hardware? Aquí cada quien tiene un criterio diferente, hay filosofías, metodologías, paradigmas y demás.

Glass expone algo que me llamó mucho la atención: la satisfacción del cliente no es lo mismo que calidad de software. Entre los elementos que evalúa el cliente están cosas como el precio del producto, el diseño, el tiempo de entrega, el soporte y otros. Un mal software puede tener una alta satisfacción (aunque poco probable), y un buen software puede ser mal valuado por el usuario (créanme, sucede). Entonces la política de calidad de la empresa en general es distinta a la política de calidad del software en sí. Pese a muchas opiniones, el software es el código y nada más. Otras cosas le van unidas, pero no son software.

En Pragmatic Programme Hunt y Thomas exponen un punto importante: software lo suficientemente bueno. En ocasiones, especialmente cuando no hay restricciones de calendario, el desarrollador quiere siempre mejorar su software. Irónicamemte un software puede ser siempre mejorado. Hay que aprender cuando un software es lo suficientemnete bueno, porque agregarle funcionalidad o mejoras puede ser hasta contraproducente si no se sabe donde parar. Al final esto es ingeniería de software, y como todas las ingenierías nuestro objetivo es calcular. Si voy a comprar alambre para cercas las plantas de mi casa puedo calcular la circunferencia usando 3 en vez de pi, si voy calcular los materiales necesarios para un edificio redondo seguramente usaré 3.14159 o tal vez más dígitos, y si estoy calculando la órbita de una nave espacial definitivamente usaré más decimales. Hay que saber cual me conviene más. Lo mismo en el software.

Existe un ISO, el 9126 que se dedica a la calidad de software tiene puntos muy interesantes. Especialmente me gustó la división que hacen para medir la calidad: la calidad del modelo, la calidad de la métrica externa, la de la métrica interna y la calidad en el uso de las métricas. Está también CMMI que se dedica a la calidad estandarizar la calidad del software y la calidad del proceso productivo de éste.

En fin la calidad de software es algo que radica entre lo objetivo y lo subjetivo. Hay mucha leña por ahí para partir, porque el universo del software es también dinámico y los parámetros también cambian. Cada equipo de trabajo tiene sus propios parámetros. Lo que quiero recalcar es que cada equipo debe definir cuales son sus parámetros para medir la calidad de su software. Luego modelar, diseñar, implementar y mantener el software apegado a esos claves. En cada proyecto el orden de prioridades cambian también y hay que tenerlo presente, porque al final de los cantares lo que queremos es que nuestro software funcione, le guste al usuario y se acerque lo más ppsible a hacer lo que tiene que hacer.

Luis H. Fernandez
luishernan@gmail.com

Algunos links.

http://synergix.wordpress.com/2008/07/02/modelo-de-calidad-tradicional-del-software/

http://blog.xebia.com/2008/11/05/what-exactly-is-software-quality/

http://en.wikipedia.org/wiki/Software_quality

http://satc.gsfc.nasa.gov/support/STC_APR96/qualtiy/stc_qual.PDF

http://en.wikipedia.org/wiki/ISO_9126

http://www.bth.se/tek/besq.nsf/(WebFiles)/CF1C3230DB425EDCC125706900317C44/$FILE/chapter_1.pdf

No related posts.

Abro este espacio para lograr un poco de discusión y para exponer mis ideas sobre el desarrollo de software. Si estás leyendo estas letras es porque te gusta programar, porque de otra manera no te interesa mucho lo que diré.

Creo que el desarrollo de software sufre un estancamiento severo. Hemos desarrollado nuevas e interesantes técnicas, modelos de manejo de datos, metodologías de desarrollo, y un sin fin de formas para hacer las cosas. La nuestra es una tarea altamente intelectual y hemos estado viendo como hacernos la vida más sencilla.

Sin embargo los tiempos y costos de desarrollo permanecen iguales, sino es que han crecido más. El estallido de GUIs con mucho entorno gráfico han añadido dificultad a nuestra tarea. El desarrollo en web se ha tornado altamente dominante, y los usuarios esperan webs bonitas, pero a nosotros, por lo general, no nos gusta hacer cosas bonitas, nos gusta hacer cosas que funcionen. Han aparecido los diseñadores gráficos, cosa que no es mala en sí, pero no han aparecido formas de lograr una simbiosis entre programadores y diseñadores gráficos.

Todos aprendemos nuevas tecnologías y frameworks constantemente. Aparecen, y queremos usarlos. Algunas de estas ideas fructifican y se convierten en estándares de facto. Muchas otras crean un gran alboroto pero terminan quedando en lo que algunos llaman shelfware, es decir en la librera guardados y considerados como ideas interesantes pero que no aplican.

Finalmente, creo que el software es una gran oportunidad de desarrollo para Latinoamérica. La inversión en software es relativamente pequeña: una computadora y alguien que sepa usarla. No se precisan de multimilonarias fábricas ni materias primas. Necesitamos personas educadas que sepan manejar y crear y software. Siempre me he preguntado: ¿por qué de los miles de frameworks que aparecen, hay tan pocos latinoamericanos? Y cuando de casualidad me encuentro con uno de origen latinoamericano, generalmente es brasileño. Este blog tambien quiero que sea una invitación, que lance una espinita, para que desarrolladores hispanos nos pongamos las pilas y creemos. Tenemos la capacidad, aunque nos hemos dormido.

Así que bienvenidos, ojalá aparezca pronto la crítica y las ideas. El nuestro es un mundo precioso, así que démosle un toque con ñ.

No related posts.