Adolescentes envidiables

Giles Tremlett, antropólogo y corresponsal de The Guardian en España, en La Contra (de Ima Sanchís) de La Vanguardia de hoy (no encuentro el link?!):

(En Inglaterra,) los niños aprenden que no deben fiarse de los adultos, y cuando llegan a la adolescencia siguen sin fiarse. Aquí, sin embargo, todavía existe el respeto intergeneracional.

A los ingleses nos sorprende mucho que en las encuestas, a la pregunta de qué es lo más importante en su vida, los adolescentes españoles contesten que su familia.

Nosotros somos muy estrictos con los niños pequeños, queremos que se porten bien en todas las situaciones. Aquí están mimadísimos, pero luego se transforman en adolescentes más sanos que los nuestros.

Planning Poker

I'm reading Mike Cohn's Agile Estimating and Planning (amazon.com amazon.co.uk); so far, a great book. Jim Highsmith's foreword is well worth reading.

On the chapter of techniques for estimating, Cohn describes Planning Poker, something that feels so simple and effective that you almost have to run to join your team and give it a try. You can read the description at http://www.planningpoker.com/detail.html. The site hosts a tool to enable distributed teams to play Planning Poker. Disclaimer: I still haven't played poker nor checked the tool.

One the nice things of Planning Poker is that it is not tied at all to software development: projects from other domains that have to be sized by guestimates (like writing a complex report) fit nicely in this approach.

In good company

I recently stumbled upon the fact that Scott Ambler, who inspired my second post in this blog, is an IBMer.

I feel in very good company every time that I learn that people that I know/read/admire "outside" are also "inside". It has just happened with Scott, but has happened to me before with Tridge, Sam Ruby, Erich Gamma...

Mary Poppendieck: Competing On The Basis Of Speed

I watched Mary Poppendieck's talk at Google: Competing On The Basis Of Speed. It is a good talk, but it does not compare well to Mary and Tom's most excellent Lean Software Development: An Agile Toolkit (amazon.com amazon.co.uk safari).



I took some messy notes, way too powerpointish :-(. My advice: go for the book.

Intro

• Fast companies (e.g. Dell, Toyota, Google)
• competitive advantage
  
• lower costs
  
• large barrier to entry for competition
  
• Speed's enemy: complexity
• 3 faces of complexity [1]:
• waste: anything that depletes resources without adding customer value
  keep it simple
  
• inconsistency: anything uneven, unbalanced, irregular
  make it flawless
  
• overload: excessive burden
  let it flow
  

Keep it simple (video 5m45s)

• Common infrastructure:
• Architecture
• Conventions: naming, coding, security, logging, ui, configuration management...
• Tools
• Refactoring to keep simplifying
• Sustainable simplicity: change tolerance (video 7m52s)
• 60%-80% of code is written after the first release
• the development process has to anticipate change
• decide as late as possible, when you have more info
  
• make decissions reversible whenever possible
• make irreversible decissions at the last responsible moment
• set-based development: explore the whole solution space at once (Toyota worked on 10 motors at once for the Prius). Keep multiple options, and one has to work at the last responsible moment.
• paradox: these redundant solutions are not waste

Make it flawless (video 18m28s)

• 2 kinds of inspection
• to find defects -> waste
• to prevent defects -> essential
• Mistake-proof every step: detect defects the moment they ocurr
• don't track defects on a list: find them and fix them
• test first, automated test suites
• Role of testing (video 21m55s)
• manufacturing:
  
• a quality process brings quality into the products (unlike in software development traditional view)
  
• finding process in verifcation -> you have a defective process
• focus on preventing defects. Cannot be at the end of development, adding waste in the form of test-fix churn. It has to be integrated into the development process.
• 4 kinds of testing
• unit testing: developer intend. Automate them.
  
• acceptance/regression testing: business intend. Automate them.
• exploratory + usability testing. Manual by definition.
• property (response, security, scaling....) testing. Take advanteg of tools.
• Technical debt (video 26m55s)
• anything that makes code difficult to change
• the longer you acquire debt the worse it gets
• cost ofcomplexty is exponential
• regression deficit: more features, longer testing, until it dominates the release cycle
• unsync code branches: the longer apart, the longer it will take to merge
• Build Quality in (video 33m17s)
• configuration management, one click build, automated testing, continuous integration, frequent depoyment
• nested synchronization: test as early and often as possible
  
• every check in - unit tests
• evrery day - regression test harness
• every week - operations test harness
• every iteration - deployment ready code

Let it flow (video 43m40s)

• cycle time : customer problem to customer solution.
• software development cycle time: requests to deployment
• process capability: wether you have or not a reliable and repetible cycle time for a given set of problems
  
• delays: hint of opportunities for cost/waste reduction
• queuing theory
• total cycle time = number of things in process / average completion rate
• shorter cycle time: ability to add new features
• small tasks and slack decrease the total cycle time
  
• utilization paradox (48m23s) - not having slack increases the cycle time. This is one of the ideas behind 3M's 15% of free time rule (Google's 20% precedent). Organizations targeting 100% utilization are meassuring the wrong thing.
  
• Keep a honest queue/to-do list: short and in the realm of the things that can be reasonably expected to be done; no useful purpose for long queues
• Stablish a regular cadence, limit work to capacity, minimize the size of things in the process.
  

System meassurements

• cycle time (lean classic) - process capability
• business case (are you making money) - business return
• customer satisfaction — sustainability
• net promoter score [2]

[1] From Matthew May's The Elegant Solution: Toyota's Formula for Mastering Innovation (amazon.com amazon.co.uk)
[2] Frederick F. Reichheld's The Ultimate Question (amazon.com amazon.co.uk)

Robots, noies i treball en equip

El treball amb robots a les escoles

• afavoreix les habilitats de treball en equip i resolució de problemes
  
• augmenta l'interés de les noies per la ciència i la tecnologia

Això és el que diu en Illah R. Nourbakhsh, de Carnegie Mellon, en el video weRobot: Robotics and Community for Learning and Exploration en el que presenta el projecte TeRK (Telepresence Robotics Kit). El video és en anglès, i acaba sent molt tècnic, però val la pena veure'n la part inicial en la que explica les motivacions del projecte, les expectatives dels alumnes sobre el que aprendran (programació i mecànica) i l'avaluació que fan del que han aprés (treball en equip i resolució de problemes), i les diferències en els interessos i els hàbits de treball de noies i nois.

Com estadística és una bírria, però, el dia què el meu fill va fer el taller de MindStorms al CosmoCaixa, la proporció entre nens i nenes era similar a la que hi havia a les classes de Telecos (molt poquetes). I, ja que l'esmento, el taller està molt bé i vaig tenir enveja dels menors de 14 anys.

El cervell del TeRK és el Qwerk, amb un processador RISC que fa servir Linux i té suport per webcam i wifi: des d'un navegador, pots veure el que e teu robot "veu" i controlar els seus moviments.

Fer-te un Qwerboot+ com el de la imatge (mono no ho és) et surt per $600 (460€) de materials i una bona feinada. Dels $600, $320 (245€) corresponen al Qwert.

De moment, els MindStorms són una opció més barata, més simple, amb més recursos disponibles i amb una comunitat més gran. Un totxo de MindStorms NXT costa 135€ i, un kit bàsic (NXT, 3 motors, sensors, bluetooth), 250€.

Hi ha gent que ha ensopegat amb aquest blog buscant on comprar-ne a Barcelona; imagino que si n'havés de comprar un provaria a roboteca.org (què tenen el mateix telèfon que invenio|learn by doing...), a lego.com o als que venen a Espanya solucions educatives de Lego. (Actualització: dues llistes de botigues a ladrillitos.com) a http://ro-botica.com/ o a http://stores.ebay.es/World-of-Leg-Godt. Info adicional a un post posterior.

I, per no gastar-se res, un EconoBOT, amb un pressupost de zero euros a base de treballar amb material reciclat.

Google Tech Taks (engEDU videos)

You *have to* keep an eye on Google's TechTalks. I have not seen an obvious link, so here it is a search and a feed on that search (better, since it provides longer descriptions). They are mostly about computer science, but the range of topics is quite broad.

It is great that they are choosing to publish all these terrific talks they host.

Update: from http://video.google.com/googleplex.html

Google TechTalks are designed to disseminate a wide spectrum of views on topics ranging from Current Affairs, Science, Engineering, Humanities, Business, Law, Entertainment, Medicine, and the Arts.

I also learned about the Authors@Google series:

Authors@Google is a speaker series where thought-provoking, Zeitgeist-making, trend-setting authors come to the Googleplex to read from their works and share their thoughts with us. The following authors have agreed to release their talks to the world on Google Video.

Irresponsabilidad corporativa

No escribo sobre plantar árboles, o no contaminar, o integrarse en las comunidades locales o... Mi tema es mucho más prosaico: no está bien que Google pida a los usuarios de Google Analytics que tecleen su identificador de usuario y contraseña en una página sin https. No basta con que las credenciales viajen seguras porque están utilizando un iframe con https para transmitirlas.

Nadie debería teclear su contraseña sin ver un candadito en su navegador.
Nadie, y, todavía menos Google, debería pedir a los usuarios que lo hagan.

Tallers de Lego MindStorms al CosmoCaixa

Els tallers de robots Lego Mindstorms de invenio|learn.by.doing, que vaig perdre'm el dia de la Robòtica, els fan aquestes vacances al CosmoCaixa. Més info al Blog de Mundobot; cal trucar per reservar; de 8 a 14 anys.

Man against Machine: Technorati ranks and spam

My (lousy) Technorati rank owes some points to splogs (spam blogs). It looks like some spam blogs are being created by posting whatever they get from subscribing to a google blog search. So far, I've been hit by two of them (sample, using tinyurl). According to an unscientific Technorati search, this particular spam amounted to about 10000 posts for December 8th. Yuk(*).

(*) Two posts in a row ending with "Yuk". Not good.

My story about you

From Bob Blakley's On The Absurdity of "Owning One's Identity":

There are lots of versions of your identity out there, but we'll lump them into two broad categories: your reputation (the story others tell about you), and your self-image (the story you tell about yourself).
(...)
Your reputation is my story about you. You can't own this by definition; as soon as you own it, it's no longer my story about you; it instantly becomes an autobiography instead of a reputation.
(...)
In principle, controlling the information that makes up your self-image seems easy - you just choose what you tell to whom, and under what conditions. (...) You value your privacy, of course, but you also value other things, like the ability to get a credit card and the ability to travel on airplanes. (...) You have a choice between getting a credit and controlling information about yourself - if you want the credit, you have to give up information somebody else chooses, and you have to do it on somebody else's terms.

I learned about Ceci n'est pas un Bob when he recently left ibm. Good reading if you are interested in identity, privacy, security and risk; and everyone should have at least a mild interest in them. Although I confess that I often skip Bob Blakley and Bruce Schneier when checking my feeds; as Calvin says (*), "Reality continues to ruin my life", and I often don't feel like having my life ruined by their uncomfortable reality reports.

(*) It is always a good thing to keep Calvin and Hobbes quotes at hand.

(Post written while trying to cope with the huge frustration of seeing someone spreading a false and damaging story about me. Yuk.)