El arte es la destreza

Mi preparación técnica

2009-11-28T00:49:00Z

La categoría para este post es Personal pues trata del todo acerca de mi propia preparación técnica.

Análisis, síntesis (diseño), comunicación, especificación, abstracción, lógica, supuestos, generalización/especialización, objetos, propiedades, conducta, clasificación, y más...trata de las destrezas requeridas para crear buenos diseños en software.

Estudiar filosofía es una buena manera para profundizar en exactamente esas destrezas.

¿Adivinaste? Estoy estudiando filosofía como parte de mi preparación técnica para la creación de soluciones de negocio basadas en software, tan simple como eso.

Para más acerca de esta perspectiva, consulta Object Thinking de David West.

Desarrollo aplicativo formal

2009-11-21T02:36:00Z

Relacionar la idea de la formalidad con el desarrollo aplicativo de software puede significar algo muy positivo en tanto signifique exactitud, puntualidad y consecuencia en las acciones durante dicha actividad (sin mencionar las apasionantes facetas que tiene la idea de formalidad al estudiar algo por su objeto formal en los tratados de lógica). La seriedad y compostura juegan de lado del valor de negocio en contraposición al desorden y la insensatez; como ejemplo, al ignorar por completo —una y otra vez— los rasgos que caracterizan a la creación de soluciones de negocio basadas en software como lo es el concepto de emergencia (acción y efecto de emerger) por el cual es propicio para un negocio estar consciente del modelo co-evolutivo solución/problema.

Por otro lado, una connotación popular de la palabra formal es simplemente otra manera de decir tradicional, lo ya conocido, lo ya establecido. Es en este insípido significado que se usa ocasionalmente —en la parte de la realidad que alcanzo a advertir y aplicado a proyectos de desarrollo de software aplicativo— como queriendo decir que es de gente adulta y profesional el tener, por ejemplo, un diagrama de Gantt debidamente detallado por el cual se guía todo el esfuerzo definido por un contrato, también tradicional.

Sin embargo, el problema perenne en el desarrollo aplicativo tradicional, es decir "formal", es:

¿Satisfacemos la emergente necesidad de negocio del usuario/cliente o satisfacemos los ya anacrónicos contrato y gráfica de Gantt?

Si es el contrato y el Gantt, ¿a costa de que el esfuerzo derive en algo que no le servirá al usuario/cliente y no resulte en retorno de inversión?

Si es la emergente necesidad de negocio, ¿a costa de arriesgarse a sufrir penalizaciones por incumplimiento de contrato?

¿No hay más opciones? ¿No hay acaso una diversidad de planteamientos del estado del arte en desarrollo de software para conducir la relación cliente y proveedor hacia el valor de negocio real? ¿En qué están tan distraídos quienes venden y pactan proyectos de desarrollo aplicativo de software como para estar dándose el lujo de perder oportunidades para elevar el estado de la práctica en esta área? ¿Será que en realidad no tienen ningún interés genuino en elevar el estado de la práctica?

Por ejemplo, las siguientes obras contienen tanto ideas novedosas como ideas que ya han sido propuestas desde hace tiempo. Se trata de perspectivas útiles que demuestran un entendimiento cabal de nuestro problema perenne así como de las alternativas de solución. La información ahí ha estado ¿cuál es la excusa? ¿Qué pasa con la educación del liderazgo en esta industria, es decir, con el cambio de su mentalidad?

(1) Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results

(2) Lean-Agile Software Development: Achieving Enterprise Agility

Creación de software en México

2009-11-16T05:42:00Z

¿Qué hay acerca de la creación de software* en México? Me gustaría que mi escueta opinión al respecto surgiera de observar un espectro muy amplio de la realidad nacional, pero en tal caso ya no sería escueta, ni personal, ni estaría en un blog individual sino en alguna publicación oficial dispuesta para las masas. Sin embargo, sirva como una aspiración a ser eso que son otros mexicanos tan notables por el empleo de su sentido crítico, personal, ese que tiene la posibilidad de transformar al individuo de adentro hacia afuera.

*software es una palabra de la voz inglesa para denotar el conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora. Para el gran público propongo que se entienda como la lógica subyacente para realizar una tarea en una computadora.

El microprocesador digital ha resultado ser una pieza de tecnología de enorme impacto en la sociedad. Al parecer, apenas estamos empezando a descubrir la punta del iceberg en cuanto a las aplicaciones del cómputo digital y las implicaciones de éste en nuestras sociedades. Como otros avances tecnológicos, las computadoras son objeto para la creatividad y para el consumo masivo, o por lo menos eso es lo que se pretende, y no parece haber marcha atrás.

Las computadoras, como herramientas, se sitúan al lado de otras herramientas tecnológicas como el microscopio o el telescopio, sobre las cuales —cuando se tiene el conocimiento para usarlas— podemos apoyarnos para enfocar nuevos y diversos cuadros de la realidad.

Pero, ¿cómo están tomadas las posiciones para la creación de software internacionalmente y en México en particular? ¿Quiénes están ubicados y bien apuntalados en sus posiciones como creadores de software y quiénes han elegido una posición tan sólo de consumidores del mismo?

No falta quien opine que en México sí estamos creando software y que sí estamos preparados para seguir haciéndolo, y haciéndolo bien, que sí vamos por buen camino o que ya están puestos los trazos hacia un mejor desempeño de las futuras generaciones en esta área. En la parte de la realidad que alcanzo a observar, no hay bases para sostener tal opinión. Encuentro, de ordinario, un entusiasmo falaz que disemina un sentido de autocomplacencia que cancela el cuestionamiento y la autocrítica sobre nuestra posición real en el panorama mundial en cuando al diseño de software. Encuentro a veces un frenesí por consumir software, para sólo ostentar lo de moda o hablar de ello, como único fin, pero muy poco acerca de crear software que entregue valor directo y sensible al usuario final. Ese, quien no tiene otra opción que tolerar la absurda excusa “no hay sistema” como respuesta estándar ante la incompetencia de quien pretende emplear tecnología de software para proveer productos o servicios sin diseñar mejores procedimientos organizacionales y mejores sistemas informáticos.

La situación es deprimente al escuchar a quienes están en posiciones de liderazgo en esta área —dentro de instituciones académicas y también en empresas del ramo— y sus opiniones al respecto están basadas exclusivamente en información proveniente ya sea de la mercadotecnia o de erradas analogías con otras industrias como la industria de la construcción o de la manufactura de principios del siglo pasado. ¿Cuál es el mensaje implícito que hacen llegar a quienes los escuchan buscando dirección profesional?† El cuadro es realmente patético al observar los esquemas que se proponen y se autorizan para la preparación del personal técnico que supuestamente estará a cargo de la supervisión y creación de soluciones de negocio basadas en software. Dichos esquemas se adscriben fielmente a los sistemas tradicionales de escolarización y adoctrinamiento de masas, donde la memorización mecánica, control del pensamiento y ambiente carcelario han inspirado históricamente expresiones artísticas cuya aparente exageración nos espolea hacia la reflexión: ¿Cuáles son las condiciones para la creación de mejor software?

† “...¿Qué justifica sostener una opinión basada en la ignorancia? He aquí que opinar tan sólo porque se puede opinar, sin atención, representa un serio agravante para la sociedad a la que se pertenece y se representa...” —El “derecho” a opinar

La preparación que resulta necesaria para la creación de mejor software suele tomar sendas poco populares en México, rumbos en las dimensiones del personal, del proceso de desarrollo, de la idea de diseñar, y de las herramientas tecnológicas [ver las fuentes en Rapid Development por Steve McConnell]. Por mencionar algunas de las más generales categorías que agrupan los factores críticos de éxito en la actividad de crear soluciones de negocio basadas en software, según lo han informado —desde hace muchos años— varios practicantes profesionales de dicha actividad. Tan sólo en la dimensión del personal involucrado en la creación de soluciones de negocio basadas en software —esto incluye clientes, usuarios y proveedores— las siguientes obras nos ayudan a entender que el impacto que tiene sobre los resultados el perfil de dicho personal es de un orden de magnitud muy superior al impacto que tienen los factores en las otras dimensiones: Tom DeMarco y Tim Lister en su clásico Peopleware: Productive Projects and Teams, también Larry L. Constantine por medio de su The Peopleware Papers: Notes on the Human Side of Software, no menos relevantes los hallazgos de Jim y Michele McCarthy en su Software for Your Head. Por mencionar algunos. En pocas palabras: el impacto relativo al proceso de desarrollo o a una arquitectura particular será, a lo mucho, marginal si está ausente el personal adecuado para sacar provecho de dicho proceso de desarrollo o para evolucionar dicha arquitectura.

Esta área de actividad —cuya demanda parece que permanecerá— también requiere una mejora continua del estado de conciencia, tanto en quienes buscan aplicar el software a problemas reales como quienes pretenden proveer los servicios profesionales para crear soluciones basadas en software a dichos problemas, elevando las expectativas de educación en ambas partes. De otro modo, con las expectativas de educación y preparación actuales, no veo otro panorama futuro más el de la continuación del conformismo, donde los clientes y proveedores de sistemas informáticos se deberán conformar con los sistemas que merecen.

¿Hay sólo una manera correcta para crear soluciones de negocio basadas en software? ¿Qué diferencia hay entre quienes responden afirmativamente a esa pregunta y quienes abrazan al dogmatismo como modelo estándar de vida? ¿Qué acaso lo que impone la realidad no es suficiente para adoptar valores, principios, patrones y prácticas que coloquen al aprendizaje continuo en el centro de nuestros proyectos en lugar de pretender que nuestra industria es igual a otras, e.g. ingeniería civil, y que debe funcionar con premisas fundamentales, métricas de desempeño, y demás políticas, similares?

¿Qué forma entonces podrá tener una estrategia plural de preparación para proyectos de creación de soluciones de negocio basadas en software? Sugiero poner atención y continuar con lo que han propuesto practicantes como Gerald M. Weinberg en su serie de cuatro tomos: Quality Software Management; de cuya influencia y síntesis actual se ha derivado el Manifesto for Agile Software Development. Pero teniendo cuidado de no errar por la inercia de tomar las buenas ideas como si fueran dogmas permanentes, al contrario, insertando modelos de adopción en los cuales siempre esté presente el sentido de aprendizaje y de adaptación a nuevas condiciones de contexto —para lo cual el sentido crítico ha sido una herramienta por excelencia en episodios trascendentales de la Historia—. Por cierto, precisamente ese patrón adaptativo y de aprendizaje es parte de la esencia fundamental del manifiesto para el desarrollo ágil de software, desde sus inicios.

Ahí está, lo necesario para presentarse muy bien equipado en un proyecto de creación de soluciones de negocio basadas en software, ahí ha estado por ya largo tiempo. ¿Qué vas a hacer al respecto estimado lector? ¿Esperar a que alguien más te dicte qué pasos dar en tu carrera profesional la cual, ya sea como usuario o proveedor, con mucha seguridad se verá transformada positiva o negativamente por un empleo adecuado o descuidado de la tecnología de software? ¿Qué caracteriza tu plan de preparación técnica, el cortoplacismo y la continuación de los mismos patrones problemáticos populares o la progresión en cada vez mejores niveles de entendimiento y aprendizaje, así como la amplitud de miras que proponen pensadores como David West en su Object Thinking?

Se hace relevante la reflexión acerca de esa tan mencionada palabra: educación. ¿Qué es la educación? ¿Dejaremos que se mantenga como sinónimo de escolarización y adoctrinamiento, como dice la canción “...No necesitamos educación, no necesitamos control mental...” o atenderemos las advertencias de los mexicanos destacados como Denise Dresser en su artículo México amurallado en la revista Proceso No. 1723 del 8 de noviembre de 2009?

El progreso de un aprendiz

2009-10-30T15:36:00Z

Según una perspectiva centrada en el progreso del aprendiz, los rasgos de entendimiento y práctica que puede seguir dicho aprendiz, en general, a lo largo de su aprendizaje son descritos en tres niveles:

Nivel 1: Seguir paso a paso, sin desviarse, las indicaciones del maestro, tratando de copiar lo que observa sin tratar necesariamente de entenderlo por completo. El pensamiento dogmático domina este nivel, donde no se espera que el aprendiz se formule cuestionamientos serios.

Nivel 2: Representa el inicio de una etapa diferente de entendimiento y práctica, donde el aprendiz identifica las limitaciones de lo entendido en el nivel 1 y busca mejorar su conocimiento para aplicarlo a una gran variedad de circunstancias, tomando conciencia de qué aplica y qué no, para cada caso. La esencia de este nivel es cuestionar seriamente lo entendido por el propio aprendiz, abordando con todo detalle las dudas que tenga pendientes. El pensamiento crítico es la marca de este nivel.

Nivel 3: El practicante en este nivel posee la soltura de un espíritu cultivado resultado de haber integrado numerosas acciones y reflexiones a lo largo de los años. Ya no importa si está siguiendo determinado lineamiento, improvisando algún otro, o inventando uno adicional, pues entiende el valor esencial y simplemente se enfoca en cuidarlo y mejorarlo. El pensamiento creativo es el rasgo de este nivel.

El planteamiento se originó en el ámbito de la transmisión de habilidades de maestro a discípulo en las Artes Marciales. Pero puede ser sujeto de generalización —con las debidas proporciones— en otras áreas donde se requiera transmitir o divulgar habilidades. Ya sean éstas habilidades técnicas en diseño de software o en otras actividades donde se busquen cada vez mejores niveles de destreza en el desempeño. Algo importante es no olvidar que “maestro” y “discípulo” son roles que las personas desempeñan en un contexto específico y que parte de la condición de ser “maestro” es la habilidad de conseguirse nuevos aprendizajes —la habilidad de siempre mantenerse como un “discípulo”, es decir, como un aprendiz—.

Un problema típico que puede presentarse por descuido o falta de perspectiva en la adopción del planteamiento consiste en que los principiantes quieran saltar de inmediato al nivel 3 haciendo prematuramente variaciones a lo establecido en el nivel 1, y por tanto perciban como “dogmáticos” a quienes están legítimamente en dicho nivel 3 cuando les indican: No, primero tienes que proceder conforme a lo que se te ha indicado para el nivel 1.

Este planteamiento educativo de tres niveles es el único marco de referencia que he encontrado en donde se emplea al dogmatismo como lo que es, es decir, algo con carácter temporal, no permanente. El planteamiento queda resumido en la siguiente frase a manera de eslogan:

Aprende el principio, respeta el principio, y disuelve el principio

Escribir

2009-09-30T14:28:00Z

La acción de escribir demanda ciertas habilidades por parte del escritor, destrezas del tipo intelectual. Por supuesto, dicha demanda varia con respecto al tipo de escritura, entre otros muchos factores.

Escribir textos para humanos, desde blogs hasta literatura, es desafiante si el propósito es hacer llegar un mensaje en forma clara y concisa, en la manera de lo posible.

Escribir textos técnicos para humanos y computadoras, también conocido como el acto de la programación artística de computadoras digitales, es también muy desafiante.

Basado en el contenido de las conversaciones típicas entre profesionales de TI, sospecho que muy pocas personas vivas hoy en día conocen en realidad qué conlleva efectivamente una comunicación común entre humanos y computadoras digitales a través de textos técnicos (también conocidos como código fuente).

QA — ¿Realmente está asegurando la calidad?

2009-08-30T18:27:00Z

¿Cuál es la idea del “QA”?

Si “QA” significa “Aseguramiento de la calidad”, entonces difícilmente debiéramos encontrar un miembro de proyecto que no tenga eso como su responsabilidad —asumiendo que los miembros en dicho proyecto adoptan valores, principios y prácticas orientadas a la calidad, como las de los métodos ágiles.

Si por “QA” se entiende “testing” (pruebas de validación y verificación, para propósitos de pruebas funcionales/integrales/aceptación) entonces pienso que la ya añeja práctica de contar con un grupo diferente de profesionales ejerciendo pruebas destructivas permanece siendo un buen consejo (si de encontrar defectos se trata, como lo describen Glenford J. Myers, Tom Badgett, Todd M. Thomas y Corey Sandler en su obra The Art of Software Testing).

Las pruebas unitarias en el contexto de la práctica del diseño basado en predicciones y asertos —test-driven design— es para los creadores del software, i.e. los programadores, (mentalidad constructiva); pruebas de validación y verificación, para propósitos de pruebas funcionales/integrales/aceptación, es para los testers (mentalidad destructiva). Por tanto, el rol de los testers no cambia mucho en el contexto de la adopción de métodos ágiles.

Más aún, asegurarse realmente de que la calidad este presente implica algo más grande que concebir al “QA” como un rol que tan sólo algunos miembros tienen en un proyecto de desarrollo de software.

¿Cómo vamos -globalmente- en la entrega de valor de negocio por medio de proyectos con clientes?

2009-07-23T05:34:00Z

Para su información, el resumen del ya famoso reporte The Standish Group CHAOS Report de este año lo pueden consultar en la siguiente página:

CHAOS Report Summary 2009

"These numbers represent a downtick in the success rates from the previous study, as well as a significant increase in the number of failures", says Jim Crear, Standish Group CIO, "They are low point in the last five study periods. This year's results represent the highest failure rate in over a decade"

Fragmento de código como piedra angular de una herramienta

2009-06-01T09:21:00Z

Algunas veces la idea de toda una herramienta puede gravitar alrededor de un simple fragmento de código, que representa un mecanismo habilitador que da vida a una funcionalidad mucho mayor.

Es el caso de una herramienta sencilla que estoy escribiendo para uso personal. Se trata de una aplicación, basada sobre Windows Presentation Foundation, la cual me ayuda a subir archivos desde mi disco duro local hacia un número de sitios y carpetas en Windows Sharepoint y que sigue mis propios patrones de carga y publicación.

El todo de la herramienta gira alrededor de esta simple pieza de código:

La "sentada" como unidad de esfuerzo en trabajo intelectual

2009-05-08T20:02:00Z

Quiero compartir con ustedes una breve nota acerca de una idea. Por si les hace click y gustan agregarla a su toolbox profesional.

Cuando estimes o hagas una proyección de esfuerzo para crear algo —ya sea software o un documento con una especificación funcional) podrías considerar que existe una unidad mínima en la que estará expresada dicha estimación en tanto esfuerzo se refiere, y que dicha unidad es el episodio más básico en el cual es posible entrar en ese estado de flujo mental donde realmente puede suceder el trabajo intelectual.

Dicha unidad representa el episodio mínimo en el cual algo puede ser creado de manera ininterrumpida, ya sea este episodio una sesión de diseño y programación de software o una sesión para articular las ideas y crear un texto. Esta unidad mínima no incluye las interacciones con otros profesionales —colaboración necesaria para indagar y deliberar las particularidades de lo que se quiere crear— sino sólo el trabajo intelectual individual y por lo tanto dichas interacciones deberán medirse con otro tipo de unidades para una estimación integral.

Yo suelo nombrar a dicha unidad de trabajo intelectual: la sentada. Como diciendo: ¿En cuántas sentadas puedo lograr dar vida a este componente? o ¿puedo realmente completar el contenido de este documento en X sentadas?

La duración para una sentada dependerá de la persona, de la forma en que logra el ritmo mental que lo hace productivo. Para alguien puede ser el caso de que en realidad logre 2 sentadas por jornada diaria de trabajo, una por la mañana y una por la tarde. Para otros puede ser diferente. Una sentada a mediodía y otra por la noche. Aun para otros podría ser que logran tres sentadas por día en determinadas condiciones. Todo depende de la manera en que funciona cada uno haciendo trabajo intelectual.

Como se mencionó, el trabajo que no implica la creación de algo sino que es de una naturaleza más interactiva y de coordinación entre profesionales, se rige por diferentes patrones mentales y de comportamiento por lo que no aplica una unidad como la sentada.

La sentada tendrá más sentido cuando se le ve como unidad de trabajo productivo e individual, y partiendo de que en la cultura corporativa generalizada tenemos una muy establecida tradición de medir y evaluar el individualismo —toda la cosmovisión implicada—, entonces podría ser una técnica que puede ayudar a obtener mejores estimaciones.

Sin embargo, se ha detectado un patrón, un tanto ecléctico, en el trabajo intelectual para sentadas de diseño y programación de computadoras, el cual contiene una mezcla interesante entre trabajo intelectual ininterrumpido e interacción con otro profesional del mismo equipo para lograr una misma tarea. Uno de los nombres que ha recibido dicho patrón es Programación en pares (pair programming). Yo personalmente he lo llevado a cabo en ciertas ocasiones y la experiencia me ha sido muy positiva. Pero, para obtener lo mejor de esta otra técnica, implicaría repensar la cosmovisión tradicional individualista que nos rige, corporativamente hablando.

Algunas referencias:

Maker's Schedule, Manager's Schedule

Peopleware: Productive Projects and Teams (Second Edition) by Tom DeMarco, Timothy Lister

Pair Programming Illuminated by Laurie Williams

What a wonderful and fulfilling experience this of pair programming

La importancia de la duda en diseño de software

2009-05-01T04:03:00Z

El explorar y el descubrir que nacen de dudas simples —pensamientos del tipo ‘no estoy completamente seguro acerca de...’— es lo que hace al acto de diseñar software y programar computadoras tan emocionante para mí. Dudar desde la eficiencia o el balance de una decisión de diseño dada, hasta los beneficios netos y de largo plazo de creencias populares acerca del proceso de desarrollo de software en un contexto de negocio.

Basado en los resultados hasta ahora de mi agenda personal de investigación acerca del acto de programar computadoras, he corroborado que esta actividad puede ser reducida —considerando su esencia— a un puro acto de diseño. Consecuentemente, el mejoramiento o avance en la profesión de desarrollo de software va en el camino de mejorar las habilidades de diseño de los practicantes.

Diseñadores de software en el camino a convertirse en un profesional competente en software necesitará educación acerca del arte —por favor nótese que aquí el concepto de educación se está usando en su sentido más amplio y no sólo en la noción popular de escolarización— y acerca de metodologías de trabajo intelectual en lenguas, literatura, historia y filosofía. Por supuesto, como es el caso de la buena educación, esta es auto-infligida. En otras palabras, el entrenamiento se puede proveer pero la educación sólo puede ser escogida.

Entre el conjunto de destrezas en un diseñador de software, la habilidad de pensar críticamente resalta como una de las más importantes. El ejercicio del sentido crítico —en contraste con el sentido común— ha resultado ser de mucho beneficio para la tarea de diseño y directamente relacionado con los atributos de calidad del resultado, es decir, software ejecutable que entrega valor real de negocio.

El acto de concebir, diseñar y codificar software

2009-03-31T15:42:00Z

El acto de concebir, diseñar y codificar software demanda ciertas conductas en quien lo ejecuta que han resultado ser muy similares a las que se observan tanto en artistas como en científicos.

Con base en las condiciones del proyecto de desarrollo típico, se puede identificar el tipo de proyecto que tenemos entre manos, y es una mezcla entre un proyecto de creatividad y de resolución de problemas. Definitivamente no es un proyecto de ejecución táctica, donde la receta para la solución se puede conocer al principio del esfuerzo y que la mera ejecución de tal receta nos produzca el resultado deseado.

Es prudente considerar un proceso de desarrollo acorde a la naturaleza del esfuerzo, uno que contenga —desde el principio— los mecanismos para aproximarse a la solución con base en los hallazgos y aprendizajes en el trayecto, uno que permita adaptarse a lo que se descubra como lo que sí se requiere y dejar de lado lo que resulte no tan adecuado, sin mayor costo.

Un ejemplo, en el renglón del diseño detallado, ocurre al adoptar un patrón de diseño para un ambiente de cómputo en particular: Know your design tools — The Singleton case.

Un excelente libro de texto en programación artística

2009-02-28T15:59:00Z

La mente de Bjarne Stroustrup por medio del pensamiento y estilo de diseño del lenguaje de programación C++ (en específico: ISO C++) ha sido de una importancia fundamental para mi propio pensamiento y práctica de la programación. Sí, él es un filósofo de la programación de computadoras, un programador artístico (es decir, diestro, tal y como se explica en Artistic programming as theory formulation).

Principiantes a la programación de computadoras y experimentados por igual podrán obtener beneficios del libro: Programming: Principles and Practice Using C++, pues es presentada una buena variedad de conceptos y ejercicios, incluyendo perspectivas históricas en algunos temas. Además, los diseñadores de programas que cuenten con experiencia podrán encontrar muchas sugerencias pues el libro es el caso de cómo un experto explica y enseña a principiantes.

Como propuesta de lectura: en la sección 1.6 Ideals for programmers, se explica un proceso general de programación y se hace notar la importancia de cómo pruebas, análisis, diseño y programación están relacionadas en dicho proceso. Por tanto, tal vez para una mejor lectura, sugiero que el sexto párrafo, el cual dice:

“We can describe the process of developing a program as having four stages:”

sería más claro si se lee de esta manera:

“We can describe the process of developing a program as having four activities:”

La desproporción práctica

2009-01-31T20:45:00Z

Un individuo o un pequeño grupo de personas tienen una idea o un sistema de ideas que suenan prometedoras y de las cuales se obtienen resultados notables. Luego, esas mismas ideas son adoptadas por las masas pero entonces se observan resultados de un mucho menor nivel de trascendencia.

He observado este patrón en muchos disimiles contextos, desarrollo de software, negocios, religión, por nombrar algunos.

¿Por qué esto es así?

¿Será una fijación de percepción mía tal que —como lentes de color— me obligan a observar algo donde no lo hay? Quizás.

¿Cuál podría ser otra explicación o sistema de interpretación razonable para este patrón de conducta entre seres humanos?

Una posibilidad es que como parte de la causa raíz de la situación se encuentre un desproporcionado enfoque en el aspecto práctico de todas las cosas. La popular creencia en que las consecuencias prácticas son el único criterio por el cual debe ser juzgado el conocimiento, el significado y lo valioso.

Sospecho que un enfoque obsesivo, desproporcionado y exclusivo en los aspectos prácticos de un asunto conlleva la mayor parte de la culpa.

¿Cuántos de nosotros podríamos de hecho explicar la diferencia entre teoría y práctica, entre teoría e hipótesis, entre conocimiento confiable y creencia?

“Aquellos quien están enamorados de la práctica sin teoría son como un piloto quien navega sin un timón o brújula y nunca tiene alguna certidumbre dónde está yendo. Práctica debiera siempre estar basada sobre un sólido conocimiento teórico”
-Leonardo de Vinci (1452–1519)

“El problema con la gente no es que desconozcan pero que conozcan tantas cosas que no son ciertas”
-Josh Billings (1818–1885)

Autenticación usando Windows Live ID

2008-12-31T18:03:00Z

La idea de un sistema operativo en una computadora digital es servir como un administrador de los recursos de cómputo para que las aplicaciones no tengan que se programadas tomando en cuenta el funcionamiento específico de un modelo particular, por ejemplo, de disco duro. Así, una aplicación puede invocar una función del sistema operativo, digamos CreateFile, para conservar información en el disco duro sin importar los detalles de modelo y marca del mismo.

Un sistema operativo es un conjunto de componentes de software, algunos de los primeros sistemas operativos se mantenían activos en su totalidad en memoria ROM en todo tiempo. ¿Recuerdan a Commodore? Otros sistemas operativos eran leídos en su totalidad y puestos en memoria RAM cuando se prendía la computadora ¿Recuerdan Apple IIe o Franklin? Luego MS-DOS (disk operating system) combinó el esquema, leyendo parte del sistema operativo en RAM al encender la computadora y parte en disco (la cual se leí por demanda). La combinación agrega también la posibilidad de que los componentes del sistema operativo residan en la red a la cual está conectada la computadora.

Esa idea es también parte del concepto de servicio Web y nos permite hablar de un sistema operativo de red, en combinación con un sistema operativo en memoria RAM o en disco duro.

Un servicio Web de este tipo que hoy en día las aplicaciones pueden invocar es el servicio de autenticación usando Windows Live ID.

Mejores estimaciones

2008-11-26T14:25:00Z

¿Qué se ha dicho que sea un rasgo de locura, de demencia o simple y sencillamente de total chifladura? “Repetir, vez tras vez, lo mismo y esperar que el resultado sea diferente”. Así me parece, como un serio trastorno, la conducta de muchas empresas privadas y públicas que, ignorando la historia de la actividad, se mantienen jugando ese pervertido juego del alcance y costo fijo para proyectos de desarrollo de software. ¿Qué tiene que pasar o cuánto dinero tiene que derrocharse para que entendamos que así no es como funciona esto?

Voy a dejar para después mis hallazgos de lo que creo hay en la raíz del problema. Por ahora, remito una recopilación de algunas ideas que han funcionado como parte de la solución al problema, es un artículo titulado “Mejores estimaciones” publicado en la revista Software Gurú del trimestre Agosto-Octubre 2008, página 52 (disponible gratuitamente en línea).