«Code should grow by addition rather than mutation»
Michael Feathers, on Measuring the closure of code. Via: Software volatility.
«Code should grow by addition rather than mutation»
Michael Feathers, on Measuring the closure of code. Via: Software volatility.
Durante el fin de semana, a ratos libres, he ido completando el wiki con una entrada sobre los principios del desarrollo de software que todavía tienen que evolucionar. Aunque la programación es una tensión continua entre varios heurísticos, tener en mente lo anterior y seguir unas técnicas de trabajo adecuadas me ayuda a tomar decisiones.
No os perdáis esta Historia del cooperativismo, de los indianos. Si andas como yo dándole vueltas a la autogestión en la empresa (también conocida como autoorganización, democracia económica, corresponsabilidad, etc) parece que es momento de releer a Proudhon. Son bienvenidas sugerencias!
«If we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”»
Edsger Dijkstra. Quoted on Are all patches create equal? article by Jonathan Corbet, a must read.
¿Usuarios habituales de gvSIG? No os perdáis esta extensión que añade nuevas funcionalidades al TOC estándar que acaba de liberar Cartolab.
As you may know, iCarto and Cartolab have hosted a gvSIG codesprint at the nice city of A Coruña. iCarto was kind enough to support my attendance to the event to work on gvsig, navtable & navtableforms. Find below some comments on my personal experience.
In the hacking side, I’m pretty happy with the results. Most of the time, Jorge López and me paired together to resolve the priority things on NavTable and NavTableForms. Here the results:
Summing up: as you may see, they were two intense days! A lot of work done and the hacktivation energy at full again. Looking forward to next one!
TripAdvisor is one of the largest travel sites: 40M Visitors/Month, 200M Dynamic Page views/Day, … how do they make this possible? Here the answer. As I’m a culture/development process junkie, I’ve search how they work. Their approach: an extremely agile culture (as they put it: “No architects. Engineers works across the entire stack“) with a lot of code/design review and co-responsibility on your own work.
Poco a poco el wiki toma más contenido. En los últimos días he estado añadiendo técnicas, conceptos, personajes y eventos del mundo SIG que almacenaba en local. Está muy en pañales todavía y, debido a la actividad de la última semana, contiene principalmente conceptos e ideas relacionados con el análisis geográfico. Pero crecerá!
«Social networks are the modern Romeo and Juliet story. If Romeo is on Facebook and Juliet is on MySpace, there’s no way that they can ever be together»
«One of the most important ways in which these efforts differ is where the risks lie. For utility projects the biggest risk is some kind of catastrophic error – you don’t want the sewage pipe to break, or to miss payroll. So you need enough attention to make sure that doesn’t happen, but other than that you want costs to be as low as possible. However with strategic projects, the biggest risk is not doing something before your competitors do. So you need to be able to react quickly. Cost is much less of an issue because the opportunity cost of not doing something is far greater than costs of software development itself.»
Martin Fowler, on software as utility or as strategic asset.