Toyota Production System: beyond large-scale production

What is Toyota doing now? All we are doing is looking at the timeline, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that time line by removing the non-value-added wastes.

– Taiichi Ohno

timeline_waste

Simple y brillante. Detrás de este aforismo, hay una historiatps muy interesante asociada a un cambio de escala profundo en el mercado de automóviles (tanto a nivel productivo como de consumo), que favoreció el crecimiento del TPS. Aunque sus primeros pasos son anteriores a la crisis del petróleo de los 70, es en ella donde todas las miradas se dirigen a la compañía japonesa: ¿por qué en un período de recesión tan fuerte, Toyota resiste tan bien? La respuesta es que Toyota llevaba años preparándose para las vacas flacas:

In the periods of high growth before the oil crisis, the usual business cycle consisted of two or three years of prosperity with, at most, six months of recession. At times, prosperity lasted longer than three years.

Slow growth, however, reverses this cycle. An annual economic growth rate of 6 to 10 percent lasts at most six months to one year, with the next two or three years realizing little or no growth or even negative growth.

Generally, Japanese industry has been accustomed to an era of “if you make it, you can sell it”, and the automobile industry is no exception. I am afraid that, because of this, many business managers aim for quantity.

En ese contexto, mientras la mayoría de los productores reducían sus costes produciendo más unidades (la famosa curva de Maxcy-Silberston), Toyota reducía sus costes por mejoras en el proceso productivo. Para cuando el mercado de consumo cambia y ya no “puedes vender todo lo que fabricas”, Toyota había construido un sistema de producción más resilente que el de sus competidores, con raíces profundas en el centro mismo de su filosofía:

[The Ford production system was focus on] making many models in small numbers cheaply. The main goal of the Toyota Production System was to produce many models in small quantities.

Y ésa fue su principal ventaja competitiva: la adaptabilidad al nuevo entorno. Ésa idea central es la que Ohno desgrana en el libro paso a paso. Es posible que no sea una lectura muy amable para aquellos que no conozcan -aunque sea superficialmente- la dinámica de una fábrica. No soy el más objetivo para decirlo porque a mí se me hizo ligero de leer, aunque no sabría decir si fue derivado de una cierta empatía y conocimientos previos de mi formación académica.

Aunque se podría hablar bastante, no entraré en la comparativa de la dinámica industrial VS software por dos razones:

  1. Porque gente con más experiencia en el mundo industrial y del software ya lo han hecho. Incluso el maravilloso concepto del time to market, lo han tratado en profundidad en su libro: From concept to cash.
  2. Porque, a pesar de asignarle un poder emotivo e importante a las historias y metáforas, creo que en nuestra industria, la del software, se ha abusado de este recurso de un modo perjudicial (primero con respecto al mundo de la ingeniería civil y luego del automóvil). El software es otra cosa.

Me he limitado a disfrutar de la lectura, sin tratar de buscar comparativas punto por punto con el software, porque eso podría haberle quitado toda la gracia y disfrute. Aunque inevitablemente ciertas metáforas emergían sin querer. Emociones similares a las que, me imagino, tuvo Beck en ese vuelo a Cerdeña para la XP 2002.

5 programadores interesantes

Bajan las persianas tarde y entra un sol mudo por las rendijas. Es domingo. RSS pendientes, que últimamente son muchos. También Carcassone. Acompañado todo por un chocolate del bueno, que fomenta esa sensación de relajación a la que uno se acostumbra rápidamente. Que favorece la lectura selectiva. Así que lo primero que hago es borrar los feeds que luego de un tiempo han perdido interés para mí y confiar en que algunos de los no leídos sean de los interesantes, de esos que regularmente aportan cosas. Y al hacerlo pienso que, listar a los buenos, no es sólo un buen homenaje sino también un conjuro, un modo de ahuyentar a lo pajarú que va asociado a nuestro gremio (ser la punta de lanza de una industria llamada a definir el siglo puede que sea la razón misma de nuestro bipolarismo). Ahí va.

Estos son mis 5 programadores interesantesRyan SingerHavoc PenningtonBruce MomjianTarek ZiadéTom McWrightEl orden es aleatorio.

Bóvedas de acero

Estas navidades he leído mi primer libro de Asimov: Bóvedas de acero, la novela que inicia la Saga de los robots. Ha sido una lectura del tirón, de esas que te enganchan rápidamente. Me ahorraré el resumen, sólo decir que Asimov ha conseguido tejer una historia muy interesante, incluso para alguien del futuro, como yo. Pensad que es una novela escrita en 1954, en plena guerra fría, previa a la revolución de las computadores. Y más de 50 años después sigue teniendo cosas que decir.

Además de novela entretenida por policíaca, contiene varias ideas-fuerza que vale la pena resaltar:

  • El choque humano/robot:

Quizás por todo lo que rodea a las leyes de la robótica y Asimov, empecé la lectura con reservas, con pocas esperanzas de que me contaran nada nuevo. Y, sin embargo, me he encontrado un discurso muy elaborado, a la altura del mejor Ghost In The Shell: la introducción de robots en la Tierra como sustitutos de personas, está creando una gran masa social sin trabajo y, por supuesto, resentida, lo que crea un movimiento reaccionario. Éste es el núcleo de todo el desarrollo. Este conflicto no me pareció una situación muy lejana de la que se dió/está dando en el proceso de desindustrialización de nuestras sociedades hacia una informacional/de servicios: enormes bolsas de población que no consiguen reconvertirse (luego de años dedicados, por ejemplo, a los astilleros, la fabricación de coches o construcción) y ven cómo su nivel de vida se reduce, en algunos casos, hasta la mera subsistencia. O, en mucha menor medida y más directamente, por ejemplo, la sustitución de cajeros por máquinas de paga tú mismo en los supermercados.

  • Superpoblación y límites de crecimiento:

Las ciudades en la Tierra son grandes bóvedas de acero superpobladas y fuertemente dependientes de los recursos naturales. En este sentido, Asimov se adelanta un lustro al neo-malthusianismo del siglo XX planteando el problema en apenas unas líneas de diálogo entre el detective Elijah Baley y el Doctor Fastolfe:

En los tiempos primitivos, los centros individuales de población eran prácticamente autosostenibles, alimentándose del producto de las granjas adyacentes. Nada salvó un desastre inmediato, una inundación o una peste o una mala cosecha, podía dañarlos. Al crecer estos centros y mejorar la tecnología, los desastres localizados podian superarse acudiendo a la ayuda de centros distantes, pero al coste de hacer que áreas aún mayores fueran interdependientes. En tiempos medievales, las ciudades abiertas, incluso las mayores, podían subsistir con los depósitos de alimentos y con provisiones de emergencia de todo tipo durante al menos una semana. Cuando Nueva York se convirtió en Ciudad, podría haberse mantenido a sí misma durante un dia. Ahora no puede hacerlo ni durante una hora. Un desastre que podría ser incomodo hace diez mil años, meramente seguro hace mil, y grave hace cien, hoy sería mortal de necesidad.
Sin embargo, a diferencia de los neo-malthusianos, Asimov plantea una salida positiva, progresista: tecnología y nuevos enclaves de población más allá de lo conocido. Con ello, también aquí se adelanta (15 años!!) a lo que el antropólogo Marvin Harris llamaría luego materialismo cultural.
  • Colectivización y jerarquización:
Aunque no le di mucha importancia a lo largo de la novela, ahora me doy cuenta que la dicotomía Tierra/Mundos exteriores es también la dicotomía sociedades de escasez VS sociedades de abundancia. Y aunque, en esta novela, Asimov se queda en la crítica de la Tierra, también nos da unas pinceladas de la sociedad de la abundancia que plantea en los Mundos Exteriores: una sociedad redistributiva en términos de Harris. Por otro lado, la pintura de la Tierra como espacio de escasez que dibuja Asimov me parece brillante y descorazonadora (por realista): creación de núcleos de población hipereficientes en cuanto a consumo de recursos naturales (por concentrados); centralización de la sociedad (planificación, jerarquización y colectivización de las actividades económicas y culturales) con la pérdida de individualidad e iniciativa que eso conlleva: capa funcionarial dedicada a escalar en la jerarquía sin preocuparse por los problemas de la sociedad, ciudadanos pasivos, etc. Es tan brillante que, lo lees, y apenas te das cuenta de la enorme crítica que contiene. Quizás éste sea el aspecto donde más se puede observar la influencia de la época en que la novela fue escrita: 1954, en plena escalada de la guerra fría entre la propuesta capitalista de Estados Unidos y la comunista de los Estados Rusos.

En definitiva, una muy buena novela, que se deja leer fácilmente como novela policíaca y que plantea con sencillez temas complejos que nos afectan. Buena ciencia ficción para empezar el año!

(Geo) Database evolution while developing

During last year, I followed with interest the different approaches on how to evolve the design of a database being discussed within the postgresql community. Following is my take on that one: how this year I developed a project with an intense evolving DB design using an agile approach.

The context

My requisites for this project were twofold:

  • An evolving DB design: at the beginning of the project I didn’t know how the DB design was to going to be. I had set to use some advanced techniques for data modeling which never had used in production (dynamic segmentation and linear referencing with PostgreSQL/PostGIS) and needed an approach which supported my evolving understanding of the domain.
  • Intense collaboration with analists: the project needed some intense work on data-processing to polish and create the data for the application. I knew this was to be an iterative process where both developers and analists would collaborate together to define and clarify the model we needed.

My approach

So, in the process of improving and automating my delivery pipeline, I set some rules for the project:

  • DB management through SQL and control versioning: the database was created from DDL scripts and data was stored as CSV (if alphanumeric) or SQL (generated from Shapefiles to store geographical information).
  • Application and database evolve together: so their code should too, which in practice means I put the app and DB directories/projects under the same git repo.
  • Test driven development: I needed to break the problem in small chunks I could deal with, while my understanding of the domain improved. Besides, when refactoring the DB (schemas, triggers, functions, etc) -which happened frequently- I needed to know all the pieces were working OK. I decided to use pgTap for that.

And how it turned out?

  • The pipeline worked smoothly: both the analists and developers were working in their confort zone with the proper tools; desktop GIS applications the formers, command-line and SQL the laters.
  • git provides an excelent mechanism for versioning text, so I had powerful tools at hand for versioning SQL structure and data (diff, cherry-pick, interative rebases, etc). Besides, see where the data was varying (name and type of fields, its values, etc) allowed us to early discovered some bugs and problems.
  • Database and application evolving to the same pace. By tagging the versions we can build in seconds the binaries needed for any version of the application with the proper DB.
  • Tests at DB level are a life-saver. pgTap allowed me to refactor the database whith no risk and a lot of confidence on what I was doing. I had all kind of tests: check if a trigger is launch if an UPDATE happens, a function is working, data integrity and model validation after the initial restore, etc.
  • Same process for deplying to developing, staging and production environments, which resulted in fewer errors and no panic-moments.
  • Having the data in the repo and regenerating BD from scracth was very comfy and quick (less than a minute in my laptop the whole DB: 100Mb of raw SQL) and similar numbers when deploying to stage through the wire. In a daily bases I only had to regenerate specific schemas of the DB, so waitings was an order of seconds.

Coda

We should consider the database as other deliverable to our clients and set the same quality, standards and methodology to develop it. In that sense, agile philosophy and practices match very well with the DB evolution.

At the tools level, I was reluctant to introduce new tools and steps I didn’t know very well in such a tight schedule, so I decided to stick to the basic and spartan (git repo, shell scripts, pgTap and SQL), then iterate and grow a solution for our specific case. Although I missed some refactoring tools, it turned out to be a good approach and now I´m in good position to know the tradeoffs of the process, which in next projects will help me to choose a specialized tool, if necessary.

Finding ADA

Hoxe celébrase o Finding Ada, un evento de homenaxe ás mulleres nas ciencias, enxeñerías, tecnoloxía ou matemáticas. Inspirado en Ada Lovelace, a primeira programadora da historia, o evento pretende visibilizar ás mulleres do mundo STEM. Unha divertida maneira de profundizar no mundo de Ada é este cómic online (pronto publicado en libro!), no que ten un rol detectivesco conxuntamente con Charles Babagge, e que xa recomendei pola súa rotunda actualidade: Lovelace and Babbage in Economic Model!

Redución de escala e poder

Últimamente, non se nos fai extraño ver procesos de reducción de escala -adelgazamento- tanto no ámbito público como no privado, ben sexa en forma de recortes de servizos ou redución de plantilla. E aínda que a crise actual empañe todo, temos que recoñecernos que xa o sabíamos: este proceso non é derivado da crise, aínda que ésta o acelere.

O que me chama a atención son as medidas que se toman dependendo da distribución do poder:

  • El País anuncia o peche das edicións galega, vasca, andaluza e valenciana, botando ó redor de 140 periodistas dos 440 que dispón o xornal. Chama a atención que o xornal dispoña de case 500 directivos (tantos como traballadores!) e que os recortes se centren nos que traballan.
  • O goberno central avanza nun recorte sen precedentes do estado do benestar a costa dos cidadáns, pero non dos seus dirixentes. Somos nós cos nosos impostos os que mantemos a estructura estatal, porén, son eles os que a dirixen: “hay una legislación que favorece claramente la participación en política de los funcionarios públicos. Si se mira este Gobierno y todos los anteriores se ve una presencia de funcionarios muy superior a lo que representan en la sociedad. Eso genera un sesgo: quienes dirigen el país no son una imagen representativa de lo que es el país.”

Mentres tanto, nas cooperativas Mondragón, cando pintan bastos o adelgazamento de unha das cooperativas nos se fai a costa dos traballadores senón con eles: redución de soldos global, mobilidade inter-cooperativa, etc. E si ben é necesaria a reducción de escala por cambios no contorno, faise inevitable pensar na brutal diferencia que hai en facela dun modo ou outro.

E vénseme á cabeza o famoso discurso Tommy Douglas, Mouseland:

«The cats passed good laws–that is, laws that were good for cats. But the laws that were good for cats weren’t very good for mice.»

«El signo de la vitalidad no es durar, sino renacer y adaptarse»

– José María Arizmendarrieta, fundador de la actual Corporación Cooperativa Mondragón. Recomendable El milagro Mondragón, documental sobre la región, nuestro valle de cooperativas.