Programar como profesión empresarial

¿Por qué hablar de profesionalismo?

Cuando la profesión principal de un negocio hace uso de otras profesiones a veces la interacción no resulta tan clara y ocurren desencuentros, malentendidos o expectativas insatisfechas. En la búsqueda por la claridad en la interacción entre profesiones en ocasiones puede ser útil una sana controversia que promueva valoraciones críticas balanceadas y justas. La siguiente conclusión preliminar tiene la intención de promover la discusión racional sobre el profesionalismo en desarrollo de software en un contexto de negocio.

Riesgos de negocio y rendición de cuentas

Cada vez más empresas suelen tener al menos un departamento o una área de «Tecnologías de información (TI)» pues han determinado que necesitan aplicar la computación electrónica para los fines de su negocio. Si la administración de un negocio sigue la regla básica de mantenerse en su giro comercial y no desenfocarse en esfuerzos dispersos, entonces una pregunta prudente que no debe olvidarse es: ¿representa mi área de TI sólo un centro de costos o es un activo que permite mejores resultados empresariales?

Algunas áreas de TI también son responsables de desarrollar software aplicativo; es decir, el software concreto que procesa la información empresarial con las reglas del negocio en particular. Para crear dicho software la empresa decidirá entre contratar servicios externos o agregar programadores a su nómina, o un esquema mixto.

La decisión de agregar programadores a la nómina implica que además de conocer el giro principal del negocio ahora se requiere conocimiento sobre cómo administrar la actividad de programación de computadoras. Cuánto conocimiento adicional se requiere está en función de cuánta responsabilidad tendrían los programadores internos. Si el esquema de tal decisión es mixto y deja la mayor parte de la responsabilidad de crear el software empresarial en manos de un grupo externo de profesionales, entonces la empresa requiere menos conocimiento que si la mayor parte de dicha responsabilidad quedase en las manos del grupo interno.

Un esquema atinado tiende a designar la mayor parte de la responsabilidad a quien demuestra la mayor parte del profesionalismo; o sea, que cada quien se dedique a lo que mejor sabe hacer y en lo que mejor pueda rendir cuentas. Lo cual coincide con una regla básica de empresas exitosas: conoce tu oficio.

Si un esquema designa la mayor parte de la responsabilidad al grupo interno, entonces se requiere de una estrategia para el crecimiento profesional y para la retención del talento interno; de otra manera la cantidad de riesgo de negocio aumenta debido a un conocimiento subdesarrollado en la materia. Programar computadoras en el contexto de un negocio puede llamarse «creación de soluciones de negocio basadas en software» y profesar tal actividad, como cualquier otra profesión, requiere desarrollo constante de conocimientos. En otras palabras, un negocio sin profesión pone sus resultados en mayor riesgo.

Datos, información y conocimiento

Aquí hay otro riesgo que debe ser debidamente administrado: el primer tropiezo que hay que evitar es confundir conocimiento con información o con datos. Los datos pueden transmitirse de persona a persona e incluso transmitirse de manera electrónica. La información es una interpretación subjetiva de dichos datos. Por otro lado, el conocimiento humano no es algo que pueda transmitirse sino sólo puede ocurrir al desarrollarse de manera personal; es decir, el conocimiento ocurre en la persona que logra un entendimiento de algún aspecto de la realidad objetiva, la cual es intersubjetiva y verificable con independencia de cómo nos gustaría o quisiéremos que fuese esa realidad.

El conocimiento humano es algo que requiere elaboración y desarrollo paulatino (como el caso de software complejo) y no algo que pueda generarse de manera instantánea (aunque hay casos de software simple que sí es generable instantáneamente por medio de software más complejo).

Arquitectura empresarial

Por supuesto, una empresa de mayor tamaño requiere la coordinación de un mayor número de profesiones. De ahí la necesidad de algo llamado ‘arquitectura empresarial’ o la acción de diseñar una empresa en su contexto de mercado, sus profesiones y sus procesos, sus modelos financieros, etc.

Si una empresa apuesta en serio por contar con su propia capacidad empresarial para crear software, entonces deberá también apostar por la profesionalización interna de tal actividad. Es decir, por el desarrollo interno de profesionales de la creación de soluciones de negocio basadas en software y no sólo contar con departamentos de IT que justifiquen el argumento de Nicholas Carr en su artículo «IT Doesn't Matter» de mayo 2003 en Harvard Business Review.

Profesionalismo en desarrollo de software

Hasta donde alcanzo a ver a la fecha, y por mucho que sea la sorpresa inicial, aún no está claro qué tipo de profesión es la creación de software; pero si revisamos su incipiente historia de apenas 60-70 años entonces la sorpresa disminuye. No es una disciplina de ingeniería, y no pocos autores demuestran porqué nunca lo será, pero sí requiere la constante aplicación de conceptos ya bien definidos a situaciones concretas. No es del todo una ciencia que entendamos ya por completo y con la que se pueda controlar y predecir con exactitud toda causa y efecto relacionado, pero sí requiere mucha abstracción y conlleva patrones de pensamiento lógico-matemático. No es del todo un arte que sólo pocos iniciados puedan realizar sino que hoy en día está al alcance de muchos. Crear soluciones de negocio basadas en software es quizá aún una artesanía en evolución en forma, por ahora, de un oficio cuasi-gremial.

Sin embargo, una empresa necesita aprender a identificar a los practicantes de ese gremio artesanal, ya sea para reclutarlos o para referirlos durante el desarrollo de su propio talento interno. Un rasgo a identificar es la coherencia entre lo que piensan y lo que hacen; lo importante es no sólo decirse profesional de la programación de computadoras, sino demostrarlo con la liberación y la evolución sostenida de software de calidad que resuelva problemas a un negocio o le habilite nuevas oportunidades.

Una empresa puede identificar a quienes están en el giro de la creación de soluciones de negocio basadas en software por la calidad del software que son capaces de entregar. Son profesionales cuyo giro de negocio depende de crear confianza en la calidad de su software y suelen carecer de una red corporativa de emergencia que les cobije en caso de mala calidad. Tales practicantes, por medio del ejemplo, suelen contribuir semillas de lo que llevaría a esta artesanía a ser una profesión conocida y respetable —no parece que esta industria esté en ese punto aún; por ejemplo, es muy difícil todavía relacionar lo que hace un programador con lo que hace un neurocirujano, a pesar de que ambos manipulan cerebros con sus propias manos, ya sea un cerebro basado en silicio o uno basado en carbono, respectivamente.

La dimensión de la complejidad que conlleva la creación sostenible de soluciones de negocio basadas en software es tal que le exige respeto a quien la contempla y le invita a la humildad. Por lo que otro rasgo de un practicante es que cultive activamente su propio nivel de conciencia sobre tal complejidad y en aprender cómo otros la abordan y la administran de manera sostenible. Por tanto, nadie que afirme altivamente dominar por completo esta profesión es realmente un practicante del gremio aludido aquí; por supuesto, puedo estar equivocado.

Además del cultivo personal, un practicante se enfoca también en el cultivo de otros practicantes a su alrededor a través de valores como el diálogo, la comunicación y la cooperación sobre aspectos de la profesión compartida. Cada voz cuenta y es preferible hablar cara a cara con regularidad en lugar de sólo a través de documentos. Someter las ideas y el trabajo propios a la crítica de otros y escucharles con atención es un hábito del profesional practicante; así como realimentar lo más atinadamente posible a los demás.

El desarrollo del profesionalismo implica muchas cosas que giran alrededor de los efectos y acciones derivadas del verbo «profesar», entre lo cual, en este caso, está la intersección entre ingeniería, ciencia y arte.

Referentes

Los practicantes del gremio aquí aludido suelen investigar con esmero y aprender de las obras de diversos autores profesionales en la materia. Algunos de esos autores a lo largo de la historia de esta profesión han sido: Edsger W. Dijkstra, Kristen Nygaard, Niklaus Wirth, Ole-Johan Dahl, Dennis M. Ritchie, Donald E. Knuth, C.A.R. Hoare, Bjarne Stroustrup, Larry L. Constantine, Alan Kay, Bertrand Meyer, Adele Goldberg, Frederick P. Brooks, Jr., David L. Parnas, Tom DeMarco, Gerald M. Weinberg, Tom Gilb, Barry Boehm, Winston W. Royce, Caper Jones, Jim Gray, David Harel, Barbara Liskov, Rebecca Wirfs-Brock, Peter Coad, Sally Shlaer, Stephen Mellor, Andrew Koenig, Ivar Jacobson, Grady Booch, Ward Cunningham, Robert C. Martin, Erich Gamma, Jeff Sutherland, Kent Beck, Dave Thomas, Ken Schwaber, Andrew Hunt, Steve McConnell, Alistair Cockburn, Jim Highsmith, etc.

Conclusión preliminar

En conclusión, si al arquitectar una empresa se contempla contar con la capacidad de crear soluciones de negocio basadas en software, entonces también se necesita profesionalizar tal función de manera interna. La profesión de crear soluciones de negocio basadas en software, como parte de una empresa o como negocio por sí mismo, suele emerger con pauta propia y sus practicantes pueden identificarse por la calidad de su software, por su auto-cultivo y por su trabajo cooperativo.

Depuración del proceso de desarrollo

Si me exijo rendir cuentas de mi profesión y de mi rol en esta industria del software, y partiendo de una conciencia mínima de lo que es ejercer la arquitectura de sistemas, entonces también me obligo a mí mismo a intentar aportar más ante ese reto que todos compartimos: ¿cómo mejorar la calidad de los sistemas y el nivel de servicio hacia clientes y usuarios?

Estoy de acuerdo en que suele ser inútil imponer o exigir la transformación de los demás si a la par no exijo los cambios pertinentes de parte propia. Pero si tomamos la pauta de «no imponer» como principio profesional, entonces por consistencia habría que resolver la cuestión de por qué los clientes y usuarios tienen que padecer la imposición de un nivel de calidad aplicativa por debajo de sus expectativas.

Algunas personas cambiamos en la medida en que tomamos cuenta de que somos parte del problema. Esa conciencia, en ocasiones, llega a través del diálogo. Pero hasta para dialogar de manera efectiva se requiere preparación y no ignorar los básicos; por ejemplo, prestar atención a las razones del otro. En ese sentido, como sugerencia y como tan sólo una parte de la estrategia ante el reto de la calidad, si podemos indagar y enfrentar las razones de fondo en el proceso de desarrollo que ha producido el presente nivel de calidad, entonces sería como hacer “debug” a ese proceso. Tal “process debugging” representa una práctica aceptable en la profesión; ejemplos: Software Engineering Classics: Software Project Survival Guide / Debugging the Development Process / Dynamics of Software Development.

Otro estilo de vida

Sí, ya sé, muchos ya ejecutan sus proyectos de desarrollo de software de tal manera que cada día salen del trabajo después de ocho productivas horas de muy gratificante esfuerzo intelectual, y que viven plenamente otros aspectos de su vida personal en el tiempo que antes pasaban en onerosas y estériles actividades con poco o nulo progreso. Además, liberan software de calidad en la pauta acordada y se aproximan mucho más, y más rápido, al valor de negocio que en realidad se requiere. Todo eso ya lo sé, pero mi punto al tocar el tema es que aún muchos proyectos están atrapados en esquemas anticuados y, por tanto, hay muchos clientes y usuarios que aún sufren las consecuencias de enfrentarse a software creado como si fuese un producto de la manufactura de inicios del siglo pasado.

Programar es entender

Título alternativo: Programar computadoras es más, mucho más, que sólo escribir código.

En torno al aprendizaje de la programación y su relación con las oportunidades de negocio basado en software me llega a la mente la frase «If you build it, they will come.», la cual aplica para algunos casos en que la sola presencia de una posibilidad técnica provoca el brote de una necesidad que de pronto requiere satisfacción; Whatsapp sería un caso, saber programar jugó un papel, por supuesto, pero con “programar” no digo sólo escribir el código sino, además, entender los detalles de «push notifications» a cabalidad; lo cual jugó un papel clave en el modelo aplicativo y, por tanto, en el modelo de negocio, sus alcances y sus limitantes. Sabemos que la frase no es regla sino es más un golpe de suerte, pues hay muchos casos de lo contrario; por ejemplo, ¿recuerdan el dispositivo Newton, de Apple?, ¿NeXTStep?, ¿Oslo, de Don Box?

En torno a las oportunidades de negocio y su relación con el profesionalismo comentaré de manera sucinta que en ocasiones el valor a largo plazo en los negocios suele estar bien cimentado y apuntalado sobre un muy alto nivel de calidad en lo desarrollado. Semejante expectativa de calidad está relacionada a una no menor expectativa en calidad profesional. Si la calidad en software es igual a la calidad profesional entonces los programadores están entre quienes ejercen altos estándares en conocimiento científico sobre cómputo digital y también en ética profesional; por supuesto, estándares que no incluyen incurrir en concesiones por la sola razón de intereses económicos parciales (“mi cuota, mis commitments, mi compliance, mis bonos,…, y que los clientes sirvan a mis intereses en primer lugar.”) a costa de arriesgar la calidad y el prestigio profesional. Los negocios pueden mantenerse, además, con buen profesionalismo, como lo alude Bjarne Stroustrup en una plática reciente cuando muestra un tipo de código en C++ y menciona que ese tipo de código ha sostenido la vida profesional y económica de no pocos en esta industria.

Un mejor profesionalismo no debe significar más burocracia; como, por ejemplo, es el patético caso real de una organización que anuncia con gran pavoneo que su nivel de ingeniería de software ha mejorado pues ahora su métrica de documentos cumplidos para lograr una certificación ya llegó a 6,000 documentos. Un mejor profesionalismo implica mejorar tanto teoría como práctica. Si se cojea de una de ellas el resultado es sólo caminar en círculos, y no la mejora en calidad profesional.

Un cierto anti-intelectualismo imperante en algunos ambientes en nuestra industria provoca un rechazo inmediato ante la palabra ‘teoría’, pero pienso que sólo es una trampa del lenguaje; es decir, usan la palabra ‘teoría’ cuando en realidad quieren decir otra cosa. Pienso que con frecuencia quieren decir «falta de progreso» en un proyecto donde sólo hay «exceso de actividad». Entonces la trampa está en confundir cantidad de actividad con cantidad de progreso.

Por el contrario, cuando digo mejorar la práctica teórica me refiero a repensar una determinada estructura conceptual con el objetivo de mejorarla o reemplazarla por una más adecuada. Es decir, trabajar la teoría es entender mejor lo que está pasando detrás de las acciones, lo cual es aquello que en buena medida las gobierna. En otras palabras, no es suficiente hacer algo, sino también es indispensable entender mejor por qué se hace. Para ilustrar lo que intento decir me apoyaré en lo que explica el Dr. Raj Shah con su ejemplo de la multiplicación: Why is Math Different Now.

El progreso de un aprendiz

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.

Carta a la tía Margarita o del software para mejorar tu negocio

Querida tía Margarita* —o estimado emprendedor que utilizarás software para tu negocio pero apenas sabes cómo encender una computadora:

*La tía Margarita es un apelativo utilizado para referir a quien es lego en las ciencias del cómputo electrónico-digital.

Me has platicado del éxito en tu negocio después de años de dedicación. Me dices de tus ahorros y de tu intención de invertirlos en un proyecto para integrarte al mundo de las posibilidades ofrecidas con los llamados teléfonos inteligentes, las nuevas computadoras tablets y otros dispositivos electrónicos; tecnologías que tienden a funcionar en una interconexión cada vez más ubicua a través de Internet. Dices que es un proyecto inevitable si no quieres perder el éxito obtenido. Además, estás decidida a extender tu éxito. Muy bien, considera lo siguiente.

Nicholas Carr dice (IT Doesn't Matter, mayo 2003, Harvard Business Review) que las tecnologías de información se han convertido en materia prima para los negocios y ya no representan un criterio de diferenciación competitiva. No le ha faltado razón. Así que si quieres colocarte a la par de tu competencia quizá sólo necesites adquirir una solución existente. Si te alcanza y tienes evidencia de que satisface tus necesidades prioritarias entonces es una opción viable. Si buscas un objetivo más ambicioso para diferenciar tu negocio entonces piensa en crear una solución a tu medida.

No digo que sea fácil integrar algo existente sino que, en definitiva, la creación de una solución basada en software para problemas de negocio representa palabras mayores en términos de complejidad. La organización Standish Group investiga las estadísticas para este tipo de proyecto y publica los resultados de su sondeo en el Chaos Report. En la categoría de resultado general los proyectos se agrupan en exitosos, deficientes y fallidos. Un proyecto exitoso logra sus objetivos de manera completa, lo hace a tiempo y dentro de su plan financiero. Un proyecto deficiente fracasa en cualquiera de esos criterios y un proyecto fallido no alcanza ninguno. Los proyectos inician con las mejores intenciones pero muchos fracasan. La fracción de proyectos que logran los tres criterios de éxito, según dicho reporte, gira alrededor de un tercio.

Ese reporte incluye los factores de éxito, suelo agruparlos en las siguientes categorías: el perfil del personal involucrado, el proceso de creación, la estrategia de diseño y la tecnología utilizada. Al considerar su impacto sobre el resultado, los factores en cada categoría tienen un impacto superior comparado con el de los factores de la categoría sucesiva. Por ejemplo, si la estrategia de diseño es impecable pero no se cuenta con un proceso adecuado para realizarla entonces su impacto es marginal; lo mismo ocurre si el proceso es muy bueno pero el personal no sabe cómo adecuarlo sobre la marcha al dinamismo de los negocios.

Las personas y su capacidad para enfocar tanto ideas generales como detalles específicos, y comunicarlos efectivamente, representan el factor más determinante para el éxito de tu proyecto; empezando por ti misma. Te sorprenderá el nivel de detalle al que es necesario especificar los requisitos para que puedas en efecto verlos realizados en una aplicación tecnológica. Si no estás dispuesta a enfrentarte a este tipo de exigencias, y mantienes tu decisión de realizar tu proyecto, entonces quizá debas reservar no poco dinero para financiar los litigios comerciales por incumplimiento de contrato. No querrás usar tus ahorros para eso.

Si el caso fuese una cirugía a cerebro abierto entonces buscarías al mejor neurocirujano que puedas conseguir. El caso de tu proyecto no es tan distinto si consideramos el tipo de esfuerzo intelectual y esmero requeridos. Habla no sólo con administradores sino directamente con quienes tienen la capacidad para crear, con su mente y manos, las piedras angulares del proyecto: el nuevo modelo de negocio y los componentes técnicos de alta calidad que sostendrán tu solución tecnológica.

Todavía hoy hay consultorías cuya organización se basa en un taylorismo posindustrial; es decir, un modelo orientado en analogía con la producción al estilo de la revolución industrial (Frederick W. Taylor) y aplicado a la producción en la revolución de las nuevas tecnologías de la información (el periodo posterior al industrial). Para funcionar, los trabajadores debían ser baratos y de muy bajo perfil intelectual, realizar trabajo mecánico repetitivo en una línea de producción —cuales partes de la máquina fabril— y obedecer los estrictos dictados del grupo de administradores de la fábrica. Quizá te sorprenda saber que el esquema actual en creación de soluciones basadas en software, en muchos casos, no está radicalmente alejado, en los hechos, de tal régimen. Por lo cual no me sorprende la explicación de fondo atrás de la banal excusa: “no le podemos dar el servicio pues se cayó el sistema”.

Los factores para el éxito, cuyas categorías ya mencioné, son claves para entender qué tipo de actividad es crear software. Formular software es una actividad reciente que inició hace unos sesenta años, y la industria del software ha adoptado opiniones caducas de la industria de manufactura de siglos pasados. Por ejemplo, la idea de división de trabajo; esta idea está detrás de puestos de trabajo como ‘analista’, ‘arquitecto’, ‘diseñador’, ‘programador’, o ‘tester’ (que realiza pruebas). Estos puestos coinciden con las etapas del modelo en cascada (secuencia lineal de etapas sucesivas) para el ciclo de vida del software: análisis, arquitectura, diseño, programación y pruebas. Quizá te sorprenda saber que Winston W. Royce, el supuesto inventor del modelo en cascada, jamás dijo que ese modelo funcionaría. De hecho, en su publicación original advierte en contra de intentar una secuencia lineal de etapas sucesivas. En años subsiguientes afirmó que su trabajo fue gravemente malinterpretado.

La creación de software tiene mucho por madurar como profesión y como industria. Su actual imagen de glamour se debe más al buen trabajo de publicistas y comerciantes oportunistas que a una ética profesional interna y madura. Por supuesto, esta industria debe financiar su proceso de madurez de sus propios bolsillos y no a costa de los ahorros de personas como tú; es decir, no permitas que malformadas opiniones arruinen tu proyecto.

Necesitarás una estrategia para formarte mejores opiniones al respecto: una estrategia para distinguir entre conocimiento confiable y mera opinión. Pues en un tema de moda, como lo son las computadoras e Internet, con mucha frecuencia las meras opiniones son las más vociferadas. Para pensar tu proyecto no digo que logres la erudición en el tema sino que salgas del analfabetismo computacional. De otro modo serás un factor de riesgo para tu proyecto pues fomentarías interpretaciones erróneas de lo que significa el avance y los hitos que cimentan el éxito; por ejemplo, si al inicio del proyecto exiges una calendarización de todo el proyecto y luego la usas para juzgar avances y retrasos entonces estarás midiendo cantidad de actividad pero no cantidad de progreso. Para no tropezar debes practicar tres hábitos del conocimiento confiable: la duda, la razón y la experiencia. Entre más destreza tengas ejerciendo esos hábitos más oportunidades tendrás de lograr cada vez mejores opiniones en el tema.

Tener una mera opinión es algo muy fácil, basta con dejarse llevar por la corriente actual de la cultura popular, y esa facilidad revela, en parte, por qué son tan frecuentes. Los problemas inician por mantener y propagar una opinión obtenida de esa manera y, para agravarlos, por afirmar que tal opinión es propia y que debe defenderse —cuando ni es propia ni debe defenderse sino evaluarse. La mera opinión será para tu proyecto como la comida chatarra es para tu salud: dañina. Por otro lado, lograr conocimiento confiable implica un trabajo muy duro. En tu caso no hay motivo para amedrentarse pues ya estás acostumbrada a ese tipo de trabajo; asimismo, ¿cómo podrías justificar el apego a una mera opinión si tú no eres un caso desesperado sin recursos ni salud?

La mera opinión y el conocimiento confiable suelen entremezclarse; por ejemplo: “un proyecto de software es igual a uno para hacer un edificio o un puente, y ambos se administran igual: al inicio hay un conjunto fijo de requerimientos, un costo total fijo, y un plan para todo el proyecto.” Si bien es cierto que los requerimientos, el costo y la planeación son muy importantes, también es cierto que una mejor aproximación a esos aspectos resulta de procesos empíricamente controlados, y no sólo por medio de racionalizaciones prematuras.

Un proceso empíricamente controlado no es controlado sólo por racionalizaciones «a priori», es decir por imaginar el futuro con independencia de la corroboración de la experiencia —lo cual sigue siendo una tendencia mayoritaria en la industria de hoy, con grandilocuentes arquitecturas por anticipado, gráficas de Gantt expresadas en meses o años, y estrategias y tácticas para la gestión del riesgo basadas en el miedo. Por otro lado, un proceso empíricamente controlado surge de estrategias y tácticas «a posteriori» ejecutadas frecuentemente y en lotes pequeños. Un ejemplo se puede encontrar en ejecuciones musicales y representaciones teatrales. Si te interesa aumentar la confianza en el éxito de tu proyecto, entonces «¡ensayar, ensayar, ensayar!» es un hábito esencial para lograr excelentes resultados tanto en representaciones teatrales como en la creación de soluciones empresariales basadas en software. Por ejemplo, la publicación de la solución tecnológica a tus clientes y proveedores debe resultar muy bien, por lo que ensayos realistas de ese procedimiento deben ser ejecutados, temprano y a menudo, antes de tocar al usuario final.

Hay mucho más que debes considerar para no ser parte de las estadísticas de proyectos fallidos o deficientes, donde los inversionistas obtienen muy poco o nada a cambio de su inversión.

El Programa para el Desarrollador Reflexivo - ¿de qué va?

¿Cuál es la oportunidad?

El programa tiene la intención de asistir como un compañero de entrenamiento (sparring partner) para el profesional individual. El programa propone una comunidad de indagación sobre el tema del profesionalismo en la creación de soluciones de negocio basadas en software. En dicha comunidad el individuo puede comparar notas con otros de una manera abierta y sin jerarquías de ninguna clase.

Un objetivo es asistir al individuo en su intento por adquirir mayor conciencia de su condición personal ante una concepción amplia del profesionalismo. Lo cual incluye, entre otros temas, familiarizarse con los perennes problemas del conocimiento en general y con las manifestaciones de dichos problemas en el contexto de la creación de soluciones.

Para iniciar, un efecto colateral propio de la dispersión del conocimiento: entre más es difundido más escaso se hace su cabal entendimiento. Por lo cual es muy probable que la idea que tengamos de un tema dado, por muy sólida que creamos tenerla, sea tan sólo un pálido, superficial y distorsionado fragmento de la idea originalmente concebida y desarrollada.

Por tal efecto colateral podríamos con frecuencia actuar sobre la base de conocimiento deficiente en el caso promedio, o de meras opiniones del todo desatinadas en el peor caso. El problema radica en permanecer con conocimiento de esa calidad como base de nuestras acciones al ejercer nuestra profesión. Por lo que la búsqueda del profesionalismo debe incluir, como tarea recurrente, el examen crítico de la calidad real del conocimiento que creemos tener de las ideas más importantes que guían nuestra conducta profesional. Por ejemplo, la noción acerca de «análisis» o de «diseño», ¿son actividades?, ¿son etapas?, ¿cuáles estructuras teóricas sostienen a las posibles respuestas?

Ciertamente, un entendimiento mejorado de las ideas que aplicamos produce una práctica profesional mejorada. Buscar más enseñanza podría mejorar el entendimiento. Pero, si los canales institucionales para la dispersión del conocimiento, como los sistemas derivados históricamente de la escolástica —o filosofía de la escuela—, no fuesen parte de la causa que distorsiona dicho conocimiento, entonces podríamos decir que esos canales bastan para mejorar el entendimiento. Por supuesto, no bastan. He aquí el nicho de oportunidad para el Programa para el Desarrollador Reflexivo.

¿Cómo mejorar el entendimiento?

La propuesta central es que el profesional individual puede convertirse en su propia influencia primordial para mejorar el entendimiento de sus propias ideas. No obstante, es mucho más fácil decirlo que lograrlo. La dificultad radica en el poco espacio mental que suele quedar al individuo después de ser invadido por un alud de información de todo tipo —por voluntad propia o no— y desde múltiples conductos simultáneos en nuestra actual sociedad cada vez más interconectada. El Programa para el Desarrollador Reflexivo reconoce que más información no equivale a más entendimiento y, por tanto, abre un espacio para que el individuo pueda pausar, analizar sus ideas, cuestionarlas y desarrollar la reformulación que resulte necesaria de las mismas.

Pues el problema no es lo que desconocemos sino lo que tenemos por cierto pero que resulta distorsionado o por completo falso. Es decir, el problema no es que ignoremos muchas cosas o que carezcamos de información en abundancia sino mantener meras opiniones debidas a malinterpretaciones de la información ya recibida. Por lo que el programa propuesto no sólo es acerca del aprendizaje autodidacto sino acerca de la teoría y la práctica de la auto-reeducación.

El programa propone entender la auto-reeducación, principalmente, como des-aprendizaje, pues eso precisamente se requiere para mejorar el entendimiento. Deshacerse de malinterpretaciones que estorben a la asimilación adecuada del conocimiento es un paso esencial para mejorar el entendimiento. En otras palabras, y como algunos estudiosos de la educación ya lo han apuntado, el analfabeto contemporáneo no es el incapaz de leer o escribir sino el incapaz de aprender, desaprender y re-aprender.

Siguientes pasos

El Programa para el Desarrollador Reflexivo consiste de una serie de conversaciones en las cuales se indaga la realidad de situaciones concretas, situaciones con relevancia profesional para los participantes. Por ejemplo, la situación puede ser el diseño de una estrategia para manejo de excepciones en una solución en desarrollo, o las dependencias entre componentes de lógica de negocio y componentes de acceso a datos para el adecuado control de transacciones distribuidas, o puede ser el análisis de una capacidad funcional autónoma o semiautónoma para ser liberada al negocio con independencia de otras capacidades, etc. El Programa para el Desarrollador Reflexivo propone un conjunto de procesos de análisis y de síntesis aplicados a situaciones concretas y pertinentes, no busca hacer prescripciones abstractas ilustradas con ejemplos triviales sin conexión con la realidad de los participantes; es decir, el programa busca identificar defectos en cómo pensamos, no busca prescribir qué debe ser pensado.

Para el caso de principiantes en el programa, el primer paso suele consistir en invitarles como observadores de una conversación donde alguien experimentado reflexiona sobre alguna situación concreta. Así los principiantes se familiarizan con los protocolos típicos para identificar contextos, para discutir estructuras o presuposiciones conceptuales, juicios, argumentos, falacias, análisis empíricos, modelos experimentales, fuentes a las cuales recurrir por más información, etc., y observan la aplicación de estándares intelectuales de rigor sistémico.

Para el caso de no principiantes en el programa, el siguiente paso suele consistir en preguntarles por alguna situación concreta para la cual quieran iniciar el proceso cooperativo de reflexión.

La continuación de este blog...

He estado publicando notas en Español acerca de desarrollo de software en el siguiente blog*:  http://blogs.msdn.com/destreza/

Donde continúo reflexionando en la convergencia del ejercicio filosófico y la esencia en la actividad de crear programas para computadoras destinados a ser parte de la solución a problemas humanos.

*blog es una contracción de ‘web log’: un diario o bitácora pública como medio de expresión particular.

Arquitectura de software y el pensamiento mágico

El tema de arquitectura de software me ha interesado y he hecho investigación al respecto desde hace algún tiempo, movido simplemente por la curiosidad de entender uno más de los fenómenos en la sociología dentro de la industria de formulación de software, y su relación con la sociología con otras industrias que también se fundamentan en tecnología. Se me ocurren dos explicaciones para mis conclusiones provisionales: o estoy viendo visiones recurrentes que mi torpe mente impone sobre áreas distintas de mi percepción o en realidad sí existen patrones en la conducta humana que se observan como resultado de un estado de conciencia inmaduro o edad mental temprana (sin tener relación alguna con la edad física).

De tal forma que así como niños nos ilusionamos y adoptamos gustosamente creencias de lo sobrenatural o etéreo por las cuales estamos dispuestos a doblegar nuestra voluntad con tal de conseguir cosas mágicamente (e.g., Santa Claus, Reyes Magos, y creo que mejor le paro aquí de contar), así también con gran facilidad nos podemos encontrar como adultos —aunque no adultos mentalmente— adoptando gustosamente creencias similares en grado por las que estamos dispuestos a cancelar nuestro pensamiento independiente y perseguir aquello que nos prometa cosas que llegarán mágicamente, e.g., “Write once, run anywhere” de Java, SOA si sólo si Enterprise Service Bus, la fábrica de software lo hace por ti, los diagramas UML son el diseño del software, lo que dice la autoridad es verdad indiscutible, etc., incluyendo —con razón— Arquitectura de software es igual a lo que hacen los arquitectos astronautas (remitirse a “architecture astronautics” y Don't Let Architecture Astronauts Scare You).

Dadas así las cosas, en tanto que cualquiera de nosotros base su educación (que es diferente de nuestra escolaridad) en, por ejemplo, la información de mercadotecnia, se ha colocado a sí mismo —por gusto propio— más allá del alcance de cualquier ayuda efectiva pues no acostumbra aplicar ni una mínima dosis de pensamiento crítico a lo que deja permanecer en su parte más íntima: su mente.

Precisamente la semana pasada estuve participando en una discusión pública acerca de arquitectura de software, algunos puntos relevantes de la discusión los publiqué aquí: Software architecture is much more than structure (incluye referencias a publicaciones pasadas al respecto).

Desarrollo moderno de software

Muchos practicantes de diseño y desarrollo de software, después de varios años de experiencia, llegan a conclusiones semejantes acerca de la naturaleza de esta actividad.

El propósito de este blog es tratar de describir dichas conclusiones y presentar los hechos lo más objetivamente posible.

Así, tal vez cuente como un granito de arena para que las organizaciones que hacen uso del desarrollo de aplicaciones de software y que busquen logros adicionales soliciten a su personal técnico o a sus proveedores una mentalidad distinta a la mentalidad tradicional, una mentalidad que incluya las conclusiones a las que han llegado muchos practicantes profesionales del diseño y desarrollo de software.