Cada cierto tiempo se oyen voces críticas sobre la falta de rigor con la que trabajan la mayoría de los programadores. La falta de métodos formales de verificación y benchmarking produce muchos programas lentos y nada fiables. Pero ¿es la programación sólo una extensión de las matemáticas por otros medios?
Algunos consejos prácticos sobre cómo poner precio a tu aplicación web: How to price your web application. Es una lectura interesante en la que se nos habla de cómo diferenciar los distintos planes, qué estrategia de precios puede resultar interesante, etc.
Si os interesa este tema y no lo habéis leído, es imprescindible leer Camels and Rubber Duckies de Joel Spolsky.
Por cierto, leyendo el artículo sobre Endeve en Alzado la respuesta parece ser: En España, mejor no le pongas precio.
Resumiendo: Endeve es una aplicación para gestionar nuestras facturas, especialmente recomendado para autónomos y pequeñas empresas. Hace un año, decidieron abrir la plataforma y poner gratuita una buena parte de su funcionalidad. Aunque han conseguido multiplicar sus usuarios (gratuitos) un 800%, parece que muy pocos usuarios pagan por el servicio (o por lo menos esa es mi impresión tras leer el artículo).
¿Cual es el problema? ¿Quizá esa aplicación no interesa a su publico objetivo? ¿O es que en España nadie quiere pagar por una aplicación web? ¿Alguna empresa ha conseguido vivir de una aplicación web?
En Design-Nation se han lanzado a la aventura de convertirse en una microISV(Micro Independent Software Vendor) y a raíz de la aparición de su primer producto, han escrito un artículo reflexionando sobre la creación del mismo: FND postmortem
Aunque yo le diría a Cesar, su creador, que el nombre del artículo no está muy bien traído (al fin y al cabo, se supone que su producto no está mortem sino recién nacido) creo que es una lectura que merece la pena. Nos habla de dónde encontrar motivación, de lo importante que es saber delimitar qué funcionalidades debemos incluir y cuales descartar, y mucho más.
Un tema este del microISV que me parece que es muy interesante y que merece un artículo más largo. Por ahora os dejo con la definición y referencias en la Wikipedia
Un defecto que se achaca a diversas metodologías es que no están basadas en estadísticas de mejoras de productividad, sino que se basan en la impresión anecdótica de sus desarrolladores. Puede que se deba al estado aún primitivo de la ingeniería del software, donde hay poco regulado y las diferencias de productividad entre dos métodos quedan en gran medida minimizadas por las enormes diferencias de productividad entre unos programadores y otros y al efecto Hawthorne.
En cualquier caso, algunos seguidores de la Programación Ágil han creado un wiki donde se recopilan, anotadas, referencias bibliográficas sobre esta metodología de desarrollo: Agile Bibliography Wiki
Una buena cantidad de lecturas para comprobar la eficiencia (o no) de la Programación Ágil.
¿Existe una barrera infranqueable entre los programadores y el común de los mortales? ¿Qué factores contribuyen a que no nos entiendan?
Creo que son muy interesantes la serie de artículos publicados por Martín Pérez sobre cómo el trabajo en un proyecto de soft libre puede desembocar en una oportunidad laboral: Sobre Software Libre y las nuevas formas de encontrar trabajo.
Divide las oportunidades según sea crear un nuevo proyecto o unirse a uno ya existente. Algunas de estas son:
Las compras de software tienen un problema de percepción en el orden de magnitud de la cifra a pagar. Los compradores esperan pagar 3.000 o 30.000 donde debería costarles realmente 30.000 ó 300.000.
¿Existe una tendencia a considerar el trabajo de programación como “de menor nivel”? Y si es así, ¿por qué?
Sergio Montoro reflexiona en La Pastilla Roja sobre cosas que son demasiado fáciles:
Y por último, por la parte que me toca, odio los lenguajes de scripting y todas las herramientas de desarrollo rápido que sólo nos han traído la filosofía de “Paco esto tenlo listo para mañana”. Programar en ensamblador con 16Kb y programas re-entrantes era igual de divertido que hacerlo en Rails o en lo que toque ahora, y, al menos, los clientes no asumían que el software es algo así como las setas, que crece en el servidor por la noche y está listo para hacer un guiso en la mañana.
Por cierto, Sergio escribe siempre unos muy buenos artículos de opinión en La Pastilla Roja, muchos sobre consultoría y desarrollo en general (no sólo sobre software libre) y merece la pena leerle en ese blog, aunque el tema del software libre no sea de nuestro interés (que también).
No os perdáis tampoco los artículos de Sergio Montoro aquí, en Versión Cero.
Interesante el artículo Developers are from Mars, Programmers are from Venus, en el que se definen y contraponen las actitudes del programador (centrado en la tecnología, el código bonito y los puzles lógicos) frente al desarrollador (que se preocupa de obtener una solución centrada en el cliente y del proyecto como un todo, más allá del código).
Aunque algo estereotipado y claramente favorable al desarrollador, el artículo presenta estas dos visiones del desarrollo de software con las que todos tenemos que lidiar.
Relacionado: Small ISVs: You need Developers, not Programmers, un artículo anterior de Eric Sink con una opinión parecida.
