Skip navigation
1 2 3 Previous Next


63 posts


Silicon Valley Is Right — Our Jobs Are Already Disappearing



Stephen Hawking says that “we are at the most dangerous moment in the development of humanity” and that the “rise of artificial intelligence is likely to extend job destruction deep into the middle classes, with only the most caring, creative or supervisory roles remaining.”

Sam Hinkie, the smartest man in sports and a Stanford grad, asks, “How are you preparing your kids for a life with 60% unemployment?”

Sam Altman, the head of Y Combinator, is so convinced that we’re going to need to figure out new ways of providing people with a means to live that he’s giving ~$20k each to 1,000 people in Oakland for a year just to see what they do with their new jobless income.

Literally the smartest people in the world think an unprecedented wave of job destruction is coming with the development of artificial intelligence, robotics, software and automation. My friends in Silicon Valley have read the Second Machine Age and Rise of the Robots and they see a wave coming.

The White House published a report last month that reinforced this view. Some of the headline stats:

  • 83% of the jobs where people make less than $20 per hour will be subject to automation or replacement.
  • Between 9% and 47% of jobs are in danger of being made irrelevant due to technological change, with the worst threats falling among the less educated.
  • Between 2.2 and 3.1 million car, bus and truck driving jobs in the U.S. will be eliminated by the advent of self-driving vehicles.



Source: Executive Office of the President of the United States; Artificial Intelligence, Automation, and the Economy; December 2016

Read that last sentence again: we’re confident that between 2 and 3 million Americans who drive vehicles for a living will lose their jobs in the next fifteen years. Self-driving cars are the most obvious job-destroying technology, but there are similar innovations ahead that will dislocate cashiers, fast food workers, customer service representatives, groundskeepers and many many others in a few short years. How many of these people will be readily employable elsewhere?

Okay, you’re thinking. But isn’t this all still in the somewhat distant future, since unemployment is only 4.6% according to the headlines? Actually, automation has already eliminated about 4 million manufacturing jobs in the U.S. since 2000. And instead of finding new jobs, a lot of those people left the workforce and didn’t come back. The U.S. labor force plummeted by about 10 million during the same period, down to levels not seen in decades. The labor participation rate is now at only 62.7%, a rate right below El Salvador and right above the Ukraine:



Each 1 percent decline in the labor participation rate equates to approximately 2.5 million Americans dropping out. The number of working-age Americans who aren’t in the workforce has surged to a record 95 million, up almost 500,000 in the last month alone, with many of these being factory workers.

Yes, there are 95 million working-age Americans no longer in the workforce. The Great Displacement is already here and is set to accelerate.

High rates of unemployment are linked to higher rates of substance abuse, domestic violence, child abuse, depression and just about every other social ill. Despair, basically. Note the recent spike in drug and opioid overdoses in the U.S. If you care about communities and our way of life, you care about people having jobs. This is the most pressing economic and social issue of our time.

Our economy is evolving in ways that will make it more and more difficult for people with lower levels of education to find jobs and support themselves.

It’s a boiling pot getting hotter one degree at a time. And we’re the frog.

I run an organization, Venture for America, with the mission of helping to create 100,000 U.S. jobs by 2025. We do this by helping growth companies access talent and training the next generation of entrepreneurs. We are taking some of the strongest young people in the country and saying, “Hey, use your talents to do some good and build businesses in Detroit, Birmingham, Baltimore, New Orleans, Cleveland, Philadelphia or some other U.S. city that could use a boost.” We’ve had some incredible success stories with people building multi-million dollar businesses that have hired dozens or even hundreds of people, including some low-skilled manufacturing workers.

We’ve trained over 500 aspiring entrepreneurs to work in eighteen cities around the U.S., and are now recruiting executives from Silicon Valleycompanies who want to help. We saw the decline in American entrepreneurship in markets around the country and resolved to do something about it.

I’m proud of everything that we do. But I feel increasingly like we’re working on islands of relative prosperity that are shrinking beneath our feet.

Every business will hire the very best people it can find — particularly startups. When our entrepreneurs start companies and expand, they generally aren’t hiring the down-on-his-or-her-luck-marginal-worker-in-need-of-a-break. They’re hiring the strongest contributors with the right mix of qualities to help an early-stage company succeed. The majority of the startup jobs that we’re helping to create essentially require a college degree. That excludes 68 percent of the population right there. And some of these companies are lifting further inefficiencies out of the system — reducing jobs in other places even while hiring its own new workers.

I’m reminded of a scene in The Hard Things about Hard Things, when Ben Horowitz meets with his two lieutenants. He says to one of them, “You’re going to do everything in your power to make this deal work.” Then he turns to the other and says, “Even if he does everything right, it’s probably not going to work. Your job is to fix it.”

That’s where we’re at. Unprecedented things are happening in real-time and starting to wreak havoc on lives and communities around the country, particularly on those least able to adapt and adjust.



We should do all we can to reduce the worst effects of the Great Displacement — it should be the driving priority of government and non-profits for the foreseeable future. We should invest in education, job training, apprenticeships, relocation, entrepreneurship, matching people to opportunities, tax incentives to hire — anything to help make hiring and retaining workers appealing.

And then we should assume that, for millions of people, it’s not going to work. Uber is going to get rid of its drivers as soon as it can. Its job is not to hire lots of people — its job is to move customers around as efficiently as possible.

One programmer, Labib Rahman, said to me recently that “any responsible technologist has to be for providing people a universal basic income to make ends meet.” He knows what’s coming.

Before long, we’re going to have to rethink the relationship between work and being able to feed yourself. And then figure out how to convey the psychic and social benefits of work in other ways.

It’s one reason why what Sam Altman is doing in Oakland is so fascinating and important. He’s basically piloting what the government should be doing so there will be relevant data when the need is too pressing to ignore. Many of my friends think that people will just chill out if you give them free money. I tend to think they’ll make the most of it and try to better themselves and their future. Sam is going to find out for all of us.

Will our jobless future look more like Star Trek or Mad Max? If you squint a little, you can see which way we’re headed.

As William Gibson says, “The future is already here — it’s just unevenly distributed.” The future of automation and job loss is right now.





Sientes que estás de mal humor y no estás rindiendo en el trabajo? Éstas son algunas razones para ser menos productivo que pueden estar afectándote.


La mayoría de los consejos para ser más productivos siempre tienen que ver con cosas como: dormir la cantidad de horas adecuadas, hacer ejercicio o pasar tiempo de calidad con nuestra familia. Sin embargo, existen otro tipo de aspectos que influyen en el sujeto de forma inconsciente y que pueden afectar su estado de ánimo para ser más productivo o no. Por lo que, si no encuentras razón aparente para estar desganado y letárgico, entonces tu ánimo y motivación pueden estar relacionadas con algunas de las siguientes razones.

1. Postura

Algunos estudios han encontrado que una buena postura no solo mejora la salud y apariencia física, sino también influye de manera considerable en nuestro estado de ánimo. A diferencia de lo que podría pensarse, es nuestra postura la que determina cómo nos sentimos anímicamente y no al revés. Las personas que suelen desplomarse en un asiento o encorvarse al caminar tienden a experimentar una disminución en los niveles de energía en comparación con las personas que siempre mantienen una posición un tanto más erguida.

2. Desorden

Razones para ser menos productivo

Aunque muchos opinen lo contrario, la investigación ha demostrado que a mayor desorden, menor capacidad de concentración obtenemos. Esto sucede porque nuestro cerebro invierte tiempo considerable en procesar lo que ve a través de nuestros ojos. Buscar o localizar un artículo consume recursos que podrían estar siendo utilizados para concentrarnos en una tarea específica. Este mismo principio se aplica al desorden digital del escritorio del ordenador, la desbordada bandeja de entrada y las constantes notificaciones en los dispositivos móviles.

Sólo unas cuantas personas logran conseguir trabajar sobre varias cosas a la vez, la gran mayoría, por otro lado, debe empezar a gestionar su tiempo, limpiar el desorden y concentrarse en una sola tarea para tener un enfoque más productivo.

3. Luz artificial

Cantidad no siempre es sinónimo de calidad. Y en este sentido, hay muchos factores que afectan la calidad del sueño, pero la luz artificial es una de las cosas sobre las que tenemos mayor control. La exposición a la luz artificial por las noches interrumpe la producción de melatonina, hormona responsable de regular el estado de ánimo y el sueño. Las luces azules que emiten las pantallas de muchos dispositivos electrónicos afectan la producción de melatonina lo que, indudablemente, produce alteraciones en el sueño. Así es que si quieres tener un buen descanso por las noches será mejor que apagues tu lámpara de mesa y pongas boca abajo tu móvil para no sufrir distracciones.

4. Colores

Razones para ser menos productivo

Así como nuestro cuerpo reacciona con la luz, también lo hace con las diferentes tonalidades del color. Por ejemplo, el color rojo está asociado al peligro y la amenaza, razón por la cual, muchos señalamientos de tránsito están pintados con este color. Según la psicología del color, la combinación de azul y verde es la opción ideal para el lugar de trabajo, pues nos evoca tranquilidad y concentración, por lo que podrían considerar pintar tu espacio de trabajo con estos tonos o cambiar el fondo de pantalla de tu ordenador.

5. Estaciones del año

Después de saber cómo afecta la luz a los niveles de melatonina, es más probable que puedas comprender que algunas estaciones también podrían influir en tu estado de ánimo. Las personas que viven en climas fríos pueden sufrir de Trastorno Afectivo Estacional (SAD), que es una forma de depresión que normalmente se derivan de la falta de luz durante el invierno. El SAD afecta al 6% de la población estadounidense cada año, con lo que está claro que nuestros niveles de humor y productividad disminuyen en cierta medida durante los meses de invierno más oscuros.

Una forma más rara de SAD es la que sufren las personas que viven en países cercanos al ecuador, donde el aumento de la temperatura y la humedad durante el verano también puede ser causa de depresión. Las personas con SAD de verano se vuelven cada vez más agitadas por el calor insoportable, y prefieren esconderse del calor del verano en casa. Esta interrupción en su rutina puede, poco a poco, influir de manera negativa en su estado de ánimo y productividad.

6. Compañía

Razones para ser menos productivo

El ser humano es un ser social por naturaleza y, en este sentido, las buenas relaciones sociales determinan, en buena medida, nuestro bienestar mental. Elcontagio emocional, tendencia natural a tomar inconscientemente las emociones de los demás, nos concedió el don de la empatía, el cual es absolutamente necesario para crear relaciones profundas. Debido a esta tendencia, es común que nos encontremos positivos cuando estamos rodeados de personas optimistas y alegres y, por el contrario, nuestro estado de ánimo tiende hacia la depresión cuando las personas con las que convivimos están llenas de emociones negativas.

7. Redes sociales

La compañía virtual afecta nuestro estado de ánimo de la misma forma en que lo hace la compañía real. Se ha encontrado que, un mayor uso de las redes sociales (Facebook) se traduce en una caída más grande en el estado de ánimo al final de dos semanas. El resentimiento y envidia que producen las publicaciones de nuestros amigos pueden dar como resultado una pérdida de autoestima y un empeoramiento de nuestro estado de ánimo. Además, cuando tu necesidad de revisar tus cuentas de redes sociales se vuelve cada vez más frecuente y empieza a interferir con tus actividades diarias, puede ser una señal de que estás cayendo en adicción.


Caso de uso: Twitter

Posted by federico Oct 30, 2013

Caso de uso: Twitter: The Second Coming of Java: A Relic Returns to Rule Web | Wired Enterprise |

2010. Su polularidad llegó a un punto en donde los servers de Twitter simplemente no podian con la demanda y se caían constantemente. A tal punto que se tuvo que "montar" un sitio alternativo para la visita a la companía del presidente ruso Medvedev para evitar que todo se colgara mientras el mandatario enviaba su primer tweet. En aquel momento, la tecnología de Twitter estaba enteramente basada en el stack armado con Ruby On Rails. Trás el episodio con el presidente ruso se decide una reestructuración masiva de todo el sistema.

2013. En agosto de este año, Twitter ya mudado enteramente a Java, y con una media de 5700 tweets por segundo, alcanza un pico de mas de 143.000 tweets por segundo durante la televisación de la película Castle In the Sky.



A menudo, somos muchas personas las que utilizamos Google Talk como aplicación de mensajería instantánea para comunicarnos con nuestros contactos de GMail. Pero esta pequeña aplicación puede ser también una poderosa herramienta para obtener información breve y de manera instantánea. Gracias a un bot llamadoGurú, es posible realizar consultas sencillas como búsquedas a través de palabras clave, solicitar la información meteorológica, traducir una palabra, consultar una definición, conocer el último resultado deportivo de tu equipo o realizar una conversión de moneda.

El mecanismo es muy sencillo. Simplemente preguntas a Gurú e inmediatamente recibes la respuesta en el propio Google Talk. Para activar esta funcionalidad y sacarle el máximo partido, tan sólo tienes que invitar a tus contactos de chat y utilizar los siguientes operadores precedidos de tu petición.

  • Web: Muestra resultados de la búsqueda de Google según las palabras clave que introduzcas a continuación. Por ejemplo, si preguntas a guru ‘web ayuntamiento valencia’ te responderá con la url de la página web del Ayuntamiento de Valencia y su descripción.
  • Score: Responde con el último resultado deportivo de tu equipo de fútbol y la información de su próximo partido. Este topic resulta poco funcional ya que no responde ante buena parte de los nombres de los equipos que hemos introducido.
  • Weather: Te permitirá conocer la información meteorológica de forma localizada. Intenta preguntando‘Weather San Cristóbal de La Laguna’ para el estado del tiempo de la ciudad en este momento y la previsión para los próximos días.
  • Currency: Este topic nos devuelve el valor del tipo de cambio actual de cualquier moneda con respecto al dólar. Por ejemplo, si escribimos ‘Currency EUR’
  • Define: Nos proporciona la definición de una palabra concreta extraída de Wikipedia. Sin embargo, sólo acepta términos en lengua inglesa.
  • Translate: Traduce cualquier palabra detectando el idioma de origen de forma automática, como por ejemplo realizando la petición ‘translate helado’
  • Help: Despliega la ayuda de guru, donde verás el resto de comandos o topics que podrás utilizar. Si quieres saber para qué sirve cada topic teclea ‘help’ y a continuación el tema que te interesa. Por ejemplo, si tecleas ‘help currency’ recibirás como respuesta sugerencias con los códigos de las divisas que puedes consultar.

Con este pequeño truco, Google Talk amplía su utilidad por encima de la mensajería instantánea al proporcionarlos una herramienta de acceso a la información que nos ahorrará mucho tiempo sobretodo si lo utilizamos desde un dispositivo móvil, ya que no necesitaremos abrir el navegador web o el traductor de Google para buscar una respuesta a una pregunta sencilla. Sin embargo el Gurú de Google Talk funciona perfectamente en inglés, y aunque todavía mantiene importantes limitaciones en otros idiomas como el castellano, si lo utilizamos en el momento adecuado puede sacarnos de un apuro en determinadas situaciones que requieren respuestas inmediatas.

de: Vanilla #Java: What skills should a Core Java Developer have?



I have been trying to put together a list of basic skills a Java developer should have to move on to being an advanced Core Java programmer.




  • can write code on paper which has a good chance of compiling.
  • can use a debugger to debug programs and profile an application.
  • are familiar all the primitives types and operators in Java.
  • understands the class loading process and how class loaders work
  • can use multiple threads both correctly and can prove this improve performance or behaviour. e.g. wait/notify/notifyAll, SwingUtils.invokeLater, the concurrency library
  • can use checked exceptions, generics and enums
  • can time a small benchmark and get reproducible results
  • can write a very simple client server TCP service
  • have an understanding of garbage collection, when is it triggered, what can you do to minimise it
  • understand when to use design patterns such as Singleton, Factory, Fly-weight, Builder, Object Pool, Iterator, Strategy, Visitor, Composite



  • read Java Concurrency in Practice (
  • write a simple client server TCP service such as chat
  • read up on Design Patterns and try to use them. so you can learn when they help and don't help

Les dejo un articulo muy interesante de Frederick P. Brooks. Para los que no lo conocen es un Ingeniero de Software, escritor del The Mythical Man-Month. Casi una biblia en el tema. De el sale la ley de Brooks que dice: "Agregar más personal a un proyecto retrasado lo retrasará aún más". Vale la pena leerlo.


No hay balas de plata: Lo esencial y lo accidental en la Ingeniería del Software

by Frederick P. Brooks, Jr.

De todos los monstruos que pueblan nuestras pesadillas, ninguno es tan terrorífico como el hombre lobo, porque pasa repentinamente de lo familiar al horror. Por eso, todos buscamos balas de plata que puedan acabar con ellos magicamente.

El familiar proyecto de software, al menos tal como lo ve un gestor no técnico, tiene algo de ese caracter: suele ser inocente y sencillo, pero es capaz de convertirse en un monstruo de plazos incumplidos, objetivos fallados y productos defectuosos. Por eso escuchamos lamentos clamando por una bala de plata -- algo que haga que los costes del software caigan tan rapidamente como lo han hecho los del hardware.


Pero no se ve en ningún lugar una bala de plata. No hay ningún desarrollo, ni en tecnología ni en técnicas de gestión, que por si sólo prometa ni siquiera una mejora en un orden de magnigud en productividad, en fiabilidad, en simplicidad. En este artículo, intentaré mostrar el porque, examinando la naturaleza del problema del software y las propiedades de las balas propuestas.


Pero ser excéptico no es lo mismo que ser pesimista. Aunque no se vea la luz al final del túnel -- y, de hecho, creo que es inconsistente con la naturaleza del software-- se están realizando muchas innovaciones. Un esfuerzo consistente y disciplinado para desarrollar, difundir y explotar estas innovaciones debería conducir a una mejora de un orden de magnitud. No hay un camino dorado, pero hay un camino.


El primer paso hacia la cura de las enfermedades fue reemplazar las teorías sobre demonios y las teorías sobre humores por la teoría de los germenes. Ese primer paso, el principio de la esperanza, destruyó toda las esperanzas de una solución mágica. Se le dijo a los trabajadores que el progreso se haría paso a paso, con gran esfuerzo, y que una vida saludable sería el pago por una disciplina de limpieza. Eso también es lo que ocurre con la ingeniería del software hoy.


¿Tiene que ser tan duro?--Dificultades esencialesNo sólo no hay balas de plata a la vista, sino que la misma naturaleza del software impide que las haya -- ningún invento de los que mejoraron la productividad, fiabilidad y simplicidad en el hardware, como la electrónica, los transistores y las altas escalas de integración (VLSI) harán lo mismo por el software. No podemos experar ver doblarse las prestaciones cada dos años.


Lo primero, debemos darnos cuenta de que la anomalía no es que el progreso del software sea tan lento,sino que la del hardware sen tan rápido. Ninguna otra tecnología desde que empezó la civilización ha visto una mejora en seis ordenes de magnitud en 30 años. En cualquier otra técnica debemos elegir mejorar o las prestaciones o reducir costes. Estas mejoras provienen de la transformación la fabricación de ordenadores de una industria de ensamblaje en una industria de procesos.


Segundo, para ver el ratio de progreso que podemos esperar en la tecnología del software, vamos a examinar las dificultades de esa tecnología. Emulando a Aristóteles, las dividiré en esenciales, dificultades inherentes a la naturaleza del software, y accidentales, aquellas dificultades que se encuentran hoy en día pero que no son inherentes al software.


La esencia de una entidad software es una construcción de conceptos entrelazados: conjuntos de datos, relaciones entre los datos, algoritmos y llamadas a funciones. Esta esencia nos indica que uno de estos conceptos abstractos construidos tiene muchas representaciones. Sin embargo es muy preciso y muy detallado.


Creo que la parte más dura de construir software es la especificación, diseño y prueba de este concepto construido, no el trabajo de representarlo y comprobar la fidelidad de la representación. Todavía tendremos errores de sintaxis, evidentemente; pero eso es trivial si lo comparamos con los errores conceptuales en la mayoría de los sistemas.


Si esto es cierto, hacer software siempre será algo duro. No hay ninguna bala de plata.


Vamos a considerar las propiedades inherentes a la esencia irreductible de los modernos sistemas de software: complejidad, conformidad, variabilidad e invisibilidad.


Complejidad. Las entidades de software son más complejas debido a su tamaña que, posiblemente, cualquier otra construcción humana porque no hay dos partes iguales (al menos por encima del nivel de instrucción). Si la hay, podemos convertir a las dos partes similares en una subrutina--abierta o cerrada. A este respecto, los sistemas de software difieren profundamente de los ordenadores, edificios o automóviles, donde abundan los elementos repetidos.


Los ordenadores digitales son en si mismos más complejos que la mayoría de las cosas que la gente hace: Tienen una enorme número de estados. Esto hace que su concepción, descripción, y pruebas sean muy duras. Los sistemas de software tienen ordenes de magnituda más estados que las que tienen los ordenadores


Además, un incremento en escala de una entidad software no consiste meramente en repetir algunos elemenso a mayor escala, sino que es necesario incrementer el número de elementos diferentes. En la mayoría de los casos, el número de interacciones entre los elementos cambia de una forma no lineal con el número de elementos y la complejidad se incrementa a un ritmo mucho más que lineal.


La complejidad del software es una propiedad esencial, no accidental. Además, una descripción de una entidad de software que elimine su complejidad a menudo elimina su esencia. Durante tres siglos, los matemáticos y los físicos han hecho grandes avances construyendo modelos simplificados de fenómenos complejos, derivando propiedades de los modelos, y verificando esas propiedades experimentalmente. Este paradigma funcionó porque las complejidades ignoradas en los modelos no eran las propiedades esenciales del fenómeno. Pero eso no funciona cuando las complejidades son la esencia.


Muchos de los problemas clásicos del desarrollo de software derivan de esta complejidad esencial y su incremento no lineal con el tamaño. De la complejidad procede la dificultad de comunicación entre los miembros del equipo, que conduce a productos defectuosos, sobrecostes y retrasos. De la complejidad procede la dificultad de enumerar, y aún más comprender, todos los posibles estados del programa, y de hay procede la falta de fiabilidad. De la complejidad de la función procede la dificultad de llamar a la función, lo que hace difícil de usar al programa. De la complejidad de la estructura procede la dificultad en extender el programa para realizar nuevas funciones sin crear efectos laterales. De la complejidad de la estructura proceden los estados no previstos que se convierten en agujeros en la seguridad.


De la complejidad no sólo se derivan problemas técnicos, sino también problemas de gestión. Hace difícil tener una visión de conjunto, impidiendo la integridad conceptual. Dificulta encontrar y controlar todos los cabos sueltos. Crea los enormes agobios en aprender y comprender que lleva al personal hacia el desastre.


Conformidad. La gente del Software no es la única que encara la complejidad. Los físicos tratan con objetos terriblemente complejos incluso a los niveles "fundamentales" de la física de partículas. Las labores del físico descansan, sin embargo, en un profunda fe de que hay principios unificadores que deben encontrarse, o en los quarks o en las teorías de campo unificado. Einstein argumentaba que debe haber explicaciones simplificadas de la naturaleza, porque Dios no es caprichoso ni arbitrario.


Nada de esa fe conforta al ingeniero de software. La mayoría de la complejida que el debe controlar es arbitraria, forzada sin ritmo ni razón por las muchas instituciones humanas y sistemas a los que debe ajustarse. Estos difieren de interfaz a interfez, y de un momento a otro, no por necesidad sino sólo poruqe fueron diseñados por gente distinta, en lugar de por Dios.


En la mayoría de los casos, el software debe ajustarse porque es lo más reciente que ha llegado a la escena. En otros casos, debe hacerlo porque parece lo más correcto. Pero en casi todos los casos, la mayoría de la complejidad viene del tener que ajustarse a otros interfaces; esta complejidad no puede simplificarse solamente con un rediseño del software.


Variabilidad. El software está constantemente sometido a presiones para cambiarlo. Por supuesto, esto también afecta a los edificio, coches u ordenadores. Pero las cosas manufacturadas no cambian casi nunca una vez fabricadas; son sobrepasadas por modelos posteriores, o cambios esenciales se incorporan en copias de número de serie superior del mismo diseño básico. Es raro que un automóvil deba ser revisado por un defecto de diseño; cambios en los ordenadores una vez que están funcionando, son algo más frecuentes. Pero son muchísimo menos frecuentes que cambios en el software ya en funcionamiento.


En parte, esto se debe a que el software de un sistema se adapta a su función, y la función es la parte que más siente la presión para cambiar. En parte es porque el softare puede cambiarse más facilemente -- es puro pensamiento, infinitamente maleable. Los edificios pueden cambiarse, pero los altos costos de hacerlo, comprendidos por todos, sirven para que la gente que desea los cambios se contenga.


Todo el software que triunfa cambia, debido a dos procesos. Primero, cuando un programa resulta útil, la gente intenta usarlos para nuevas aplicaciones en el límite o más allá del dominio original para el que se diseño. La presión para extender las funcionalidades proceden de usuarios a los que les encantan las funciones básicas e inventan nuevos usos para ellas.


Segundo, el software exitoso sobrevive más allá de la vida del hardware para el que fue diseñado. Si no son nuevos computadores, son nuevos discos, pantallas, impresoras...; y el software debe adaptarse para estas nuevas oportunidades.


En resumen, el software vive dentro de un entorno cultural de aplicaciones, usuarios, leyes y hardware. Todo este entorno cambia continuamente, y esos cambios inexorablemente fuerzan a que se produzcan cambios en el software.


Invisibilidad. El software es invisible e invisualizable. Las abstracciones geométricas son herramientas potentes. El plano de la planta de un edificio ayuda tanto al arquitecto como al cliente a evaluar espacios, flujos de tráfico, vistas. Las contradicciones y omisiones salen a la luz. Dibujos a escalas de partes mecánicas y modelos de palos de moléculas, aunque son abstracciones, sirven al mismo propósito. Una realidad geométrica es capturada dentro de una abstracción geométrica.


La realidad del software no es un algo espacial. Aquí, no hay representaciones geométricas como las que que tiene la tierra en forma de mapas, los chips de silicio en forma de diagramas o los computadores en esquemas de conexiones. En el momento que intentamos crear diagramas de las estructuras de software, descubrimos que no está constituido por uno, sino por varios gráficos en distintas direcciones, superpuestos unos sobre otros. Los diversos gráficos pueden representar el flujo de control, el flujo de datos, patrones de dependencia, secuencias temporales, relaciones entre los nombres. Estos gráficos no suelen ser planares y mucho menos jerárquicos. De hecho, una de establecer control conceptual sobre estas estrucutras es forzar que todo encaje sobre uno (o más de uno) gráficos jerárquicos. [1]


A pesar del progreso en limitar y simplicar las estructuras del software, es inherente a las mismas el ser invisualizables, y esto no permite a nuestras mentes usar algunas de las más potentes herramientas conceptuales. Esto no sólo dificulta que nuestras mentes piensen sobre el diseño, sino que también hace difícil que nuestras mentes se comunican sobre el diseño.


Los avances del pasado solucionaron dificultades accidentalesSi examinamos los tres pasos el desarrollo de la tecnología del software que han sido más fructiferos, descubriremos que cada uno atacó una dificultad de envergadura en el desarrollo del software, pero que estas dificultades eran accidentales, no esenciales. Podemos también descubrir los límites naturales a la extrapolación de cada uno de estos ataques.


Lenguajes de Alto Nivel. Posiblemente la mayor mejora en productividad, fiabilidad y simplicidad ha venido del uso de lenguajes de alto nivel para la programación. La mayoría de observadores dirán que proporciona un incremento en un factor cinco de la productividad, y ganancias sustanciales en fiabilidad, simplicidad y comprensibilidad.


¿ Que es lo que consigue un lenguaje de alto nivel ? Libera a un programa de mucha de su dificultad accidental. Un programa abstracto consiste de construcciones conceptuales: operaciones, tipos de datos, secuencias y comunicación. El programa para una máquina concreta está relacionado con bits, registros, condiciones, bifurcaciones, canales, discos y demás. Al extender los lenguajes de alto nivel sus construcciones a lo que uno busca en el programa abstracto y evitar los niveles inferiores, elimina un nivel entero de complejidad que no es inherente en absoluto al programa.


Lo máximo que un lenguaje de alto nivel puede hacer es abarcar todas las construcciones que el programador imagina en el programa abstracto. Para asegurarnos de eso, el nivel de nuestro pensamiento sobre estructuras de datos, tipos de datos y operaciones sigue subiendo, pero a un ratio cada vez menor. Y el desarrollo de los lenguajes se aproxima cada vez más a la sofisticación de los usuarios.


Pero, finalmente, se llega al punto que el desarrollo del lenguaje de alto nivel crea una herramienta nueva que incrementa en vez de reducir el trabajo intelectual del usuario, el cual raramente usa esa esotérica construcción.


Tiempo compartido. El Tiempo Compartido consiguió una gran mejora en la productividad de los programadores y en la calidad de su producto, aunque no tan grande como los lenguajes de alto nivel.


El tiempo compartido ataca una dificultad bastante diferente. Permite la inmediatez, y esto nos permite tener una visión de conjunto de la complejidad. El lento desarrolo del trabajo por lotes implicaba que uno se olvidaba de los detalles que tenía en mente en el momento que se dejaba de programa y se preparaba para compilar y ejecutar. El efecto más serio era el dejar de tener en mente todo lo que está ocurriendo en un sistema complejo.


Esos retrasos, igual que las complejidades del lenguajes máquina, es algo más accidental que esencial en el proceso del software. Los límites de la potencial contribución del tiempo compartido se derivan directamente. El efecto principal es acortar el tiempo de respuesta. Conforme este tiempo de respuesta se aproxima a cero, llega un monento que supera el umbral de percepción humana, que es de unos 100 milisegundos. Más allá de ese límite, no habrá benecios.


Entornos de desarrollo unificados. Unix e Interlisp, los primeros entornos de programación integrados que se difundieron, parecieron mejorar la productividad por factores propios a ellos. ¿ Porqué ?


Atacaban a las dificultades accidentales que se producen al usar programas individuales de forma conjunta, proporcionando librarías integradas, formatos de fichero unificados, y colas y filtros. Como resultado, estructuras conceptuales que en principio consistían en llamarse, alimentarse y utilizarse entre si podía de hecho ser implementadas facilmente en la práctica.


Este avance estimuló el desarrollo de 'bancos de herramientas', puesto que cada nueva herramienta podía aplicarse a cualquiera de los programas que utilizaban los formatos estandar.


Debido a estos éxitos, los entornos son el objetivo de mucha de la investigación de hoy en día en la ingeniería del software. Echaremos un vistazo a sus promesas y limitaciones en la siguiente sección.


Esperanzas de descubrir la plata Ahora vamos a considerar los desarrollos técnicos que han ido presentandose como potenciales balas de plata. ¿Que tipo de problema encaran? ¿Los esenciales o los accidentales? ¿Ofrecen avances revolucionarios o sólo mejoras incrementales?


Ada y otros avances en lenguajes de alto nivel. Uno de los desarrollos recientes que más nos han vendido es Ada, un lenguaje de alto nivel de proposito general de los años 80. Ada no sólo refleja mejoras evolucionarias en conceptos del lenguaje, sino que abarca características para animar a utilizar diseño moderno y modularidad. Quizás la filosofía de Ada sea un avance mayor que el lenguaje, a causa de su enfasis en modularidad, tipos de datos abstractos o estructura jerárquica. Ada es excesivamente prolijo, un resultado natural de su proceso de desarrollo, donde los requisitos fueron más importantes que el diseño. Esto no es algo fatal, ya que subconjuntos de su vocabulario pueden solventar el problema de aprenderlo, y avances en el hardware los MIPS baratos necesarios para pagar los costes de compilar. Los avances en estructura de los sistemas de software son, de hecho, una excelente forma de gastar los MIPS que nuestro dinero compra. Los sistemas operativos, a los que se denostaba en los años 60 por su consumo de memoria y ciclos de CPU, han demostrado ser una forma excelente para utilizar los MIPS y memoria baratos que han surgido del desarrollo del hardware.


Sin embargo, Ada no ha demostrado ser la bala de plata que acabe con el monstruo de la productividad del software. Es, después de todo, tan sólo otro lenguaje de alto nivel, y el mayor beneficio de estos lenguajes vino de la primera vez que se adoptaron: la transición de las complejidades accidentales de la máquina en las instrucción más abstractas de las soluciones paso-a-paso. Uno vez eliminados estos accidentes, los que quedan son más pequeños, y el premio por eliminarlos seguramente es menor.


Predigo que en una decada, cuando la efectividad de Ada sea valorada, se verá que ha conseguido algo de mejora, pero no a causa de alguna particularidad del lenguaje, ni siguiera a causa de todas ellas combinadas. Ni será el nuevo entorno de Ada la causa de las mejoras. La mayor contribución de Ada será la transición de los programadores que lo usen, aunque sea ocasionalmente, a las modernas técnicas de diseño de software.


Programación orientada a objeto. Muchos estudiantes del estado del arte tienen más esperanzas en la programación orientada a objetos que en cualquier otra técnica en desarrollo. [2] Yo entre ellos.. Mark Sherman de Dartmouth nos dice en CSnet News que debemos ser cuidadosos distinguiendo dos ideas separadas que aparecen bajo el mismo nombre: tipos de datos abstractos y tipos jerárquicos. El concepto del tipo de datos abstracto es que el tipo del objeto debería ser definido por un nombre, un conjunto de valores  y un conjunto de operaciones propios más que por su estructura almacenada, la cual debería ocultarse. Ejemplos son los paquetes Ada (con tipos privados) y los módulos de Modula.


Los tipos jerárquicos, como las clases de Simula-67, nos permiten definir interfaces generales que pueden ser refinadas posteriormente suministrando tipos subordinados. Los dos conceptos son ortogonales: podemos tener jerarquía sin ocultación u ocultación sin jerarquía. Ambos conceptos representan avances reales en el arte de construir software.


Cada uno elimina otra dificultad accidental del proceso, permitiendo al diseñador expresar la esencia del diseño sin tener que escribir grandes conjuntos de material sintáctico que no añade información sobre el contenido. Para ambos tipos de abstracción, el resultado es eliminar un tipo de dificultad accidental de un mayor nivel y permitir un mayor nivel de expresión en el diseño.


Sin embargo, tales avances pueden hacer poco más que eliminar todas las dificultades accidentales de la expresión del diseño. La complejidad del diseño en si mismo es esencial, y tales ataques no hacen que cambie en eso. La programación orientada a objeto puede conseguir una ganancia de un orden de magnitud sólo si la innecesaria especificación de tipos de nuestro lenguaje consigue acabar con las nueve decimas partes del trabajo de diseño de un programa. Permitánme que lo dude.


Inteligencia Artificial.La mayoría de la gente espera que avances en inteligencia artificial nos proporcionen el avance revolucionario que nos dará ganancias de varios ordenes de magnitud en la productividad del software y su calidad. [3] Yo no. Para ver porqué, debemos aclarar lo que entendemos por "inteligencia artificial."


D.L. Parnas ha aclarado el caos terminológico: [4]


Dos tipos bastante diferentes de AI son de uso común hoy en día. AI-1: el uso de ordenadores para solucionar problemas que previamente sólo podían solventarse utilizando inteligencia humana. AI-2: El uso de un conjunto específico de técnicas de programación conocidas como heurísticas o programación basada en reglas. En esta aproximación, se estudia a expertos humanos para determinar que heurísticas o reglas utilizan para solucionar problemas... El programa se diseña para solucionar un problema de la misma forma que los humanos parecen hacerlo.


La primera definición tiene un significado que va cambiando... Algo puede encajar con la definición de AI-1 hoy, pero una vez que sabemos como trabaja el programa y comprendemos el problema, no lo veremos como AI nunca más... Desafortunadamente no puedo identificar un único cuerpo de tecnología en este campo... La mayoría del trabajo es específico a un problema, y se requiere algo de abstracción o creatividad para ver la forma de transferirlo.


Coincido completamente con esta crítica. Las técnicas usadas para reconocimiento de voz parecen tener poco que ver con las usadas para reconocimiento de imágenes, y ambas son muy diferentes de las usadas en los sistemas expertos. Se me hace difícil ver como el reconocimiendo de imágenes, por ejemplo, producirá una diferencia apreciable en la práctica de la programación. Lo mismo ocurre con el reconocimiento del habla. Lo difícl al escribir software es decidir lo que uno quiere decir, no decirlo. Ninguna facilidad en la expresión puede dar más que ganancias marginales.


A la tecnología de sistemas expertos, AI-2, le reservo una sección entera.


Sistemas expertos. El cmapo más avanzado dentro de la inteligencia artificial, y el usado en mayor grado, es la tecnología para construir sistemas expertos. Muchos científicos del software están trabajando intensamente para aplicar esta tecnología en el ámbido del desarrollo de software. [3, 5] ¿ De que va todo esto, y cuales son las espectativas ?


Un sistema experto es un programa que contiene un motor de inferencias generalista y una base de reglas, que coge datos de entrada y suposiciones, explorar las inferencias derivadas de la base de reglas, consigue conclusiones y consejos, y ofrece explicar sus resultados mostrando su razonamiento al usuarios. Los motores de inferencia normalmente tratan con datos y reglas probabilísticos o de tipo fuzzy (lógica difusa), además de usar lógica puramente determinista.


Estos sistemas ofrecen ventajas claras sobre algoritmos programados diseñados para conseguir las mismas soluciones para los mismos problemas:


  • La tecnología de motor de inferencia se desarrolla de forma independiente de la aplicación y, a continuación, se aplica para muchos usos. Se puede justificar un mayor esfuerzo en los motores de inferencia. De hecho, esa tecnología es muy avanzada.
  • Las partes cambiables de las peculiriades de una aplicación en particular se codifican dentro de la base de reglas, de una forma uniforme, y se suministran herramientas para desarrollar, cambiar, probar y documentar la base de reglas. Esto regulariza gran parte de la complejidad de la aplicación.


La potencia de estos sistemas no proviene de maravillos mecanismos de inferencia sino más bien de sobre-prolijas bases de conocimiento que reflejan el mundo real de forma muy precisa Creo que el avance más importante ofrecido por la tecnología es la separación de la complejidad de la aplicación de la la complejidad del programa. 


Cómo puede aplicarse esta tecnología al trabajo de la ingeniería del software? De muchas formas: Esos sistemas pueden sugegir las reglas para la interfaz, aconsejar sobre estrategias de test, recodar las frecuencias de tipos de bugs, y mostrar claves para la optimización.


Piense en un asesor sobre pruebas. En su forma más rudimentaria, el sistema experto de diagnóstico es poco más que el checklist de un polito, tan sólo un listado enumerado de sugerencias como causas posibles de dificultad. Conforme la estructura del sistema sea más y más captada por la base de reglas, y conforme la base reglas tenga una vista más sofisticada de los sintomas de problemas que se informen, el asesor sobre tests será más detallado sobre las hipótesis que genera y los tests que recomienda. Tal sistema experto se separa radicalmente de un sistema convencional en tanto en cuanto que su base de reglas puede ser modularizada de forma jerárquica en la misma forma que el software correspondiente, por que si el software se cambia modularmente, las reglas de diagnóstico pueden asimismo modificarse modularmente.


El trabajo requerido para general las reglas de diagnóstico es un trabajo que debería de ser hecho de todas formas generando el conjunto de casos de prueba para los módulos y para el sistema. Si se hace de una forma generalista, tanto con una estructura uniforme para las reglas como un buen motor de inferencia, puede reducir realmente el trabajo total de generar los casos de test y ayudar también en el mantenimiento durante el ciclo de vida del producto y las pruebas para las modificaciones. De la misma forma, podemos defender otros asesores, posiblemente muchos y simples, para otras partes de las tareas de la producción de software.


Hay muchas dificultades en el camino de comprender la utilidad de los asesores basados en sistemas expertos en el desarrollo de programas. Una parte crucial de nuestro escenario imaginario es el desarrollo de formas sencillas de pasar desde la especificación de la estructura del programa a generación de reglas de diagnóstico de forma automática o semiautomática. Incluso más difícil e importante es la tarea doble de la adquisición de conocimientos: encontrar expertos auto-analíticos que articulen el porqué hacen las cosas que hacen y desarrollar técnicas eficientes para estraer lo que ellos saben y destilarlo dentro de bases de reglas. El prerrequisito esencial para construir un sistema experto es tener un experto.


La contribución más poderosa de los sistemas expertos posiblemente será poner al servicio del programado inexperto la experiencia y visión acumulada por los mejores programadores. Esto no es precisamene poco. El salto entre la práctica del mejor ingeniero de software y la del ingeniero medio es enorme, quizás la mayor que se encuentre entre las distintas ingenierías existentes. Una herramienta que disemine buenas prácticas sería importante.


Programación "Automática". Durante casi 40 años, la gente ha estado anticipando y escribiendo sobre "programación automática", o la generación de un programa para resolver un problema a partir de las especificaciones del problema. Hay quien escribe hoy como si esperaran que esta técnica proporcionara el siguiente salto. [5]


Parnas [4] implica que el término se usa por su glamour, no por la semántica de su palabra, aseverando,



Resumiendo, la programación automática siempre ha sido un eufemismo para la programación en un lenguaje de alto nivel que estaba disponible en ese momento para el programador.


Esencialmente argumenta que en la mayoría de los casos las especificaciones que deben tenerse no son las del problema sino las del método para su solución.


Hay excepciones. La técnica de construir generadores es muy potente, y se usar rutinariamente en programas para ordenar. Algunos sistemas para integrar ecuaciones diferenciales también han permitido la especificicación directa del problema, y los sistemas han ajustado los parámetros, elegido los metodos de solución entre los de una librería y generado los programas.


Estas aplicaciones tienen propiedades muy favorables:

  • Los problemas son claramente caracterizados por (relativamente) muy pocos parámetros.
  • Hay muchos métodos conocidos de solución que proporcionan una librería de alternativas.
  • Un análisis extensivo ha conducido a reglas explicitas para seleccionar técnicas de solución, a partir de parámetros dados por el problema.


Resulta difícil ver la forma en que estas técnicas se generalizan al mundo enormemente más amplio del software ordinario, donde los casos donde esas bonitas propiedades aparecen son la excepción. Incluso más difícil es imaginar como este avance en la generalización pudiera producirse. 


Programación gráfica. Uno de los temas favóritos en ls disertaciones para PhD es la programación gráfica o visual -- la aplicación de los gráficos de ordenador al diseño de software. [6, 7] A veces la promesa hecha por esa aproximación se defiende como análoga al diseño de los chips VLSI, en los cuales los gráficos por ordenador juegan un rol muy fructífero. A veces los teóricos, justifican la aproximación considerando los flujogramas como el medio ideal para el diseño de programas y proporcionando poderosos mediso para construirlos.


Nada convicente, y mucho menos excitante, ha surgido de esos esfuerzos. Estoy convencido de nunca lo hará.


En primer lugar, como he defendido antes [8], el flujograma es una pobre abstracción de la estructura del software. De hecho, es mejor verlo como el intento de Burks, von Neumann, y Goldstine de proporcionar un lenguaje de control de alto nivel que necesitaban desesperadamente para su propuesta de ordenador. En la forma lastimosa, multipágina, de caja de conexiones en la que ha terminado elaborada el flujograma hoy en día, ha demostrado ser inútil como una herramienta de deseño:  los programadores dibujan los flujogramas después, no antes de haber escrito los programas que describen.


Segundo, las pantallas de hoy son demasiado pequeñas, en pixeles, para mostrar tanto el conjunto como la resolucion de cualquier diagrama de software seriamente detallado. La conocida "metáfora de escritorio" de las estaciones de trabajo actuales es, de hecho, una metáfora de "sillón de avión". Cualquiera que haya habierto un maletín lleno de papeles mientras estaba sentado entre dos pasájeros reconocerá las diferencias: uno puede sólo ver unas pocas cosas a la vez. El escritorio real proporciona tanto acceso a un montón de páginas como una visión de conjunto. Más aún, cuando la creatividad sube al límite, más de un programador o escritor abandona el escritoio por el mucho más espacioso suelo. La tecnología de hardware tendrá que avanzar bastante más antes de que la amplitud de nuestros monitores sea suficiente para la tarea de diseñar software.


Aún más fundamental, como defendí antes, es que el software sea muy difícil de visualizar. Si uno hace diagrama de flujo de control, el anidado de los ámbitos de las variables, las referencias cruzadas entre las variables, el flujo de datos, estructuras jerárquicas de datos o cualquier otra cosa, uno percibe sólo una dimensión del elefante de estructuras intricadamente interconectas que es el software. Si se superponen todos los diagramas generados por las muchas vistas relevantes, resulta difícl extraer cualquier visión de conjunto. La analogía VLSI es fundamentalmente erronea: un diseño de un chip es una descripción bi-dimensional cuya geometría refleja su construcción en tres dimensiones. Un software no.


Verificación del programa. Gran parte del esfuerzo de la programación consiste en el testeo y la corrección de errores. ¿ Es quizás donde pudieramos esperar una bala de plata, eliminando los errores del software en la fase de diseño del sistema? ¿ Puede mejorar tanto la productividad como la fiabilidad radicalmente la estrategia enormemente diferente de probar la correción de los diseños antes del inmenso esfuerzo realizado en implementarlo y comprobarlo ?


No creo que podamos encontrar la magia de la productividad aquí. La verificación de programas es un concepto muy potente y será muy importante en cosas tales como kernels de sistemas operativos seguros. La tecnología no promete, sin embargo, ahorrar en trabajo. Las verificaciones cuestan tanto trabajo que sólo unos pocos programas son verificados.


La verificación del programa no implica programas a prueba de errores. No hay magia aquí. Las pruebas matemáticas pueden estar llenas de fallos. Aunque la verificación podría reducir la carga en el testeo del programa, no puede eliminarla.


Más en serio, incluso la verificación de programa perfecta sólo podría establecer que un programa cumple con sus especificaciones. La tarea más dura en el software es conseguir unas especificaciones completas y consistentes, y la parte más esencial de construir un programa es, de hecho, la depuración de las especificaciones.


Entornos y herramientas. Que ganancia podemos esperar de las mejoras e investigaciones en los entornos de programación? Una reacción instintiva es que los problemas con mayor retribución (sistemas de ficheros jerárquicos, formatos de ficheros uniformes para hacer posibles interfaces de programa uniformes y herramientas generalizadas) fueron atacados hace ya mucho, y han sido resueltos. Los editores y entornos de desarrollo inteligentes específicos a un lenguaje no se usan todavía ampliamente en la práctica, pero la mayoría de ellos prometen libarnos de los errores sintácticos y los errores semánticos simples.


Quizás la mayor ganancia que deba conseguirse por los entornos de programación es el uso de sistemas de base de datos integrados para realizar el seguimiento de la miriada de detalles que deben ser seguidos de forma precisa por el programador individual y mantenidas uniformemente por el grupo de colaboradores en un único sistema.

Seguramente este trabajo se realice y arrojará alguna fruta de productividad y fiabilidad, peró será marginal.


Estaciones de trabajo. Que ganancia puede esperar el arte del software del incremento rápido y seguro de la potencia y memoria de las estaciones de trabajo individuales? Bien, cuantos MIPS puede uno usar fructiferamente? La composición y edición de programas y documentos es soportada totamente por las máquinas de hoy en día. La compilación significa un retraso, pero un factor de 10 en la velocidad de la máquina podría llevar el tiempo necesario para la velocidad de pensamiento de la actividad diaria del programador. De hecho, eso parece que ocurra hoy en día.


Seguro que unas estaciones de trabajo más potentes serán bienvenidas. Pero no podemos esperar mágicos avances gracias a ellas.


Ataques prometedores sobre la EsenciaIncluso aunque ninguna avance tecnológico prometa dar el tipo de resultado mágico al que estamos acostumbrados en el hardware, actualmente hay abundancia de buenos trabajos, y la promesa de avances firmes, aunque no espectaculares.


Todos los ataques tecnológicos a los accidentes en el proceso del software están limitados fundamentalmente por la ecuación de la productividad:


Si, como creo, los componentes conceptuales de la tarea están ocupando ahora la mayoría del tiempo, entonces ninguna actividad sobre las partes necesarias del trabajo que consistan simplemente en la expresión de los conceptos dará grandes ganancias de productividad.


Deberíamos centrarnos en aquellos ataques sobre la esencia del problema del software, la formulación de estructuras conceptuales complejas. Afortunadamente, algunos de estos ataques son prometedores.


Comprar vs construir. La solución más radical para construir software es no hacerlo.


Cada día esto es más fácil, ya que más y más vendedores ofrecen más y mejor software de una asombrosa variedad de aplicaciones. Mientras los ingenieros de software hemos trabajo en la metodología de producirlo, la revolución del PC ha creado no uno, sino muchos mercados masivos para el software. Cada revista mensual, ordenada por tipo de máquina, anuncia y revisa docenas de productos a precios por debajo de los cientos de Euros. Las fuentes más especializadas ofrecen productos muy potentes para los mercados de las estaciones de trabajo y el mercado Unix. Incluso herramientas de software y entornos pueden comprarse sin problemas. Yo mismo he propuesto un mercado para módulos individuales [9]


Cualquiera de estos productos es más barato de comprar que de hacer. Incluso a un costo de 100.000 Euros, un software comprado cuesta lo mismo que un año de programador. Y la entrega es inmediata! Bueno, inmediata siempre que el producto exista, productos que harán feliz a un usuario. Más aún, tales productos tienden a estar mucho mejor documentados y mejor mantenidos que el producto propio.


El desarrollo del mercado de masas es, creo, el mayor avance en la ingeniería del software. El coste del software ha sido siempre el de desarrollo, no el de copia. Al compartir el coste simplemente entre unos pocos usuarios reduce radicalmente el coste por usuario. Otra forma de verlo es que el uso de n copias de un software multiplica de forma efectiva la productividad de sus desarrolladores por n. Eso implica una mejora de la productividad enorme.


El factor clave, por supuesto, es la aplicabilidad. Puedo usar un paquete ya hecho para implementar mi tarea? Aquí ha ocurrido algo sorprendente. Durante los años 50 y 60, estudio tras estudio mostraban que los usuarios no utilizarían paquetes genaralistas para gestión de nominas, control de inventarios, contabilidad y cosas así. Los requisitos eran demasiado especializados, las variaciones de un caso a otro excesivas. Durante los años 80, nos encontramos que la gente demandaba estos productos y se difundían de forma masiva. ¿ Que es lo que cambio ?


Ciertamente, no los paquetes. Podían ser más generalistas y algo más ajustables que antes, pero no mucho. Ni las aplicaciones. En todo caso, las necesidades de los negocios y ciencias de hoy son mayores y más complicadas que las de hace 20 años.


El gran cambio ha venido del ratio de costo hardware/software. En 1960, el comprador de una máquina de dos millones de dolares sentía que el podía afrontar otros 250.000 más por un programa de nóminas a la medida, uno que encajara más facilmente y sin problemas en el entorno hostil de la sala de ordenadores. Hoy, el comprador de una máquina para la oficina de 50.000 dolares no concibe afrontar un programa de nominas a la medida, por lo que se adapta su gestión de nóminas a los paquetes disponibles. Los ordenadores son algo tan ubicuo, aunque no tan amado, que las adaptaciones son aceptadas como algo inevitable.


Hay excepciones dramáticas a mi argumento de que los paquetes de software no han cambiado mucho en estos años: las hojas de cálculo y los sistemas simples de base de datos. Estas poderosas herramientas, tan obvias retrospectivamente y tan tardías en aparecer, conducen ellas mismas a miles de usos, algunos bastante poco ortodoxos. Artículos e incluso libros abundan ahora mismo sobre como realizar tareas insospechadas con la hoja de cálculo. Un gran número de aplicaciones que podrían haberse escrito como programas a la medida en Cobol o RPG son ahora realizadas rutinariamente con estas herramientas.


Muchos usuarios operan ahora sus propios ordenadores con diversas aplicaciones sin haber escrito nunca un programa. De hecho, muchos de estos usuarios no pueden escribir nuevos programas para sus máquinas, pero son sin embargo adeptos a solucionar nuevos problemas con ellos.


Creo que la más potente estrategia de productividad del software para muchas organizaciones de hoy es equipar a los trabajadores intelectuales que están en primera linea con PCs y programas generalistas de hoja de cálculo, ficheros, dibujo y proceso de textos y dejar que se las apañen. La misma estrategia, con paquetes de estadística y matemáticas y algunas capacidades simples de programación, funcionarían con centenares de científicos de laboratorio.


Refinamiento de requisitos y prototipado rápido. La parte más dura de hacer software es, precisamente, decidir lo que hacer. Ninguna otra de las partes en que se divide este trabajo es tan difícil como establecer los requisitos técnicos detallados, incluyendo todas las interfaces con la personas, las máquinas y los otros sistemas de software. Ninguna otra parte del trabajo destroza tanto el resultado final si se hace mal. Ninguna otra parte resulta tan díficil de rectificar a posteriori.


Por tanto, la función más importante que realiza el diseñador de software para el cliente es la extracción iterativa y el refinamiento de los requisitos del producto. La verdas es que el cliente no sabe lo que quiere. El cliente normalmente no sabe que preguntas deben ser respondidas, y casi nunca ha pensado en los detalles del problema necesarios para la especificación. Incluso la simple respuesta ("Haz que el nuevo software trabaje como nuestro viejo sistema de procesado manual de la información") es de hecho demasiado simple. Uno nunca quiere exactamente eso. Es más, los sistemas de software complejos son cosas que actúan, se mueven, que trabajan. La dinámica de esa acción son difíciles de imaginar. Por tanto, al planificar cualquier actividad de diseño de software, es necesario permitir un trabajo iterativo extensivo entre el cliente y el diseñador como parte de la definición del sistema.


Quisiera ir un paso más allá y asegurar que es realmente imposible para un cliente, trabajando con un ingeniero de software, especificar completa, precisa y correctamente los requisitos exactos de un sistema de software moderno sin probar algunas versiones de prueba del sistema.


Por tanto, una de las mayores promesas de los esfuerzos tecnológicos actuales, y una que ataca a la esencia, no los accidentes, del problema del software, es el desarrollo de aproximación y herramientas para el prototipado rápido de sistemas ya que el prototipado es parte de la especificación iterativa de requisitos.


Un prototipo de software es uno que simula las interfaces más importantes e implementa las funciones principales del sistema deseado, aunque no se ajuste a las limitaciones de velocidad del hardware, tamaño o coste. Los prototipos normalemente implementan las tareas principales de la aplicación, pero no intentan manipular las tareas excepcionales, responder correctamente a entradas erroneas, o abortar de forma limpia. El proposito del prototipo es hacer real la estructura del concepto del software especificado, para que el cliente pueda comprobar su consistencia y su usabilidad.


Gran parte del procedimiento de adquisición de software de hoy en día descansa en asumir que uno puede especificar de forma satisfactoria un sistema por anticipado, pagar lo necesario para que se construya, tenerlo construido e instalarlo. Creo que asumir esto es algo fundamentalmente erroneo, y que muchos problemas relativos a la adquisición de software se deben a esa falacia. A partir de ese momento, no podrán ser solucionados sin revisiones de sus fundamentos, revisiones que implican desarrollo iterativo y especificación de prototipos y productos.


Desarrollo incremental: hacer crecer en vez de construir software. Todavía recuerdo la sacudida que sentí en 1958 cuando escuche por primera vez a un amigo hablando de construir un programa, como algo opuesto a escribirlo. Como en un fogonazo, el cambió mi forma de ver el proceso del software. La metáfora era potente y precisa. Hoy comprendemos mejor como se asemeja la construcción del software a otros procesos de contrucción y usamos libremente otros elementos de la metáfora, tales como especificaciones, ensamblaje de componentes, y andamiaje (scaffolding).


La metáfora de la construcción ha sobrevivido a su utilidad. Es el momento de cambiar una vez más. Si, como yo creo, las escructuras conceptuales que construimos hoy son demasiado complicadas para ser especificadas de forma precisa de forma temprana, y demasiado complejas para ser construidas sin fallos, debemos tomar una aproximación radicalmente diferente


Deberíamos mirar a la naturaleza y estudiar la complejidad de las cosas vivas, en vez de las cosas muertas que hace el hombre. Aquí encontramos construcciones cuya complejidad nos estremece. El mismo cerebro es tan intrincado que no se le puede sacar un mapa, poderoso más allá de la imitación, rico en diversidad, auto-protegido y autoregenativo. El secreto es que creció, no se construyó.


Lo mismo debería ocurrir con nuestro software. Hace algunos años Harlan Mills propuso que cualquier software debería crecer mediante desarrollo incremental. [10] Esto significa que el sistema debería primero conseguir que se ejecutara, incluso sin hacer nada útil expcepto llamar al conjunto apropiado de subprogramas que no hacen nada. Entonces, paso a paso, debería ser rellenado, desarrollando los subprogramas, como acciones o llamadas a subrutinas vacías en el nivel inferior.


He visto resultados impresionantes desde que empecé a instigar a usar esta técnica a los constructores de software en mi clase (Software Engineering Laboratory). Nada en la década anterior ha cambiado tanto mi propia práctica, o su efectividad. La aproximación necesita el diseño de arriba hacia abajo (top-down), lo que representa un crecimiento desde arriba hacia abajo del software. Permite un fácil rastreo (backtracking). Permite prototipos tempranos. Cada función añadidad y cada nueva provisión para datos o circunstancias más complejos crece organicamente a partir de lo ya existente.


Los efectos en la moral son asombrosos. El entusiasmo salta cuando hay un sitema en marcha, aunque sea uno simpel. Los esfuerzos se redoblan cuando el primer dibujo de un software de gráficos aparece en la pantalla, aunque sea sólo un rectángulo. Uno siempre tiene, en cada paso del proceso, un sistema en marcha. Descubro que los equipos de desarrollo pueden hacer crecer entidades mucho más complejas en cuatro meses de lo que podían construir.


Los mismos beneficios se obsevan tanto en proyectos enormes como en los más pequeños. [11]


Grandes diseñadores. La cuestión central sobre como mejorar el arte del software se centra, como siempre, en la gente.


Podemos conseguir buenos diseños siguiendo prácticas buenas en lugar de pobres. Las buenas prácticas de diseño pueden enseñarse. Los programadores están entre los más inteligentes entre la población, por lo que pueden aprender buenas prácticas. A partir de ahora, uno de los mayores obligación en USA debería ser promulgar prácticas buenas y modernas. Nuevos curriculums, nueva literatura, nuevas organizaciones tales com el Software Engineering Institute, todas deberían enfocarse en subir el nivel de nuestras prácticas de uno pobre a otro bueno. Esto es completamente apropiado.


No obstante, no creo que podamos dar el siguiente paso adelante en la misma forma. Mientras que la diferencia entre diseños conceptuales pobres y buenos debe descansar en lo saludable del método de diseño, la diferencia entre diseños buenos y excelentes seguramente no. Los diseños excelentes proceden de diseñadores excelentes. La construcción de software es un proceso creativo. Una metodología sana puede potenciar y liberar la mente creativa; pero no puede inflamar o inspirar al esclavo.


Las diferencias no son menores: son similares a las diferencias entre Salieri y Mozart. Estudio tras estudio muestran que los diseñadores excelentes producen estructuras que son más rápidas, pequeñas, simples, claras y producen más con menos esfuerzo. [12] Las diferencias entre los excelentes y la media se aproxima a un orden de magnitud.


Una pequeña mirada retrospectiva muestra que aunque mucho software bueno y útil ha sido diseñado por comités y fabricado como parte de proyectos con varios apartados, aquellos sistemas de software que tienen fans excitados y apasionados son aquellos que son el producto de uno o sólo unos pocos diseñadores excelentes. Pensemos en Unix, APL, Pascal, Modula, Smalltalk, incluso Fortran; y comparámoslos con Cobol, PL/I, Algol, MVS/370, y MS-DOS. (Vea la Tabla 1.)


Por tanto, aunque apoyo fuertemente los esfuerzos actuales para la transferencia de tecnología y la formación, creo que el esfuerzo individual más importante que podemos hacer es desarrollar las formas de que surgan grandes diseñadores.


Ninguna organización dedicada al software puede ignorar este desafío. Los buenos gestores, aunque escasos, no lo son tanto como los buenos diseñadores. Los diseñadores y gestores excelentes son incluso más raros. La mayoría de las organizaciones realizan esfuerzos considerables buscando y cultivando a sus gestores; no conozco a ninguna que realice esfuerzos equivalentes para encontrar y desarrollar a los diseñadores excelentes de los que depende en última instancia la excelencia técnica de los productos.


   Tabla 1. Software Excitante Vs. Util pero No excitante.  Excitante No Excitante  Unix Cobol  APL PL/I  Pascal Algol  Modula MVS/370   Smalltalk MS-DOS  Fortran - 


Mi primera propuesta es que las organizaciones de software debe determinar y proclamar que los diseñadores excelentes son tan importantes para su éxito como los gestores excelentes, y que deben esperar ser recompensados y arropados de la misma forma. No sólo en el salario, sino el resto de los requisitos -- tamaño de la oficina, mobiliario, equipamiento, gastos para viajes, personal de apoyo -- deben ser equivalentes.

Como desarrollar a los diseñadores excelentes? El espacio no me permite una discusión detallada, pero algunos pasos son obvios:


  • Identificar sistemáticamente a los mejores diseñadores tan pronto como sea posible. Los mejores a menudo no son los que tienen más experiencia. 
  • Asignar un mentor de carrera responsable del desarrollo de su futuro, y realizar un seguimiento cuidadoso de su carrera. 
  • Idear y mantener un plan de desarrollo de carrera para cada una de las jovenes promesas, incluyendo aprendizaje junto a diseñadores excelentes cuidadosamente seleccionados, episodios de educación formal avanzada y cursillos, todo entrelazado con asignación de diseños solitarios y liderazgo técnico. 
  • Dar oportunidades para que los diseñadores en desarrollo interactúen y se estimulen con otros.

AcknowledgmentsI thank Gordon Bell, Bruce Buchanan, Rick Hayes-Roth, Robert Patrick, and, most especially, David Parnas for their insights and stimulating ideas, and Rebekah Bierly for the technical production of this article




¿Estás buscando trabajo y crees que tienes lo que hay que tener para poder trabajar en uno de los grandes? ¿trabajas en una empresa mugrienta y quieres regodearte en la autocompasión? Si perteneces a cualquiera de estos dos grupos, o simplemente tienes curiosidad, puedes echar un vistazo a esta infografía que resume algunos de los beneficios y extras que reciben los trabajadores de Google, Facebook, Twitter o LinkedIn.



La UBA está organizando un torneo Iteruniversitario de programación. Acá les dejo el link con la info completa:



El torneo es una competencia de programación por equipos. Cada equipo debe ser conformado por 3 alumnos de la misma universidad y se desarrollará de forma presencial el 24 de septiembre de 2011 en las sedes mecionadas más arriba. El torneo consiste en resolver un conjunto de problemas algorítmicos en un plazo de 5 horas. La solución a cada problema es un programa que se envía mediante un sistema especial al jurado, que lo corrige en su momento mediante casos de prueba secretos (test de caja negra). El equipo se entera al instante si la solución enviada es correcta, y de no serlo puede corregirla.

Las pruebas incluyen problemas de distinto grado de dificultad, desde problemas que habitualmente resuelven casi todos los participantes, a un par de problemas realmente desafiantes. En nuestra página WEB o en la de las competencia Internacional, o la Moaratona de Brasil por ejemplo se pueden ver pruebas anteriores, para darse una idea de como es la competencia.

Gente, les dejo este articulo que encotre buscando cosas para la facu, Es un poco largo pero esta bueno.




How To Write Unmaintainable Code


Ensure a job for life ;-)


Roedy Green

Canadian Mind Products



Never ascribe to malice, that which can be explained by incompetence.
- Napoleon


In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn't be able to maintain the code!

You don't want to overdo this. Your code should not look hopelessly unmaintainable, just be that way. Otherwise it stands the risk of being rewritten or refactored.

General Principles

Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.

To foil the maintenance programmer, you have to understand how he thinks. He has your giant program. He has no time to read it all, much less understand it. He wants to rapidly find the place to make his change, make it and get out and have no unexpected side effects from the change.

He views your code through a toilet paper tube. He can only see a tiny piece of your program at a time. You want to make sure he can never get at the big picture from doing that. You want to make it as hard as possible for him to find the code he is looking for. But even more important, you want to make it as awkward as possible for him to safely ignore anything.

Programmers are lulled into complacency by conventions. By every once in a while, by subtly violating convention, you force him to read every line of your code with a magnifying glass.

You might get the idea that every language feature makes code unmaintainable -- not so, only if properly misused.


"When I use a word," Humpty Dumpty said, in a rather scornful tone, "it means just what I choose it to mean - neither more nor less."
- Lewis Carroll -- Through the Looking Glass, Chapter 6

Much of the skill in writing unmaintainable code is the art of naming variables and methods. They don't matter at all to the compiler. That gives you huge latitude to use them to befuddle the maintenance programmer.

    New Uses For Names For Baby

    Buy a copy of a baby naming book and you'll never be at a loss for variable names. Fred is a wonderful name, and easy to type. If you're looking for easy-to-type variable names, try adsf or aoeu if you type with a DSK keyboard.


    Single Letter Variable Names

    If you call your variables a, b, c, then it will be impossible to search for instances of them using a simple text editor. Further, nobody will be able to guess what they are for. If anyone even hints at breaking the tradition honoured since FØRTRAN of using i, j, and k for indexing variables, namely replacing them with ii, jj and kk, warn them about what the Spanish Inquisition did to heretics.


    Creative Miss-spelling

    If you must use descriptive variable and function names, misspell them. By misspelling in some function and variable names, and spelling it correctly in others (such as SetPintleOpening SetPintalClosing) we effectively negate the use of grep or IDE search techniques. It works amazingly well. Add an international flavor by spelling tory or tori in different theatres/theaters.


    Be Abstract

    In naming functions and variables, make heavy use of abstract words like it, everything, data, handle, stuff, do, routine, perform and the digits e.g. routineX48, PerformDataFunction, DoIt, HandleStuff and do_args_method.



    Use acronyms to keep the code terse. Real men never define acronyms; they understand them genetically.


    Thesaurus Surrogatisation

    To break the boredom, use a thesaurus to look up as much alternate vocabulary as possible to refer to the same action, e.g. display, show, present. Vaguely hint there is some subtle difference, where none exists. However, if there are two similar functions that have a crucial difference, always use the same word in describing both functions (e.g. print to mean "write to a file", "put ink on paper" and "display on the screen"). Under no circumstances, succumb to demands to write a glossary with the special purpose project vocabulary unambiguously defined. Doing so would be an unprofessional breach of the structured design principle of information hiding.


    Use Plural Forms From Other Languages

    A VMS script kept track of the "statii" returned from various "Vaxen". Esperanto , Klingon and Hobbitese qualify as languages for these purposes. For pseudo-Esperanto pluraloj, add oj. You will be doing your part toward world peace.



    Randomly capitalize the first letter of a syllable in the middle of a word. For example ComputeRasterHistoGram().


    Reuse Names

    Wherever the rules of the language permit, give classes, constructors, methods, member variables, parameters and local variables the same names. For extra points, reuse local variable names inside {} blocks. The goal is to force the maintenance programmer to carefully examine the scope of every instance. In particular, in Java, make ordinary methods masquerade as constructors.


    Åccented Letters

    Use accented characters on variable names. E.g.
      typedef struct { int i; } ínt;
    where the second ínt's í is actually i-acute. With only a simple text editor, it's nearly impossible to distinguish the slant of the accent mark.


    Exploit Compiler Name Length Limits

    If the compiler will only distinguish the first, say, 8 characters of names, then vary the endings e.g. var_unit_update() in one case and var_unit_setup() in another. The compiler will treat both as var_unit.


    Underscore, a Friend Indeed

    Use _ and __ as identifiers.


    Mix Languages

    Randomly intersperse two languages (human or computer). If your boss insists you use his language, tell him you can organise your thoughts better in your own language, or, if that does not work, allege linguistic discrimination and threaten to sue your employers for a vast sum.


    Extended ASCII

    Extended ASCII characters are perfectly valid as variable names, including ß, Ð, and ñ characters. They are almost impossible to type without copying/pasting in a simple text editor.


    Names From Other Languages

    Use foreign language dictionaries as a source for variable names. For example, use the German punkt for point. Maintenance coders, without your firm grasp of German, will enjoy the multicultural experience of deciphering the meaning.


    Names From Mathematics

    Choose variable names that masquerade as mathematical operators, e.g.:
      openParen = (slash + asterix) / equals;


    Bedazzling Names

    Choose variable names with irrelevant emotional connotation. e.g.:
      marypoppins = (superman + starship) / god;
    This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they're trying to think about.


    Rename and Reuse

    This trick works especially well in Ada, a language immune to many of the standard obfuscation techniques. The people who originally named all the objects and packages you use were morons. Rather than try to convince them to change, just use renames and subtypes to rename everything to names of your own devising. Make sure to leave a few references to the old names in, as a trap for the unwary.


    When To Use i

    Never use i for the innermost loop variable. Use anything but. Use i liberally for any other purpose especially for non-int variables. Similarly use n as a loop index.


    Conventions Schmentions

    Ignore the Sun Java Coding Conventions, after all, Sun does. Fortunately, the compiler won't tattle when you violate them. The goal is to come up with names that differ subtlely only in case. If you are forced to use the capitalisation conventions, you can still subvert wherever the choice is ambigous, e.g. use both inputFilename and inputfileName. Invent your own hopelessly complex naming conventions, then berate everyone else for not following them.


    Lower Case l Looks a Lot Like the Digit 1

    Use lower case l to indicate long constants. e.g. 10l is more likely to be mistaken for 101 that 10L is. Ban any fonts that clearly disambiguate uvw wW gq9 2z 5s il17|!j oO08 `'" ;,. m nn rn {[()]}. Be creative.


    Reuse of Global Names as Private

    Declare a global array in module A, and a private one of the same name in the header file for module B, so that it appears that it's the global array you are using in module B, but it isn't. Make no reference in the comments to this duplication.


    Recycling Revisited

    Use scoping as confusingly as possible by recycling variable names in contradictory ways. For example, suppose you have global variables A and B, and functions foo and bar. If you know that variable A will be regularly passed to foo and B to bar, make sure to define the functions as function foo(B) and function bar(A) so that inside the functions A will always be referred to as B and vice versa. With more functions and globals, you can create vast confusing webs of mutually contradictory uses of the same names.


    Recycle Your Variables

    Wherever scope rules permit, reuse existing unrelated variable names. Similarly, use the same temporary variable for two unrelated purposes (purporting to save stack slots). For a fiendish variant, morph the variable, for example, assign a value to a variable at the top of a very long method, and then somewhere in the middle, change the meaning of the variable in a subtle way, such as converting it from a 0-based coordinate to a 1-based coordinate. Be certain not to document this change in meaning.


    Cd wrttn wtht vwls s mch trsr

    When using abbreviations inside variable or method names, break the boredom with several variants for the same word, and even spell it out longhand once in while. This helps defeat those lazy bums who use text search to understand only some aspect of your program. Consider variant spellings as a variant on the ploy, e.g. mixing International colour, with American color and dude-speak kulerz. If you spell out names in full, there is only one possible way to spell each name. These are too easy for the maintenance programmer to remember. Because there are so many different ways to abbreviate a word, with abbreviations, you can have several different variables that all have the same apparent purpose. As an added bonus, the maintenance programmer might not even notice they are separate variables.


    Misleading names

    Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database.



    a naming convention from the world of C++ is the use of "m_" in front of members. This is supposed to help you tell them apart from methods, so long as you forget that "method" also starts with the letter "m".


    o_apple obj_apple

    Use an "o" or "obj" prefix for each instance of the class to show that you're thinking of the big, polymorphic picture.


    Hungarian Notation

    Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack. The following tips will help you corrupt the original intent of Hungarian Notation:


      Insist on using "c" for const in C++ and other languages that directly enforce the const-ness of a variable.

      Seek out and use Hungarian warts that have meaning in languages other than your current language. For example insist on the PowerBuilder "l_" and "a_ " {local and argument} scoping prefixes and always use the VB-esque style of having a Hungarian wart for every control type when coding to C++. Try to stay ignorant of the fact that megs of plainly visible MFC source code does not use Hungarian warts for control types.

      Always violate the Hungarian principle that the most commonly used variables should carry the least extra information around with them. Achieve this end through the techniques outlined above and by insisting that each class type have a custom wart prefix. Never allow anyone to remind you that no wart tells you that something is a class. The importance of this rule cannot be overstated if you fail to adhere to its principles the source code may become flooded with shorter variable names that have a higher vowel/consonant ratio. In the worst case scenario this can lead to a full collapse of obfuscation and the spontaneous reappearance of English Notation in code!

      Flagrantly violate the Hungarian-esque concept that function parameters and other high visibility symbols must be given meaningful names, but that Hungarian type warts all by themselves make excellent temporary variable names.

      Insist on carrying outright orthogonal information in your Hungarian warts. Consider this real world example "a_crszkvc30LastNameCol". It took a team of maintenance engineers nearly 3 days to figure out that this whopper variable name described a const, reference, function argument that was holding information from a database column of type Varchar[30] named "LastName" which was part of the table's primary key. When properly combined with the principle that "all variables should be public" this technique has the power to render thousands of lines of source code obsolete instantly!

      Use to your advantage the principle that the human brain can only hold 7 pieces of information concurrently. For example code written to the above standard has the following properties:

      • a single assignment statement carries 14 pieces of type and name information.
      • a single function call that passes three parameters and assigns a result carries 29 pieces of type and name information.
      • Seek to improve this excellent, but far too concise, standard. Impress management and coworkers by recommending a 5 letter day of the week prefix to help isolate code written on 'Monam' and 'FriPM'.
      • It is easy to overwhelm the short term memory with even a moderately complex nesting structure, especially when the maintenance programmer can't see the start and end of each block on screen simultaneously.

    Hungarian Notation Revisited

    One followon trick in the Hungarian notation is "change the type of a variable but leave the variable name unchanged". This is almost invariably done in windows apps with the migration from Win16 :- WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam) to Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) where the w values hint that they are words, but they really refer to longs. The real value of this approach comes clear with the Win64 migration, when the parameters will be 64 bits wide, but the old "w" and "l" prefixes will remain forever.


    Reduce, Reuse, Recycle

    If you have to define a structure to hold data for callbacks, always call the structure PRIVDATA. Every module can define it's own PRIVDATA. In VC++, this has the advantage of confusing the debugger so that if you have a PRIVDATA variable and try to expand it in the watch window, it doesn't know which PRIVDATA you mean, so it just picks one.


    Obscure film references

    Use constant names like LancelotsFavouriteColour instead of blue and assign it hex value of $0204FB. The color looks identical to pure blue on the screen, and a maintenance programmer would have to work out 0204FB (or use some graphic tool) to know what it looks like. Only someone intimately familiar with Monty Python and the Holy Grail would know that Lancelot's favorite color was blue. If a maintenance programmer can't quote entire Monty Python movies from memory, he or she has no business being a programmer.


The longer it takes for a bug to surface, the harder it is to find.
- Roedy Green

Much of the skill in writing unmaintainable code is the art of camouflage, hiding things, or making things appear to be what they are not. Many depend on the fact the compiler is more capable at making fine distinctions than either the human eye or the text editor. Here are some of the best camouflaging techniques.

    Code That Masquerades As Comments and Vice Versa

    Include sections of code that is commented out but at first glance does not appear to be.
      for(j=0; j<array_len; j+ =8)
        total += array[j+0 ];
        total += array[j+1 ];
        total += array[j+2 ]; /* Main body of
        total += array[j+3]; * loop is unrolled
        total += array[j+4]; * for greater speed.
        total += array[j+5]; */

        total += array[j+6 ];
        total += array[j+7 ];
    Without the colour coding would you notice that three lines of code are commented out?



    Struct/union and typedef struct/union are different name spaces in C (not in C++). Use the same name in both name spaces for structures or unions. Make them, if possible, nearly compatible.
      typedef struct {
      char* pTr;
      size_t lEn;
      } snafu;

      struct snafu {
      unsigned cNt
      char* pTr;
      size_t lEn;
      } A;


    Hide Macro Definitions

    Hide macro definitions in amongst rubbish comments. The programmer will get bored and not finish reading the comments thus never discover the macro. Ensure that the macro replaces what looks like a perfectly legitimate assignment with some bizarre operation, a simple example:
      #define a=b a=0-b


    Look Busy

    use define statements to make made up functions that simply comment out their arguments, e.g.:
      #define fastcopy(x,y,z) /*xyz*/
      fastcopy(array1, array2, size); /* does nothing */


    Use Continuation to hide variables

    Instead of using
      #define local_var xy_z
    break up "xy_z" onto two lines:
      #define local_var xy\
      _z // local_var OK
    That way a global search for xy_z will come up with nothing for that file. To the C preprocessor, the "\" at the end of the line means glue this line to the next one.


    Arbitrary Names That Masquerade as Keywords

    When documenting, and you need an arbitrary name to represent a filename use "file ". Never use an obviously arbitrary name like "Charlie.dat" or "Frodo.txt". In general, in your examples, use arbitrary names that sound as much like reserved keywords as possible. For example, good names for parameters or variables would be"bank", "blank", "class", "const ", "constant", "input", "key", "keyword", "kind", "output", "parameter" "parm", "system", "type", "value", "var" and "variable ". If you use actual reserved words for your arbitrary names, which would be rejected by your command processor or compiler, so much the better. If you do this well, the users will be hopelessly confused between reserved keywords and arbitrary names in your example, but you can look innocent, claiming you did it to help them associate the appropriate purpose with each variable.


    Code Names Must Not Match Screen Names

    Choose your variable names to have absolutely no relation to the labels used when such variables are displayed on the screen. E.g. on the screen label the field "Postal Code" but in the code call the associated variable "zip".


    Don't Change Names

    Instead of globally renaming to bring two sections of code into sync, use multiple TYPEDEFs of the same symbol.


    How to Hide Forbidden Globals

    Since global variables are "evil", define a structure to hold all the things you'd put in globals. Call it something clever like EverythingYoullEverNeed. Make all functions take a pointer to this structure (call it handle to confuse things more). This gives the impression that you're not using global variables, you're accessing everything through a "handle". Then declare one statically so that all the code is using the same copy anyway.


    Hide Instances With Synonyms

    Maintenance programmers, in order to see if they'll be any cascading effects to a change they make, do a global search for the variables named. This can be defeated by this simple expedient of having synonyms, such as
      #define xxx global_var // in file std.h
      #define xy_z xxx // in file ..\other\substd.h
      #define local_var xy_z // in file ..\codestd\inst.h
    These defs should be scattered through different include-files. They are especially effective if the include-files are located in different directories. The other technique is to reuse a name in every scope. The compiler can tell them apart, but a simple minded text searcher cannot. Unfortunately SCIDs in the coming decade will make this simple technique impossible. since the editor understands the scope rules just as well as the compiler.


    Long Similar Variable Names

    Use very long variable names or class names that differ from each other by only one character, or only in upper/lower case. An ideal variable name pair is swimmer and swimner. Exploit the failure of most fonts to clearly discriminate between ilI1| or oO08with identifier pairs like parselnt and parseInt or D0Calc and DOCalc. l is an exceptionally fine choice for a variable name since it will, to the casual glance, masquerade as the constant 1. In many fonts rn looks like an m. So how about a variable swirnrner. Create variable names that differ from each other only in case e.g. HashTable and Hashtable.


    Similar-Sounding Similar-Looking Variable Names

    Although we have one variable named xy_z, there's certainly no reason not to have many other variables with similar names, such as xy_Z, xy__z, _xy_z, _xyz, XY_Z, xY_z, and Xy_z.

    Variables that resemble others except for capitalization and underlines have the advantage of confounding those who like remembering names by sound or letter-spelling, rather than by exact representations.


    Overload and Bewilder

    In C++, overload library functions by using #define. That way it looks like you are using a familiar library function where in actuality you are using something totally different.


    Choosing The Best Overload Operator

    In C++, overload +,-,*,/ to do things totally unrelated to addition, subtraction etc. After all, if the Stroustroup can use the shift operator to do I/O, why should you not be equally creative? If you overload +, make sure you do it in a way that i = i + 5; has a totally different meaning from i += 5; Here is an example of elevating overloading operator obfuscation to a high art. Overload the '!' operator for a class, but have the overload have nothing to do with inverting or negating. Make it return an integer. Then, in order to get a logical value for it, you must use '! !'. However, this inverts the logic, so [drum roll] you must use '! ! !'. Don't confuse the ! operator, which returns a boolean 0 or 1, with the ~ bitwise logical negation operator.


    Overload new

    Overload the "new" operator - much more dangerous than overloading the +-/*. This can cause total havoc if overloaded to do something different from it's original function (but vital to the object's function so it's very difficult to change). This should ensure users trying to create a dynamic instance get really stumped. You can combine this with the case sensitivity trickalso have a member function, and variable called "New".



    #define in C++ deserves an entire essay on its own to explore its rich possibilities for obfuscation. Use lower case #define variables so they masquerade as ordinary variables. Never use parameters to your preprocessor functions. Do everything with global #defines. One of the most imaginative uses of the preprocessor I have heard of was requiring five passes through CPP before the code was ready to compile. Through clever use of defines and ifdefs, a master of obfuscation can make header files declare different things depending on how many times they are included. This becomes especially interesting when one header is included in another header. Here is a particularly devious example:
      #ifndef DONE

      #ifdef TWICE

      // put stuff here to declare 3rd time around
      void g(char* str);
      #define DONE

      #else // TWICE
      #ifdef ONCE

      // put stuff here to declare 2nd time around
      void g(void* str);
      #define TWICE

      #else // ONCE

      // put stuff here to declare 1st time around
      void g(std::string str);
      #define ONCE

      #endif // ONCE
      #endif // TWICE
      #endif // DONE
    This one gets fun when passing g() a char*, because a different version of g() will be called depending on how many times the header was included.


    Compiler Directives

    Compiler directives were designed with the express purpose of making the same code behave completely differently. Turn the boolean short-circuiting directive on and off repeatedly and vigourously, as well as the long strings directive.


Any fool can tell the truth, but it requires a man of some sense to know how to lie well.
- Samuel Butler (1835 - 1902)


Incorrect documentation is often worse than no documentation.
- Bertrand Meyer

Since the computer ignores comments and documentation, you can lie outrageously and do everything in your power to befuddle the poor maintenance programmer.

    Lie in the comments

    You don't have to actively lie, just fail to keep comments as up to date with the code.


    Document the obvious

    Pepper the code with comments like /* add 1 to i */ however, never document wooly stuff like the overall purpose of the package or method.


    Document How Not Why

    Document only the details of what a program does, not what it is attempting to accomplish. That way, if there is a bug, the fixer will have no clue what the code should be doing.


    Avoid Documenting the "Obvious"

    If, for example, you were writing an airline reservation system, make sure there are at least 25 places in the code that need to be modified if you were to add another airline. Never document where they are. People who come after you have no business modifying your code without thoroughly understanding every line of it.


    On the Proper Use Of Documentation Templates

    Consider function documentation prototypes used to allow automated documentation of the code. These prototypes should be copied from one function (or method or class) to another, but never fill in the fields. If for some reason you are forced to fill in the fields make sure that all parameters are named the same for all functions, and all cautions are the same but of course not related to the current function at all.


    On the Proper Use of Design Documents

    When implementing a very complicated algorithm, use the classic software engineering principles of doing a sound design before beginning coding. Write an extremely detailed design document that describes each step in a very complicated algorithm. The more detailed this document is, the better.

    In fact, the design doc should break the algorithm down into a hierarchy of structured steps, described in a hierarchy of auto-numbered individual paragraphs in the document. Use headings at least 5 deep. Make sure that when you are done, you have broken the structure down so completely that there are over 500 such auto-numbered paragraphs. For example, one paragraph might be(this is a real example) - Display all impacts for activity where selected mitigations can apply (short pseudocode omitted).

    then... (and this is the kicker) when you write the code, for each of these paragraphs you write a corresponding global function named:

    Do not document these functions. After all, that's what the design document is for!

    Since the design doc is auto-numbered, it will be extremely difficult to keep it up to date with changes in the code (because the function names, of course, are static, not auto-numbered.) This isn't a problem for you because you will not try to keep the document up to date. In fact, do everything you can to destroy all traces of the document.

    Those who come after you should only be able to find one or two contradictory, early drafts of the design document hidden on some dusty shelving in the back room near the dead 286 computers.


    Units of Measure

    Never document the units of measure of any variable, input, output or parameter. e.g. feet, metres, cartons. This is not so important in bean counting, but it is very important in engineering work. As a corollary, never document the units of measure of any conversion constants, or how the values were derived. It is mild cheating, but very effective, to salt the code with some incorrect units of measure in the comments. If you are feeling particularly malicious, make up your own unit of measure; name it after yourself or some obscure person and never define it. If somebody challenges you, tell them you did so that you could use integer rather than floating point arithmetic.



    Never document gotchas in the code. If you suspect there may be a bug in a class, keep it to yourself. If you have ideas about how the code should be reorganised or rewritten, for heaven's sake, do not write them down. Remember the words of Thumper in the movie Bambi "If you can't say anything nice, don't say anything at all". What if the programmer who wrote that code saw your comments? What if the owner of the company saw them? What if a customer did? You could get yourself fired. An anonymous comment that says "This needs to be fixed!" can do wonders, especially if it's not clear what the comment refers to. Keep it vague, and nobody will feel personally criticised.


    Documenting Variables

    Never put a comment on a variable declaration. Facts about how the variable is used, its bounds, its legal values, its implied/displayed number of decimal points, its units of measure, its display format, its data entry rules (e.g. total fill, must enter), when its value can be trusted etc. should be gleaned from the procedural code. If your boss forces you to write comments, lard method bodies with them, but never comment a variable declaration, not even a temporary!


    Disparage In the Comments

    Discourage any attempt to use external maintenance contractors by peppering your code with insulting references to other leading software companies, especial anyone who might be contracted to do the work. e.g.:
      /* The optimised inner loop.
      This stuff is too clever for the dullard at Software Services Inc., who would
      probably use 50 times as memory & time using the dumb routines in <math.h>.

      class clever_SSInc
        .. .
    If possible, put insulting stuff in syntactically significant parts of the code, as well as just the comments so that management will probably break the code if they try to sanitise it before sending it out for maintenance.



    Always refuse to accept advances in the development environment arena, especially SCIDs. Disbelieve rumors that all function and variable declarations are never more than one click away and always assume that code developed in Visual Studio 6.0 will be maintained by someone using edlin or vi. Insist on Draconian commenting rules to bury the source code proper.


    Monty Python Comments

    On a method called makeSnafucated insert only the JavaDoc /* make snafucated */. Never define what snafucated means anywhere. Only a fool does not already know, with complete certainty, what snafucated means. For classic examples of this technique, consult the Sun AWT JavaDOC.

Program Design

The cardinal rule of writing unmaintainable code is to specify each fact in as many places as possible and in as many ways as possible.
- Roedy Green


    The key to writing maintainable code is to specify each fact about the application in only one place. To change your mind, you need change it in only one place, and you are guaranteed the entire program will still work. Therefore, the key to writing unmaintainable code is to specify a fact over and over, in as many places as possible, in as many variant ways as possible. Happily, languages like Java go out of their way to make writing this sort of unmaintainable code easy. For example, it is almost impossible to change the type of a widely used variable because all the casts and conversion functions will no longer work, and the types of the associated temporary variables will no longer be appropriate. Further, if the variable is displayed on the screen, all the associated display and data entry code has to be tracked down and manually modified. The Algol family of languages which include C and Java treat storing data in an array, Hashtable, flat file and database with totally different syntax. In languages like Abundance, and to some extent Smalltalk, the syntax is identical; just the declaration changes. Take advantage of Java's ineptitude. Put data you know will grow too large for RAM, for now into an array. That way the maintenance programmer will have a horrendous task converting from array to file access later. Similarly place tiny files in databases so the maintenance programmer can have the fun of converting them to array access when it comes time to performance tune.


    Java Casts

    Java's casting scheme is a gift from the Gods. You can use it without guilt since the language requires it. Every time you retrieve an object from a Collection you must cast it back to its original type. Thus the type of the variable may be specified in dozens of places. If the type later changes, all the casts must be changed to match. The compiler may or may not detect if the hapless maintenance programmer fails to catch them all (or changes one too many). In a similar way, all matching casts to (short) need to be changed to(int) if the type of a variable changes from short to int. There is a movement afoot in invent a generic cast operator (cast) and a generic conversion operator (convert) that would require no maintenance when the type of variable changes. Make sure this heresy never makes it into the language specification. Vote no on RFE 114691 and on genericity which would eliminate the need for many casts.


    Exploit Java's Redundancy

    Java insists you specify the type of every variable twice. Java programmers are so used to this redundancy they won't notice if you make the two types slightly different, as in this example:
      Bubblegum b = new Bubblegom();
    Unfortunately the popularity of the ++ operator makes it harder to get away with pseudo-redundant code like this:
      swimmer = swimner + 1;


    Never Validate

    Never check input data for any kind of correctness or discrepancies. It will demonstrate that you absolutely trust the company's equipment as well as that you are a perfect team player who trusts all project partners and system operators. Always return reasonable values even when data inputs are questionable or erroneous.


    Be polite, Never Assert

    Avoid the assert() mechanism, because it could turn a three-day debug fest into a ten minute one.


    Avoid Encapsulation

    In the interests of efficiency, avoid encapsulation. Callers of a method need all the external clues they can get to remind them how the method works inside.


    Clone & Modify

    In the name of efficiency, use cut/paste/clone/modify. This works much faster than using many small reusable modules. This is especially useful in shops that measure your progress by the number of lines of code you've written.


    Use Static Arrays

    If a module in a library needs an array to hold an image, just define a static array. Nobody will ever have an image bigger than 512 x 512, so a fixed-size array is OK. For best precision, make it an array of doubles. Bonus effect for hiding a 2 Meg static array which causes the program to exceed the memory of the client's machine and thrash like crazy even if they never use your routine.


    Dummy Interfaces

    Write an empty interface called something like "WrittenByMe", and make all of your classes implement it. Then, write wrapper classes for any of Java's built-in classes that you use. The idea is to make sure that every single object in your program implements this interface. Finally, write all methods so that both their arguments and return types are WrittenByMe. This makes it nearly impossible to figure out what some methods do, and introduces all sorts of entertaining casting requirements. For a further extension, have each team member have his/her own personal interface (e.g., WrittenByJoe); any class worked on by a programmer gets to implement his/her interface. You can then arbitrary refer to objects by any one of a large number of meaningless interfaces!


    Giant Listeners

    Never create separate Listeners for each Component. Always have one listener for every button in your project and simply use massive if...else statements to test for which button was pressed.


    Too Much Of A Good ThingTM

    Go wild with encapsulation and oo. For example:
      myPanel.add( getMyButton() );
      private JButton getMyButton()
        return myButton;
    That one probably did not even seem funny. Don't worry. It will some day.


    Friendly Friend

    Use as often as possible the friend-declaration in C++. Combine this with handing the pointer of the creating class to a created class. Now you don't need to fritter away your time in thinking about interfaces. Additionally you should use the keywords private andprotected to prove that your classes are well encapsulated.


    Use Three Dimensional Arrays

    Lots of them. Move data between the arrays in convoluted ways, say, filling the columns in arrayB with the rows from arrayA. Doing it with an offset of 1, for no apparent reason, is a nice touch. Makes the maintenance programmer nervous.


    Mix and Match

    Use both accessor methods and public variables. That way, you can change an object's variable without the overhead of calling the accessor, but still claim that the class is a "Java Bean". This has the additional advantage of frustrating the maintenence programmer who adds a logging function to try to figure out who is changing the value.


    Wrap, wrap, wrap

    Whenever you have to use methods in code you did not write, insulate your code from that other dirty code by at least one layer of wrapper. After all, the other author might some time in the future recklessly rename every method. Then where would you be? You could of course, if he did such a thing, insulate your code from the changes by writing a wrapper or you could let VAJ handle the global rename. However, this is the perfect excuse to preemptively cut him off at the pass with a wrapper layer of indirection, before he does anything idiotic. One of Java's main faults is that there is no way to solve many simple problems without dummy wrapper methods that do nothing but call another method of the same name, or a closely related name. This means it is possible to write wrappers four-levels deep that do absolutely nothing, and almost no one will notice. To maximise the obscuration, at each level, rename the methods, selecting random synonyms from a thesaurus. This gives the illusion something of note is happening. Further, the renaming helps ensure the lack of consistent project terminology. To ensure no one attempts to prune your levels back to a reasonable number, invoke some of your code bypassing the wrappers at each of the levels.


    Wrap Wrap Wrap Some More

    Make sure all API functions are wrapped at least 6-8 times, with function definitions in separate source files. Using #defines to make handy shortcuts to these functions also helps.


    No Secrets!

    Declare every method and variable public. After all, somebody, sometime might want to use it. Once a method has been declared public, it can't very well be retracted, now can it? This makes it very difficult to later change the way anything works under the covers. It also has the delightful side effect of obscuring what a class is for. If the boss asks if you are out of your mind, tell him you are following the classic principles of transparent interfaces.


    The Kama Sutra

    This technique has the added advantage of driving any users or documenters of the package to distraction as well as the maintenance programmers. Create a dozen overloaded variants of the same method that differ in only the most minute detail. I think it was Oscar Wilde who observed that positions 47 and 115 of the Kama Sutra were the same except in 115 the woman had her fingers crossed. Users of the package then have to carefully peruse the long list of methods to figure out just which variant to use. The technique also balloons the documentation and thus ensures it will more likely be out of date. If the boss asks why you are doing this, explain it is solely for the convenience of the users. Again for the full effect, clone any common logic and sit back and wait for it the copies to gradually get out of sync.


    Permute and Baffle

    Reverse the parameters on a method called drawRectangle(height, width) to drawRectangle(width, height) without making any change whatsoever to the name of the method. Then a few releases later, reverse it back again. The maintenance programmers can't tell by quickly looking at any call if it has been adjusted yet. Generalisations are left as an exercise for the reader.


    Theme and Variations

    Instead of using a parameter to a single method, create as many separate methods as you can. For example instead of setAlignment(int alignment) where alignment is an enumerated constant, for left, right, center, create three methodssetLeftAlignment, setRightAlignment, and setCenterAlignment. Of course, for the full effect, you must clone the common logic to make it hard to keep in sync.


    Static Is Good

    Make as many of your variables as possible static. If you don't need more than one instance of the class in this program, no one else ever will either. Again, if other coders in the project complain, tell them about the execution speed improvement you're getting.


    Cargill's Quandry

    Take advantage of Cargill's quandary (I think this was his) "any design problem can be solved by adding an additional level of indirection, except for too many levels of indirection." Decompose OO programs until it becomes nearly impossible to find a method which actually updates program state. Better yet, arrange all such occurrences to be activated as callbacks from by traversing pointer forests which are known to contain every function pointer used within the entire system. Arrange for the forest traversals to be activated as side-effects from releasing reference counted objects previously created via deep copies which aren't really all that deep.



    Keep all of your unused and outdated methods and variables around in your code. After all - if you needed to use it once in 1976, who knows if you will want to use it again sometime? Sure the program's changed since then, but it might just as easily change back, you "don't want to have to reinvent the wheel" (supervisors love talk like that). If you have left the comments on those methods and variables untouched, and sufficiently cryptic, anyone maintaining the code will be too scared to touch them.


    And That's Final

    Make all of your leaf classes final. After all, you're done with the project - certainly no one else could possibly improve on your work by extending your classes. And it might even be a security flaw - after all, isn't java.lang.String final for just this reason? If other coders in your project complain, tell them about the execution speed improvement you're getting.


    Eschew The Interface

    In Java, disdain the interface. If your supervisors complain, tell them that Java interfaces force you to "cut-and-paste" code between different classes that implement the same interface the same way, and they know how hard that would be to maintain. Instead, do as the Java AWT designers did - put lots of functionality in your classes that can only be used by classes that inherit from them, and use lots of "instanceof" checks in your methods. This way, if someone wants to reuse your code, they have to extend your classes. If they want to reuse your code from two different classes - tough luck, they can't extend both of them at once! If an interface is unavoidable, make an all-purpose one and name it something like "ImplementableIface." Another gem from academia is to append "Impl" to the names of classes that implement interfaces. This can be used to great advantage, e.g. with classes that implement Runnable.


    Avoid Layouts

    Never use layouts. That way when the maintenance programmer adds one more field he will have to manually adjust the absolute co-ordinates of every other thing displayed on the screen. If your boss forces you to use a layout, use a single giant GridBagLayout, and hard code in absolute grid co-ordinates.


    Environment variables

    If you have to write classes for some other programmer to use, put environment-checking code (getenv() in C++ / System.getProperty() in Java) in your classes' nameless static initializers, and pass all your arguments to the classes this way, rather than in the constructor methods. The advantage is that the initializer methods get called as soon as the class program binaries get loaded, even before any of the classes get instantiated, so they will usually get executed before the program main(). In other words, there will be no way for the rest of the program to modify these parameters before they get read into your classes - the users better have set up all their environment variables just the way you had them!


    Table Driven Logic

    Eschew any form of table-driven logic. It starts out innocently enough, but soon leads to end users proofreading and then shudder, even modifying the tables for themselves.


    Modify Mom's Fields

    In Java, all primitives passed as parameters are effectively read-only because they are passed by value. The callee can modify the parameters, but that has no effect on the caller's variables. In contrast all objects passed are read-write. The reference is passed by value, which means the object itself is effectively passed by reference. The callee can do whatever it wants to the fields in your object. Never document whether a method actually modifies the fields in each of the passed parameters. Name your methods to suggest they only look at the fields when they actually change them.


    The Magic Of Global Variables

    Instead of using exceptions to handle error processing, have your error message routine set a global variable. Then make sure that every long-running loop in the system checks this global flag and terminates if an error occurs. Add another global variable to signal when a user presses the 'reset' button. Of course all the major loops in the system also have to check this second flag. Hide a few loops that don't terminate on demand.


    Globals, We Can't Stress These Enough!

    If God didn't want us to use global variables, he wouldn't have invented them. Rather than disappoint God, use and set as many global variables as possible. Each function should use and set at least two of them, even if there's no reason to do this. After all, any good maintenance programmer will soon figure out this is an exercise in detective work, and she'll be happy for the exercise that separates real maintenance programmers from the dabblers.


    Globals, One More Time, Boys

    Global variables save you from having to specify arguments in functions. Take full advantage of this. Elect one or more of these global variables to specify what kinds of processes to do on the others. Maintenance programmers foolishly assume that C functions will not have side effects. Make sure they squirrel results and internal state information away in global variables.


    Side Effects

    In C, functions are supposed to be idempotent, (without side effects). I hope that hint is sufficient.


    Backing Out

    Within the body of a loop, assume that the loop action is successful and immediately update all pointer variables. If an exception is later detected on that loop action, back out the pointer advancements as side effects of a conditional expression following the loop body.


    Local Variables

    Never use local variables. Whenever you feel the temptation to use one, make it into an instance or static variable instead to unselfishly share it with all the other methods of the class. This will save you work later when other methods need similar declarations. C++ programmers can go a step further by making all variables global.


    Reduce, Reuse, Recycle

    If you have to define a structure to hold data for callbacks, always call the structure PRIVDATA. Every module can define it's own PRIVDATA. In VC++, this has the advantage of confusing the debugger so that if you have a PRIVDATA variable and try to expand it in the watch window, it doesn't know which PRIVDATA you mean, so it just picks one.


    Configuration Files

    These usually have the form keyword=value. The values are loaded into Java variables at load time. The most obvious obfuscation technique is to use slightly different names for the keywords and the Java variables. Use configuration files even for constants that never change at run time. Parameter file variables require at least five times as much code to maintain as a simple variable would.


    Bloated classes

    To ensure your classes are bounded in the most obtuse way possible, make sure you include peripheral, obscure methods and attributes in every class. For example, a class that defines astrophysical orbit geometry really should have a method that computes ocean tide schedules and attributes that comprise a Crane weather model. Not only does this over-define the class, it makes finding these methods in the general system code like looking for a guitar pick in a landfill.


    Subclass With Abandon

    Object oriented programming is a godsend for writing unmaintainable code. If you have a class with 10 properties (member/method) in it, consider a base class with only one property and subclassing it 9 levels deep so that each descendant adds one property. By the time you get to the last descendant class, you'll have all 10 properties. If possible, put each class declaration in a separate file. This has the added effect of bloating your INCLUDE or USES statements, and forces the maintainer to open that many more files in his or her editor. Make sure you create at least one instance of each subclass.

Coding Obfuscation

Sedulously eschew obfuscatory hyperverbosity and prolixity.

    Obfuscated C

    Follow the obfuscated C contests on the Internet and sit at the lotus feet of the masters.


    Find a Forth or APL Guru

    In those worlds, the terser your code and the more bizarre the way it works, the more you are revered.


    I'll Take a Dozen

    Never use one housekeeping variable when you could just as easily use two or three.


    Jude the Obscure

    Always look for the most obscure way to do common tasks. For example, instead of using arrays to convert an integer to the corresponding string, use code like this:
      char *p;
      switch (n)
      case 1:
          p = "one";
          if (0)
      case 2:
          p = "two";
          if (0)
      case 3:
          p = "three";
          printf("%s", p);


    Foolish Consistency Is the Hobgoblin of Little Minds

    When you need a character constant, use many different formats ' ', 32, 0x20, 040. Make liberal use of the fact that 10 and 010 are not the same number in C or Java.



    Pass all data as a void * and then typecast to the appropriate structure. Using byte offsets into the data instead of structure casting is fun too.


    The Nested Switch

    (a switch within a switch) is the most difficult type of nesting for the human mind to unravel.


    Exploit Implicit Conversion

    Memorize all of the subtle implicit conversion rules in the programming language. Take full advantage of them. Never use a picture variable (in COBOL or PL/I) or a general conversion routine (such as sprintf in C). Be sure to use floating-point variables as indexes into arrays, characters as loop counters, and perform string functions on numbers. After all, all of these operations are well-defined and will only add to the terseness of your source code. Any maintainer who tries to understand them will be very grateful to you because they will have to read and learn the entire chapter on implicit data type conversion; a chapter that they probably had completely overlooked before working on your programs.


    Raw ints

    When using ComboBoxes, use a switch statement with integer cases rather than named constants for the possible values.



    Always use semicolons whenever they are syntactically allowed. For example:
        int d;
        d = c;

    Use Octal

    Smuggle octal literals into a list of decimal numbers like this:
      array = new int []


    Convert Indirectly

    Java offers great opportunity for obfuscation whenever you have to convert. As a simple example, if you have to convert a double to a String, go circuitously, via Double with new Double(d).toString() rather than the more directDouble.toString(d). You can, of course, be far more circuitous than that! Avoid any conversion techniques recommended by the Conversion Amanuensis. You get bonus points for every extra temporary object you leave littering the heap after your conversion.



    Nest as deeply as you can. Good coders can get up to 10 levels of ( ) on a single line and 20 { } in a single method. C++ coders have the additional powerful option of preprocessor nesting totally independent of the nest structure of the underlying code. You earn extra Brownie points whenever the beginning and end of a block appear on separate pages in a printed listing. Wherever possible, convert nested ifs into nested [? ] ternaries. If they span several lines, so much the better.


    Numeric Literals

    If you have an array with 100 elements in it, hard code the literal 100 in as many places in the program as possible. Never use a static final named constant for the 100, or refer to it as myArray.length. To make changing this constant even more difficult, use the literal 50 instead of 100/2, or 99 instead of 100-1. You can futher disguise the 100 by checking for a == 101 instead of a > 100 or a > 99 instead of a >= 100.

    Consider things like page sizes, where the lines consisting of x header, y body, and z footer lines, you can apply the obfuscations independently to each of these and to their partial or total sums.

    These time-honoured techniques are especially effective in a program with two unrelated arrays that just accidentally happen to both have 100 elements. If the maintenance programmer has to change the length of one of them, he will have to decipher every use of the literal 100 in the program to determine which array it applies to. He is almost sure to make at least one error, hopefully one that won't show up for years later.

    There are even more fiendish variants. To lull the maintenance programmer into a false sense of security, dutifully create the named constant, but very occasionally "accidentally" use the literal 100 value instead of the named constant. Most fiendish of all, in place of the literal 100 or the correct named constant, sporadically use some other unrelated named constant that just accidentally happens to have the value 100, for now. It almost goes without saying that you should avoid any consistent naming scheme that would associate an array name with its size constant.


    C's Eccentric View Of Arrays

    C compilers transform myArray[i] into *(myArray + i), which is equivalent to *(i + myArray) which is equivalent to i[myArray]. Experts know to put this to good use. To really disguise things, generate the index with a function:

    int myfunc(int q, int p) { return p%q; }
    myfunc(6291, 8)[Array];

    Unfortunately, these techniques can only be used in native C classes, not Java.


    L o n g   L i n e s

    Try to pack as much as possible into a single line. This saves the overhead of temporary variables, and makes source files shorter by eliminating new line characters and white space. Tipremove all white space around operators. Good programmers can often hit the 255 character line length limit imposed by some editors. The bonus of long lines is that programmers who cannot read 6 point type must scroll to view them.



    I am going to let you in on a little-known coding secret. Exceptions are a pain in the behind. Properly-written code never fails, so exceptions are actually unnecessary. Don't waste time on them. Subclassing exceptions is for incompetents who know their code will fail. You can greatly simplify your program by having only a single try/catch in the entire application (in main) that calls System.exit(). Just stick a perfectly standard set of throws on every method header whether they could actually throw any exceptions or not.


    When To Use Exceptions

    Use exceptions for non-exceptional conditions. Routinely terminate loops with an ArrayIndexOutOfBoundsException. Pass return standard results from a method in an exception.


    Use threads With Abandon

    title says it all.


    Lawyer Code

    Follow the language lawyer discussions in the newsgroups about what various bits of tricky code should do e.g. a=a++; or f(a++,a++); then sprinkle your code liberally with the examples. In C, the effects of pre/post decrement code such as
      *++b ? (*++b + *(b-1)) 0
    are not defined by the language spec. Every compiler is free to evaluate in a different order. This makes them doubly deadly. Similarly, take advantage of the complex tokenising rules of C and Java by removing all spaces.


    Early Returns

    Rigidly follow the guidelines about no goto, no early returns, and no labelled breaks especially when you can increase the if/else nesting depth by at least 5 levels.


    Avoid {}

    Never put in any { } surrounding your if/else blocks unless they are syntactically obligatory. If you have a deeply nested mixture of if/else statements and blocks, especially with misleading indentation, you can trip up even an expert maintenance programmer. For best results with this technique, use Perl. You can pepper the code with additional ifs after the statements, to amazing effect.


    Tabs From Hell

    Never underestimate how much havoc you can create by indenting with tabs instead of spaces, especially when there is no corporate standard on how much indenting a tab represents. Embed tabs inside string literals, or use a tool to convert spaces to tabs that will do that for you.


    Magic Matrix Locations

    Use special values in certain matrix locations as flags. A good choice is the [3][0] element in a transformation matrix used with a homogeneous coordinate system.


    Magic Array Slots revisited

    If you need several variables of a given type, just define an array of them, then access them by number. Pick a numbering convention that only you know and don't document it. And don't bother to define #define constants for the indexes. Everybody should just know that the global variable widget[15] is the cancel button. This is just an up-to-date variant on using absolute numerical addresses in assembler code.


    Never Beautify

    Never use an automated source code tidier (beautifier) to keep your code aligned. Lobby to have them banned them from your company on the grounds they create false deltas in PVCS/CVS (version control tracking) or that every programmer should have his own indenting style held forever sacrosanct for any module he wrote. Insist that other programmers observe those idiosyncratic conventions in "his " modules. Banning beautifiers is quite easy, even though they save the millions of keystrokes doing manual alignment and days wasted misinterpreting poorly aligned code. Just insist that everyone use the same tidied format, not just for storing in the common repository, but also while they are editing. This starts an RWAR and the boss, to keep the peace, will ban automated tidying. Without automated tidying, you are now free to accidentally misalign the code to give the optical illusion that bodies of loops and ifs are longer or shorter than they really are, or that else clauses match a different if than they really do. e.g.
      if(a) if(b) x=y; else x=z;


    The Macro Preprocessor

    It offers great opportunities for obfuscation. The key technique is to nest macro expansions several layers deep so that you have to discover all the various parts in many different *.hpp files. Placing executable code into macros then including those macros in every *.cpp file (even those that never use those macros) will maximize the amount of recompilation necessary if ever that code changes.


    Exploit Schizophrenia

    Java is schizophrenic about array declarations. You can do them the old C, way String x[], (which uses mixed pre-postfix notation) or the new way String[] x, which uses pure prefix notation. If you want to really confuse people, mix the notationse.g.
      byte[ ] rowvector, colvector , matrix[ ];
    which is equivalent to:
      byte[ ] rowvector;
      byte[ ] colvector;
      byte[ ][] matrix;


    Hide Error Recovery Code

    Use nesting to put the error recovery for a function call as far as possible away from the call. This simple example can be elaborated to 10 or 12 levels of nest:
      if ( function_A() == OK )
        if ( function_B() == OK )
          /* Normal completion stuff */
          /* some error recovery for Function_B */
        /* some error recovery for Function_A */


    Pseudo C

    The real reason for #define was to help programmers who are familiar with another programming language to switch to C. Maybe you will find declarations like #define begin { " or " #define end } useful to write more interesting code.


    Confounding Imports

    Keep the maintenance programmer guessing about what packages the methods you are using are in. Instead of:
      import MyPackage.Read;
      import MyPackage.Write;
      import Mypackage. *;
    Never fully qualify any method or class no matter how obscure. Let the maintenance programmer guess which of the packages/classes it belongs to. Of course, inconsistency in when you fully qualify and how you do your imports helps most.


    Toilet Tubing

    Never under any circumstances allow the code from more than one function or procedure to appear on the screen at once. To achieve this with short routines, use the following handy tricks:
      Blank lines are generally used to separate logical blocks of code. Each line is a logical block in and of itself. Put blank lines between each line.

      Never comment your code at the end of a line. Put it on the line above. If you're forced to comment at the end of the line, pick the longest line of code in the entire file, add 10 spaces, and left-align all end-of-line comments to that column.

      Comments at the top of procedures should use templates that are at least 15 lines long and make liberal use of blank lines. Here's a handy template:
      /* Procedure Name:
      /* Original procedure name:
      /* Author:
      /* Date of creation:
      /* Dates of modification:
      /* Modification authors:
      /* Original file name:
      /* Purpose:
      /* Intent:
      /* Designation:
      /* Classes used:
      /* Constants:
      /* Local variables:
      /* Parameters:
      /* Date of creation:
      /* Purpose:

    The technique of putting so much redundant information in documentation almost guarantees it will soon go out of date, and will help befuddle maintenance programmers foolish enough to trust it.


I don't need to test my programs. I have an error-correcting modem.
- Om I. Baud

Leaving bugs in your programs gives the maintenance programmer who comes along later something interesting to do. A well done bug should leave absolutely no clue as to when it was introduced or where. The laziest way to accomplish this is simply never to test your code.

    Never Test

    Never test any code that handles the error cases, machine crashes, or OS glitches. Never check return codes from the OS. That code never gets executed anyway and slows down your test times. Besides, how can you possibly test your code to handle disk errors, file read errors, OS crashes, and all those sorts of events? Why, you would have to either an incredibly unreliable computer or a test scaffold that mimicked such a thing. Modern hardware never fails, and who wants to write code just for testing purposes? It isn't any fun. If users complain, just blame the OS or hardware. They'll never know.


    Never, Ever Do Any Performance Testing

    Hey, if it isn't fast enough, just tell the customer to buy a faster machine. If you did do performance testing, you might find a bottleneck, which might lead to algorithm changes, which might lead to a complete redesign of your product. Who wants that? Besides, performance problems that crop up at the customer site mean a free trip for you to some exotic location. Just keep your shots up-to-date and your passport handy.


    Never Write Any Test Cases

    Never perform code coverage or path coverage testing. Automated testing is for wimps. Figure out which features account for 90% of the uses of your routines, and allocate 90% of the tests to those paths. After all, this technique probably tests only about 60% of your source code, and you have just saved yourself 40% of the test effort. This can help you make up the schedule on the back-end of the project. You'll be long gone by the time anyone notices that all those nice "marketing features" don't work. The big, famous software companies test code this way; so should you. And if for some reason, you are still around, see the next item.


    Testing is for cowards

    A brave coder will bypass that step. Too many programmers are afraid of their boss, afraid of losing their job, afraid of customer hate mail and afraid of being sued. This fear paralyzes action, and reduces productivity. Studies have shown that eliminating the test phase means that managers can set ship dates well in advance, an obvious aid in the planning process. With fear gone, innovation and experimentation can blossom. The role of the programmer is to produce code, and debugging can be done by a cooperative effort on the part of the help desk and the legacy maintenance group.

    If we have full confidence in our coding ability, then testing will be unnecessary. If we look at this logically, then any fool can recognise that testing does not even attempt to solve a technical problem, rather, this is a problem of emotional confidence. A more efficient solution to this lack of confidence issue is to eliminate testing completely and send our programmers to self-esteem courses. After all, if we choose to do testing, then we have to test every program change, but we only need to send the programmers to one course on building self-esteem. The cost benefit is as amazing as it is obvious.


    Ensuring It Only Works In Debug Mode

    If you've defined TESTING as 1
      #define TESTING 1
    this gives you the wonderful opportunity to have separate code sections, such as
      #if TESTING==1
    which can contain such indispensable tidbits as
      x = rt_val;
    so that if anyone resets TESTING to 0, the program won't work. And with the tiniest bit of imaginative work, it will not only befuddle the logic, but confound the compiler as well.

Choice Of Language

Philosophy is a battle against the bewitchment of our intelligence by means of language.
- Ludwig Wittgenstein

Computer languages are gradually evolving to become more fool proof. Using state of the art languages is unmanly. Insist on using the oldest language you can get away with, octal machine language if you can (Like Hans und Frans, I am no girlie man; I am so virile I used to code by plugging gold tipped wires into a plugboard of IBM unit record equipment (punch cards), or by poking holes in paper tape with a hand punch), failing that assembler, failing that FORTRAN or COBOL, failing that C, and BASIC, failing that C++.


    Write all your code in FORTRAN. If your boss ask why, you can reply that there are lots of very useful libraries that you can use thus saving time. However the chances of writing maintainable code in FORTRAN are zero, and therefore following the unmaintainable coding guidelines is a lot easier.


    Avoid Ada

    About 20% of these techniques can't be used in Ada. Refuse to use Ada. If your manager presses you, insist that no-one else uses it, and point out that it doesn't work with your large suite of tools like lint and plummer that work around C's failings.


    Use ASM

    Convert all common utility functions into asm.


    Use QBASIC

    Leave all important library functions written in QBASIC, then just write an asm wrapper to handle the large->medium memory model mapping.


    Inline Assembler

    Sprinkle your code with bits of inline assembler just for fun. Almost no one understands assembler anymore. Even a few lines of it can stop a maintenance programmer cold.


    MASM call C

    If you have assembler modules which are called from C, try to call C back from the assembler as often as possible, even if it's only for a trivial purpose and make sure you make full use of the goto, bcc and other charming obfuscations of assembler.


    Avoid Maintainability Tools

    Avoid coding in Abundance, or using any of its principles kludged into other languages. It was designed from the ground up with the primary goal of making the maintenance programmer's job easier. Similarly avoid Eiffel or Ada since they were designed to catch bugs before a program goes into production.

Dealing With Others

Hell is other people.
- Jean-Paul Sartre, No Exit, 1934

There are many hints sprinkled thoroughout the tips above on how to rattle maintenance programmers though frustration, and how to foil your boss's attempts to stop you from writing unmaintainable code, or even how to foment an RWAR that involves everyone on the topic of how code should be formatted in the repository.

    Your Boss Knows Best

    If your boss thinks that his or her 20 year old FORTRAN experience is an excellent guide to contemporary programming, rigidly follow all his or her recommendations. As a result, the boss will trust you. That may help you in your career. You will learn many new methods to obfuscate program code.


    Subvert The Help Desk

    One way to help ensure the code is full of bugs is to ensure the maintenance programmers never hear about them. This requires subverting the help desk. Never answer the phone. Use an automated voice that says "thank you for calling the helpline. To reach a real person press "1" or leave a voice mail wait for the tone". Email help requests should be ignored other than to assign them a tracking number. The standard response to any problem is " I think your account is locked out. The person able to authorise reinstatement is not available just now."


    Keep Your Mouth Shut

    Be never vigilant of the next Y2K. If you ever spot something that could sneak up on a fixed deadline and destroy all life in the western hemisphere then do not openly discuss it until we are under the critical 4 year event window of panic and opportunity. Do not tell friends, coworkers, or other competent people of your discovery. Under no circumstances attempt to publish anything that might hint at this new and tremendously profitable threat. Do send one normal priority, jargon encrypted, memo to upper management to cover-your-a$$. If at all possible attach the jargon encrypted information as a rider on an otherwise unrelated plain-text memo pertaining to a more immediately pressing business concern. Rest assured that we all see the threat too. Sleep sound at night knowing that long after you've been forced into early retirement you will be begged to come back at a logarithmically increased hourly rate!


    Baffle 'Em With Bullshit

    Subtlety is a wonderful thing, although sometimes a sledge-hammer is more subtle than other tools. So, a refinement on misleading comments create classes with names like FooFactory containing comments with references to the GoF creational patterns (ideally with http links to bogus UML design documents) that have nothing to do with object creation. Play off the maintainer's delusions of competence. More subtly, create Java classes with protected constructors and methods like Foo f = Foo.newInstance()that return actual new instances, rather than the expected singleton. The opportunities for side-effects are endless.


    Book Of The Month Club

    Join a computer book of the month club. Select authors who appear to be too busy writing books to have had any time to actually write any code themselves. Browse the local bookstore for titles with lots of cloud diagrams in them and no coding examples. Skim these books to learn obscure pedantic words you can use to intimidate the whippersnappers that come after you. Your code should impress. If people can't understand your vocabulary, they must assume that you are very intelligent and that your algorithms are very deep. Avoid any sort of homely analogies in your algorithm explanations.

Roll Your Own

You've always wanted to write system level code. Now is your chance. Ignore the standard libraries and write your own. It will look great on your resumé.

    Roll Your Own BNF

    Always document your command syntax with your own, unique, undocumented brand of BNF notation. Never explain the syntax by providing a suite of annotated sample valid and invalid commands. That would demonstrate a complete lack of academic rigour. Railway diagrams are almost as gauche. Make sure there is no obvious way of telling a terminal symbol (something you would actually type) from an intermediate one -- something that represents a phrase in the syntax. Never use typeface, colour, caps, or any other visual clues to help the reader distinguish the two. Use the exact same punctuation glyphs in your BNF notation that you use in the command language itself, so the reader can never tell if a (...), [...], {...} or "..." is something you actually type as part of the command, or is intended to give clues about which syntax elements are obligatory, repeatable or optional in your BNF notation. After all, if they are too stupid to figure out your variant of BNF, they have no business using your program.


    Roll Your Own Allocator

    Everyone knows that debugging your dynamic storage is complicated and time consuming. Instead of making sure each class has no storage leaks, reinvent your own storage allocator. It just mallocs space out of a big arena. Instead of freeing storage, force your users to periodically perform a system reset that clears the heap. There's only a few things the system needs to keep track of across resets -- lots easier than plugging all the storage leaks; and so long as the users remember to periodically reset the system, they'll never run out of heap space. Imagine them trying to change this strategy once deployed!

Tricks In Offbeat Languages

Programming in Basic causes brain damage.
- Edsger Wybe Dijkstra


    SQL Aliasing

    Alias table names to one or two letters. Better still alias them to the names of other unrelated existing tables.


    SQL Outer Join

    Mix the various flavours of outer join syntax just to keep everyone on their toes.


    JavaScript Scope

    "Optimise" JavaScript code taking advantage of the fact a function can access all local variables in the scope of the caller.


    Visual Basic Declarations

    Instead of:
      dim Count_num as string
      dim Color_var as string
      dim counter as integer
      Dim Count_num$, Color_var$, counter%


    Visual Basic Madness

    If reading from a text file, read 15 characters more than you need to then embed the actual text string like so:
      ReadChars = .ReadChars (29,0)
      ReadChar = trim(left(mid(ReadChar,len(ReadChar)-15,len(ReadChar)-5),7))
      If ReadChars = "alongsentancewithoutanyspaces"
      Mid,14,24 = "withoutanys"
      and left,5 = "without"


    Delphi/Pascal Only

    Don't use functions and procedures. Use the label/goto statements then jump around a lot inside your code using this. It'll drive 'em mad trying to trace through this. Another idea, is just to use this for the hang of it and scramble your code up jumping to and fro in some haphazard fashion.



    Use trailing if's and unless's especially at the end of really long lines.



    LISP is a dream language for the writer of unmaintainable code. Consider these baffling fragments:
      (lambda (*<8-]= *<8-[= ) (or *<8-]= *<8-[= ))

      (defun :-] (<) (= < 2))

      (defun !(!)(if(and(funcall(lambda(!)(if(and '(< 0)(< ! 2))1 nil))(1+ !))
      (not(null '(lambda(!)(if(< 1 !)t nil)))))1(* !(!(1- !)))))

  • Visual Foxpro

    This one is specific to Visual Foxpro. A variable is undefined and can't be used unless you assign a value to it. This is what happens when you check a variable's type:
      lcx = TYPE('somevariable')
    The value of lcx will be 'U' or undefined. BUT if you assign scope to the variable it sort of defines it and makes it a logical FALSE. Neat, huh!?
      LOCAL lcx
      lcx = TYPE('somevariable')
    The value of lcx is now 'L' or logical. It is further defined the value of FALSE. Just imagine the power of this in writing unmaintainable code.
      LOCAL lc_one, lc_two, lc_three... , lc_nIF lc_one
      DO some_incredibly_complex_operation_that_will_neverbe_executed WITH
      ENDIFIF lc_two
      DO some_incredibly_complex_operation_that_will_neverbe_executed WITH
      ENDIFPROCEDURE some_incredibly_complex_oper....
      * put tons of code here that will never be executed
      * why not cut and paste your main procedure!

Miscellaneous Techniques

If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime.
- Anonymous
  1. Don't Recompile

    Let's start off with probably the most fiendish technique ever devised: Compile the code to an executable. If it works, then just make one or two small little changes in the source each module. But don't bother recompiling these. You can do that later when you have more time, and when there's time for debugging. When the hapless maintenance programmer years later makes a change and the code no longer works, she will erroneously assume it must be something she recently changed. You will send her off on a wild goose chase that will keep her busy for weeks.
  2. Foiling Debuggers

    A very simple way to confound people trying to understand your code by tracing it with a line debugger, is to make the lines long. In particular, put the then clause on the same line as the if. They can't place breakpoints. They can't tell which branch of an if was taken.
  3. S.I. vs American Measure

    In engineering work there are two ways to code. One is to convert all inputs to S.I. (metric) units of measure, then do your calculations then convert back to various civil units of measure for output. The other is to maintain the various mixed measure systems throughout. Always choose the second. It's the American way!
  4. CANI

    Constant And Never-ending Improvement. Make "improvements" to your code often, and force users to upgrade often - after all, no one wants to be running an outdated version. Just because they think they're happy with the program as it is, just think how much happier they will be after you've "fixed" it! Don't tell anyone what the differences between versions are unless you are forced to - after all, why tell someone about bugs in the old version they might never have noticed otherwise?
  5. About Box

    The About Box should contain only the name of the program, the names of the coders and a copyright notice written in legalese. Ideally it should link to several megs of code that produce an entertaining animated display. However, it should never contain a description of what the program is for, its minor version number, or the date of the most recent code revision, or the website where to get the updates, or the author's email address. This way all the users will soon all be running on different versions, and will attempt to install version N+2 before installing version N+1.
  6. Ch ch ch Changes

    The more changes you can make between versions the better, you don't want users to become bored with the same old API or user interface year after year. Finally, if you can make this change without the users noticing, this is better still - it will keep them on their toes, and keep them from becoming complacent.
  7. Put C Prototypes In Individual Files

    instead of common headers. This has the dual advantage of requiring a change in parameter data type to be maintained in every file, and avoids any chance that the compiler or linker will detect type mismatches. This will be especially helpful when porting from 32 -> 64 bit platforms.
  8. No Skill Required

    You don't need great skill to write unmaintainable code. Just leap in and start coding. Keep in mind that management still measures productivity in lines of code even if you have to delete most of it later.
  9. Carry Only One Hammer

    Stick with what you know and travel light; if you only carry a hammer then all problems are nails.
  10. Standards Schmandards

    Whenever possible ignore the coding standards currently in use by thousands of developers in your project's target language and environment. For example insist on STL style coding standards when writing an MFC based application.
  11. Reverse the Usual True False Convention

    Reverse the usual definitions of true and false. Sounds very obvious but it works great. You can hide:
      #define TRUE 0
      #define FALSE 1
    somewhere deep in the code so that it is dredged up from the bowels of the program from some file that noone ever looks at anymore. Then force the program to do comparisons like:
      if ( var == TRUE )
      if ( var != FALSE )
    someone is bound to "correct" the apparent redundancy, and use var elsewhere in the usual way:
      if ( var )
    Another technique is to make TRUE and FALSE have the same value, though most would consider that out and out cheating. Using values 1 and 2 or -1 and 0 is a more subtle way to trip people up and still look respectable. You can use this same technique in Java by defining a static constant called TRUE. Programmers might be more suspicious you are up to no good since there is a built-in literal true in Java.
  12. Third Party Libraries

    Include powerful third party libraries in your project and then don't use them. With practice you can remain completely ignorant of good tools and add the unused tools to your resumé in your "Other Tools" section.
  13. Avoid Libraries

    Feign ignorance of libraries that are directly included with your development tool. If coding in Visual C++ ignore the presence of MFC or the STL and code all character strings and arrays by hand; this helps keep your pointer skills sharp and it automatically foils any attempts to extend the code.
  14. Create a Build Order

    Make it so elaborate that no maintainer could ever get any of his or her fixes to compile. Keep secret SmartJ which renders make scripts almost obsolete. Similarly, keep secret that the javac compiler is also available as a class. On pain of death, never reveal how easy it is to write and maintain a speedy little custom java program to find the files and do the make that directly invokes the compile class.
  15. More Fun With Make

    Have the makefile-generated-batch-file copy source files from multiple directories with undocumented overrwrite rules. This permits code branching without the need for any fancy source code control system, and stops your successors ever finding out which version of DoUsefulWork() is the one they should edit.
  16. Collect Coding Standards

    Find all the tips you can on writing maintainable code such as the Square Box Suggestions and flagrantly violate them.
  17. IDE, Not Me!

    Put all the code in the makefileyour successors will be really impressed how you managed to write a makefile which generates a batch file that generates some header files and then builds the app, such that they can never tell what effects a change will have, or be able to migrate to a modern IDE. For maximum effect use an obsolete make tool, such as an early brain dead version of NMAKE without the notion of dependencies.
  18. Bypassing Company Coding Standards

    Some companies have a strict policy of no numeric literals; you must use named constants. It is fairly easy to foil the intent of this policy. For example, one clever C++ programmer wrote:
      #define K_ONE 1
      #define K_TWO 2
      #define K_THOUSAND 999
  19. Compiler Warnings

    Be sure to leave in some compiler warnings. Use the handy "-" prefix in make to suppress the failure of the make due to any and all compiler errors. This way, if a maintenance programmer carelessly inserts an error into your source code, the make tool will nonetheless try to rebuild the entire package; it might even succeed! And any programmer who compiles your code by hand will think that they have broken some existing code or header when all that has really happened is that they have stumbled across your harmless warnings. They will again be grateful to you for the enjoyment of the process that they will have to follow to find out that the error was there all along. Extra bonus points make sure that your program cannot possibly compile with any of the compiler error checking diagnostics enabled. Sure, the compiler may be able to do subscripts bounds checking, but real programmers don't use this feature, and neither should you. Why let the compiler check for errors when you can use your own lucrative and rewarding time to find these subtle bugs?
  20. Combine Bug Fixes With Upgrades

    Never put out a "bug fix only" release. Be sure to combine bug fixes with database format changes, complex user interface changes, and complete rewrites of the administration interfaces. That way, it will be so hard to upgrade that people will get used to the bugs and start calling them features. And the people that really want these "features" to work differently will have an incentive to upgrade to the new versions. This will save you maintenance work in the long run, and get you more revenue from your customers.
  21. Change File Formats With Each Release Of Your Product

    Yeah, your customers will demand upwards compatibility, so go ahead and do that. But make sure that there is no backwards compatibility. That will prevent customers from backing out the newer release, and coupled with a sensible bug fix policy (see above), will guarantee that once on a newer release, they will stay there. Extra bonus points Figure out how to get the old version to not even recognise files created by the newer versions. That way, they not only can't read them, they will deny that they are even created by the same application! Hint PC word processors provide a useful example of this sophisticated behaviour.
  22. Compensate For Bugs

    Don't worry about finding the root cause of bugs in the code. Simply put in compensating code in the higher-level routines. This is a great intellectual exercise, akin to 3D chess, and will keep future code maintainers entertained for hours as they try to figure out whether the problem is in the low-level routines that generate the data or in the high-level routines that change various cases all around. This technique is great for compilers, which are inherently multi-pass programs. You can completely avoid fixing problems in the early passes by simply making the later passes more complicated. With luck, you will never have to speak to the little snot who supposedly maintains the front-end of the compiler. Extra bonus points make sure the back-end breaks if the front-end ever generates the correct data.
  23. Use Spin Locks

    Avoid actual synchronization primitives in favor of a variety of spin locks -- repeatedly sleep then test a (non-volatile) global variable until it meets your criterion. Spin locks are much easier to use and more "general" and "flexible " than the system objects.
  24. Sprinkle sync code liberally

    Sprinkle some system synchronization primitives in places where they are not needed. I came across one critical section in a section of code where there was no possibility of a second thread. I challenged the original developer and he indicated that it helped document that the code was, well, "critical!"
  25. Graceful Degradation

    If your system includes an NT device driver, require the application to malloc I/O buffers and lock them in memory for the duration of any transactions, and free/unlock them after. This will result in an application that crashes NT if prematurely terminated with that buffer locked. But nobody at the client site likely will be able to change the device driver, so they won't have a choice.
  26. Custom Script Language

    Incorporate a scripting command language into your client/server apps that is byte compiled at runtime.
  27. Compiler Dependent Code

    If you discover a bug in your compiler or interpreter, be sure to make that behaviour essential for your code to work properly. After all you don't use another compiler, and neither should anyone else!
  28. A Real Life Example

    Here's a real life example written by a master. Let's look at all the different techniques he packed into this single C function.
      void* Realocate(void*buf, int os, int ns)
        temp = malloc(os);
        memcpy((void*)temp, (void*)buf, os);
        buf = malloc(ns);
        memset(buf, 0, ns);
        memcpy((void*)buf, (void*)temp, ns);
        return buf;
    • Reinvent simple functions which are part of the standard libraries.
    • The word Realocate is not spelled correctly. Never underestimate the power of creative spelling.
    • Make a temporary copy of input buffer for no real reason.
    • Cast things for no reason. memcpy() takes (void*), so cast our pointers even though they're already (void*). Bonus for the fact that you could pass anything anyway.
    • Never bothered to free temp. This will cause a slow memory leak, that may not show up until the program has been running for days.
    • Copy more than necessary from the buffer just in case. This will only cause a core dump on Unix, not Windows.
    • It should be obvious that os and ns stand for "old size" and "new size".
    • After allocating buf, memset it to 0. Don't use calloc() because somebody might rewrite the ANSI spec so that calloc() fills the buffer with something other than 0. (Never mind the fact that we're about to copy exactly the same amount of data into buf.)
  29. How To Fix Unused Variable Errors

    If your compiler issues "unused local variable" warnings, don't get rid of the variable. Instead, just find a clever way to use it. My favorite is...
    i = i;
  30. It's The Size That Counts

    It almost goes without saying that the larger a function is, the better it is. And the more jumps and GOTOs the better. That way, any change must be analysed through many scenarios. It snarls the maintenance programmer in the spaghettiness of it all. And if the function is truly gargantuan, it becomes the Godzilla of the maintenance programmers, stomping them mercilessly to the ground before they have an idea of what's happened.
  31. A Picture is a 1000 Words; A Function is 1000 Lines

    Make the body of every method as long as possible - hopefully you never write any methods or functions with fewer than a thousand lines of code, deeply nested, of course.
  32. One Missing File

    Make sure that one or more critical files is missing. This is best done with includes of includes. For example, in your main module, you have
      #include <stdcode.h>
    Stdcode.h is available. But in stdcode.h, there's a reference to
      #include "a:\\refcode.h"
    and refcode.h is no where to be found.
  33. Write Everywhere, Read Nowhere

    At least one variable should be set everywhere and used almost nowhere. Unfortunately, modern compilers usually stop you from doing the reverse, read everywhere, write nowhere, but you can still do it in C or C++.


The people who design languages are the people who write the compilers and system classes. Quite naturally they design to make their work easy and mathematically elegant. However, there are 10,000 maintenance programmers to every compiler writer. The grunt maintenance programmers have absolutely no say in the design of languages. Yet the total amount of code they write dwarfs the code in the compilers.

An example of the result of this sort of elitist thinking is the JDBC interface. It makes life easy for the JDBC implementor, but a nightmare for the maintenance programmer. It is far clumsier than the FORTRAN interface that came out with SQL three decades ago.

Maintenance programmers, if somebody ever consulted them, would demand ways to hide the housekeeping details so they could see the forest for the trees. They would demand all sorts of shortcuts so they would not have to type so much and so they could see more of the program at once on the screen. They would complain loudly about the myriad petty time-wasting tasks the compilers demand of them.

There are some efforts in this direction NetRexx, Bali, and visual editors (e.g. IBM's Visual Age is a start) that can collapse detail irrelevant to the current purpose.


The Shoemaker Has No Shoes

Imagine having an accountant as a client who insisted on maintaining his general ledgers using a word processor. You would do you best to persuade him that his data should be structured. He needs validation with cross field checks. You would persuade him he could do so much more with that data when stored in a database, including controlled simultaneous update.

Imagine taking on a software developer as a client. He insists on maintaining all his data (source code) with a text editor. He is not yet even exploiting the word processor's colour, type size or fonts.

Think of what might happen if we started storing source code as structured data. We could view the same source code in many alternate ways, e.g. as Java, as NextRex, as a decision table, as a flow chart, as a loop structure skeleton (with the detail stripped off), as Java with various levels of detail or comments removed, as Java with highlights on the variables and method invocations of current interest, or as Java with generated comments about argument names and/or types. We could display complex arithmetic expressions in 2D, the way TeX and mathematicians do. You could see code with additional or fewer parentheses, (depending on how comfortable you feel with the precedence rules). Parenthesis nests could use varying size and colour to help matching by eye. With changes as transparent overlay sets that you can optionally remove or apply, you could watch in real time as other programmers on your team, working in a different country, modified code in classes that you were working on too.

You could use the full colour abilities of the modern screen to give subliminal clues, e.g. by automatically assigning a portion of the spectrum to each package/class using a pastel shades as the backgrounds to any references to methods or variables of that class. You could bold face the definition of any identifier to make it stand out.

You could ask what methods/constructors will produce an object of type X? What methods will accept an object of type X as a parameter? What variables are accessible in this point in the code? By clicking on a method invocation or variable reference, you could see its definition, helping sort out which version of a given method will actually be invoked. You could ask to globally visit all references to a given method or variable, and tick them off once each was dealt with. You could do quite a bit of code writing by point and click.

Some of these ideas would not pan out. But the best way to find out which would be valuable in practice is to try them. Once we had the basic tool, we could experiment with hundreds of similar ideas to make life easier for the maintenance programmer.

I discuss this further in the SCID student project.

An early version of this article appeared in Java Developers' Journal (volume 2 issue 6). I also spoke on this topic in 1997 November at the Colorado Summit Conference. It has been gradually growing ever since.

This essay is a joke! I apologise if anyone took this literally. Canadians think it gauche to label jokes with a :-). People paid no attention when I harped about how to write __maintainable code. I found people were more receptive hearing all the goofy things people often do to muck it up. Checking for unmaintainable design patterns is a rapid way to defend against malicious or inadvertent sloppiness.

The original was published on Roedy Green's Mindproducts site.

Gente, les dejo una invitacion que me llego:


Tercera Conferencia Argentina Python
en la sede Junín de la UNNOBA


Del 22 al 24 de septiembre, la UNNOBA será sede de la Tercera Conferencia Argentina Python, un evento que se organiza en las principales ciudades del mundo y que en la Argentina se desarrolló anteriormente en Capital Federal (2009) y en Córdoba (2010).


Cinco figuras internacionales provenientes de Estados Unidos y Europa disertarán en las jornadas: Steve Holden (Chairman de la Python Software Foundation), Jim Fulton (Zope Corporation), Alan Runyan (Plone & Enfold Systems), Maciej Fijałkowski (core developer de PyPy) y Wesley Chun (Google). Además, estará presente también el programador argentino Ricardo Quesada, creador de una plataforma de desarrollo de juegos para iOS (iPhone) y Android llamada cocos2d, que es usada actualmente por más de 2.500 juegos en el mundo.


El Grupo de Usuarios de Python de Aregntina (PyAr) organiza este evento que reúne a informáticos de distintas latitudes y convoca a programadores, analistas de sistemas, ingenieros, profesores, especialistas, científicos y amantes del software libre.

La Escuela de Tecnología de la UNNOBA, la Fundación Vía Libre, Menttes, Simple Consultoría y Phyton Brasil colaboran con PyAr en la organización de este evento.


El 22 de septiembre será dedicado solo a tutoriales, mientras que el 23 y 24 serán dos jornadas dedicadas al desarrollo de paneles, talleres, charlas y actividades planificadas para distintos niveles: principiantes, intermedio y avanzado.

Entre los temas que se abordarán se destacan Programación web, Aplicaciones científicas, Frameworks, Aplicaciones en la nube, Aplicaciones de escritorio, Python en Android, Desarrollo orientado a pruebas, QA programación y Diseño de juegos.

Los organizadores esperan que a Junín arriben participantes de todo el país, Brasil y el resto de América.


La entrada al evento es libre y gratuita. Los interesados en participar deberán inscribirse obligatoriamente a través de la web:

Para los que no lo conocen es el creador de LOGO (el de la tortuguita!) y de varias teorías de aprendizaje usando tecnología:





La procrastinación (posposición reiterada de una tarea) es un enemigo de principal de toda persona que se propone ser productiva. Sin embargo, la procrastinación es como la lluvia, no puedes evitarla, así que lo único que puedes hacer es aprender a vivir con ella.

Dicho de otro modo, puesto que sabes que va a estar ahí quieras o no, la acción más inteligente es prepararte. Para esto el primer paso es identificar sus tipos porque aunque todos tienen el mismo efecto (posponer una tarea), no todos tienen el mismo origen (el por qué de haberla pospuesto) y por lo tanto no siempre es recomendable actuar del mismo modo.

Es aquí donde pretendo poner la lupa convencido de que si aprendes a identificar de qué tipo es la tarea que estás procrastinando, sólo te separará la acción que te propongo de completarla. Vayamos con la lista.


1. Procrastinación como base de la concentración

Características: Se produce cuando necesitas concentrarte en una tarea y para ello aplazas el resto.

El hecho de tener varias tareas compitiendo por tu atención es inefectivo, así que a menudo (¡y es lo correcto!) tendrás que posponer el resto de tareas hasta que hayas terminado la actual.

Hay muchos métodos de gestión y Jero en concreto ya te ha hablado de las bandejas de entrada por citar uno de ellos. Sin embargo, aunque esta procrastinación es necesaria, resulta un peligro porque existen demasiadas formas de usar mal el método.

La solución pasa por tener bien definidas tus áreas de responsabilidad y tener siempre un punto de referenciadonde concentres tu organización. Tienes que saber a dónde acudir para encontrar tu próxima tarea y asegurarte de que, si vacías tu cabeza para concentrarte, tu sistema te la restablecerá cuando acabes tu tarea.

2. Procrastinación por miedo a lo desconocido

Características: Cuando pospones constantemente de forma voluntaria una tarea porque no te apetece.

Si la anterior era necesaria, esta es imposible de erradicar. Mientras vivas, tu subconsciente te va a seguir jugando malas pasadas. No obstante, si lo dominas tu productividad dará un salto enorme.

¿Cuál es la parte fea de este reto tan motivador? Es una lucha constante. Deja de pensar que se trata de una tarea que puedas resolver un día y recostarte. Tus miedos nunca descansan.

La solución pasa por adentrarte en la tarea cuanto antes superando esa barrera mental inicial que tú mismo te impones. Intentar dar los primeros pasos buscando un poco de información o haz un sondeo entre tus conocidos sobre cómo lo resuelven ellos si es posible.

Yo aprendí a controlar este tipo de tareas copiando a Google con un “me siento afortunado”. La técnica consiste en hacer un simulacro de una tarea larga muy rápido escogiendo las primeras opciones que me aparecen para cada sub-tarea. Al final, obtengo una cadena completa que el 90% de las veces es muy mejorable en varios aspectos. Sin embargo la tarea se reduce ahora a mejorar mi versión inicial y aquí irás mucho más enfocado, con menos volumen de trabajo a abordar y con objetivos muy definidos.

Sobra decir que cuando hago una gran tarea a toda velocidad y esta tiene éxito, eso va directo a mi lista de victorias.

3. Procrastinación involuntaria

Características: Cuando una tarea no figura en tus listas pero debería.

Lamentablemente esto también es procrastinar. Si una tarea no llega a tu sistema de organización lo que llegará será un momento en el que tengas la sensación de que llevas años esforzándote por todo pero aún no has hecho tal cosa.

Antes de cargar sobre tus hombros el peso de tu pasado o de flagelarte, para un segundo. Si llevas trabajando todo el tiempo y aportando un granito de arena a tu proyecto cada día como una hormiguita no te mereces castigarte.

La solución correcta es ser consciente de que no puedes estar en todo. Una vez admitida esta limitación humana puedes intentar paliarla lo mejor posible. Presta atención siempre a nuevas fuentes de tareas que no hayas considerado pero que puede que debieras afrontar (como salud por ejemplo) y levanta de vez en cuando la cabeza para ver qué te puedes estar dejando. A menudo hay tareas que olvidas no porque no las quieras hacer, sino porque en ningún momento has tenido claro por dónde empezar.

4. Procrastinación sistemática

Características: Cuando una tarea que figura en tu lista parece que nunca se va a hacer porque nunca es la más prioritaria y por lo tanto no recibe nunca tu atención.

Tengo una buena noticia para ti. Esto puede que no sea un problema sino una reacción natural a una tarea que nunca deberías hacer. Además, si es así apúntate un tanto porque con tu sistema de organización no sólo haces las tareas más importantes, sino que desechas coherentemente el trabajo que no debes hacer.

Míralo con frialdad y no te empeñes en hacer tareas que no te aportan casi nada. Algunas de ellas son producto de que aún no habías definido bien tus objetivos. No hagas nada porque sí, arguméntate tus tareas. Sé tu propio trabajador perezoso que no tiene ganas de hacer lo innecesario y cuestiona todo. Con mayor frecuencia de lo que crees, acertarás, sobre todo al principio.

Recogiéndolo todo

Tienen la misma consecuencia, pero orígenes diferentes. En resumen, deberás saber reaccionar a cada tipo con la medida correcta, espero que las ideas que te propongo te orienten.

Como ves, el hecho de caer en la cuenta de que te habías olvidado algo nunca desaparecerá y lo práctico es aprender a vivir con ello. Practica periódicamente revisiones para los tipos 3 y 4 respondiendo (por ejemplo cada fin de mes/semana) a las preguntas ¿Qué estoy dando por sentado? y ¿qué tareas se llevan arrastrando un par de semanas por mis listas?

Para los tipos 1 y 2 la aproximación es más directa y lo único que debes mantener siempre es el control y el contacto con la realidad.

  • En los últimos seis años la industria del software aumentó su producción un 278 por ciento; sus exportaciones, un 256 por ciento, y el nivel de empleo, un 240 por ciento.


  • Así se convirtió en el sector productivo de mayor crecimiento entre 2004 y 2010.


  • La industria está compuesta por más de 1500 pymes y una veintena de corporaciones internacionales.


  • Tiene niveles salariales superiores en un 35,5 por ciento a la media del sector privado registrado.


  • La tasa de desempleo es nula y existe más demanda que oferta de empleados.


  • El rubro más dinámico es el de videojuegos: desde 2004 aumentó un 900 por ciento sus ventas externas, el empleo creció un 256 y la facturación, un 642 por ciento. Existen 165 empresas dedicadas a esa actividad que emplean a más de 12 mil personas, con un promedio de 27 años de edad.





SBS predice el futuro!!

Posted by federico Mar 31, 2011