lixo.org

I don’t remember exactly how I ended up there, but after following a discussion on a possible Refactoring browser implementation for Ruby over at Murphee’s, Lean Manufacturing grabbed my attention. Besides Just-in-Time production, there is another big aspect of it that I hadn’t paid much attention to before: Muda, or the reduction of waste.

Waste, in the Toyota Production System, can come from seven different sources: overproduction, waiting, transporting, inappropriate processing, unnecessary inventory or motion, and defects. They can all be mapped to the software development domain quite easily, and most have a direct link to agile methodology practices, even if in some cases you have to stretch your imagination a bit. Not to wonder, as most of software development processes were directly inspired by production line practices – not necessarily in the conveyor belt sense, but more as in “I have (resources, ideas) and would like to make (manufactured products, software) out of them. What is the most efficient, effective and sustainable way to do so?”

There are two things we can waste while developing software: time (and its little brother, money) and brainpower (and its big brother, talent). Interestingly, flushing one down the toilet also brings the other with it: a project stuck in endless meetings or in fixing production issues is wasting both its people’s time and brainpower, and I find it fascinating and saddening at the same time how often I see projects that are up to here in both problems: a production issue is found, meetings are held for days or weeks, but nothing gets actually done to fix the problem and avoid it happening again. During those meetings, there’s lots of talk about changing the architecture, platform, getting more programmers and tools, or my favourite, “just rewriting the whole damn thing.” And rewriting a significant part of your system, as anyone who watched Netscape die can tell, doesn’t work.

Still, why is this behaviour so common, and why aren’t we working on bringing refactoring support for purportedly extremely productive languages like Ruby like there is no tomorrow, as to avoid repeating the mistake of rebuilding things instead of beating them into shape?

This write-up by Clay Shirky at Many 2 Many on why he sees the never-ending debate about Wikipedia to be a matter of fundamental differences in thinking is just brilliant, and it probably has a much broader scope than just technology innovations. Here’s a couple of choice quotes:

When thinking about technological change, there are two kinds of people, or rather, people with two kinds of maps of the world — radial, and Cartesian. Radial maps are circular, and express position in relative coordinates — angle and distance — from the center. Cartesian maps are grids, and express position in absolute coordinates.

Anything that was bad at Point A and is still bad at Point B gets factored out of the radialist critique. Any change where most of the bad things are still bad but a few of the bad things are somewhat less bad seems like a good thing to us, and if it can happen in a way that requires less energy, or better harnesses individual motivation, that seems like a great thing.

I’ve started reading The Wisdom Of Crowds yesterday, a wonderful book about how decisions taken by groups assembled under the right conditions constantly outperform the ones taken by experts. There are numerous examples, tales and food for thought served warm and with some delicious toppings.

I’ll refrain from blurting out quotes, because there are just so many good quotes I can’t really decide on anything significantly interesting that could be taken out of context. Anyway, if you can’t take the time to read the whole thing, try Smarter than the CEO, an essay by the same author, James Surowiecki.

I reckon there’s a huge and barely explored field for great software to grow in based on the wisdom that crowds hold: most companies don’t really take into account the power of its combined intelligence, relying on higher-ups to decide on what’s important when creating a good environment for groups of employees to decide on these matters could yield more accurate decisions.

Software that helps assembling and aggregating information from those groups within a company barely exists today, and I’m trying to come up with something. Shouldn’t be too hard, actually: some companies have experimented with internal stock markets and had fabulous results, and maybe that’s a good way to go. I’d buy a lot of Dan North and Liz Keogh shares by now: there’s GeekNight next week and JBehave is surely going to be discussed.


PS: I promise the next picture will not have insects of any kind.