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

Simple y brillante. Detrás de este aforismo, hay una historia 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.

Estos son mis 5 programadores interesantes: Ryan Singer, Havoc Pennington, Bruce Momjian, Tarek Ziadé, Tom McWright. El orden es aleatorio.

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.

• Colectivización y jerarquización:

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!

A paper (PDF) on how Spotify organizes the work of tens of engineers and designers in an agile manner.

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.

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.

]]> http://nosolosoftware.com/huxley-vs-orwell/feed/ 1