Nov 24
Permalink

SPIEGEL: You include a nice list by the French philosopher Roland Barthes in your new book, “The Vertigo of Lists.” He lists the things he loves and the things he doesn’t love. He loves salad, cinnamon, cheese and spices. He doesn’t love bikers, women in long pants, geraniums, strawberries and the harpsichord. What about you?

Eco: I would be a fool to answer that; it would mean pinning myself down. I was fascinated with Stendhal at 13 and with Thomas Mann at 15 and, at 16, I loved Chopin. Then I spent my life getting to know the rest. Right now, Chopin is at the very top once again. If you interact with things in your life, everything is constantly changing. And if nothing changes, you’re an idiot.

Nov 16
Permalink

annotate models plugin

Just discovered Annotate Models plugin for rails (thanks to post in railspikes). Looks fab.

Nov 11
Permalink
Nov 02
Permalink

Problem-driven development?

Another reflection after listening to Seddon on “Rethinking Lean Service”

Seddon argues that you need to let the actual problems (that disrupt your delivery of value) dictate what activities you perform, and what processes you set up. This implies that you need to be brave enough to allow problems to occur (and have a way of catching and solving them). It means (in software terms) that you must not pre-optimize (of course!) but also not pre-solve, problems you haven’t yet had (even if these occur in 90% of similar projects), and also not pre-create functionality you haven’t yet found a request for (again even if these occur in 99% of similar projects). This is related to the software principle of YAGNI (You ain’t gonna need it) and DTSTTCPW (Do the simplest thing that could possibly work).

This problem-oriented flow is similar to the principle that Seddon characterizes as “Demand-driven” development, for which he stipulates that it is critical to differentiate which kinds of demand represent value, and which actually flow from “defects” and represent waste. For me, in software design, this is an understanding of user/customer/client requirements - these are demands, and some of them follow from the need to generate extra user-value (a needed feature), but some of them actually indicate defects in the existing system. It’s critical as a software designer to be able to differentiate these two, or you may end up building a monstrosity where new features are introduced to correct old mistakes. (I could give common examples but instead will choose one that I find really instructive: the example of the No Kahuna team who chose to remove a feature to fix an apparent defect in their webapplication - This is the right and brave decision even if I personally relied on that feature, and my team didn’t see a defect - and as Nathaniel pointed out in his comment - a very rare event in software development)

(adapted from part of my post on The Connected Republic)

Nov 01
Permalink

Study your organisation as a system

Thanks to Mark for encouraging me to listen to this great podcast of John Seddon rethinking “Lean” and going back to its roots in the Toyota / Japanese miracle

Some notes:

  • Customer pull, worker pull. Let workers improve (and own!) the processes.
  • Let the problems you encounter determine the processes you set up.
  • The measures in use must relate to the customer (“For any flow, we measure the end to end timing as it is experienced by the customer”).
  • Let demand drive the system. Which kinds of demand represent value, which waste (that determines your response).
  • Study your organization as a system

Really fantastic and very valuable for working out what I have been learning over the last two or three years.

I remember trying this out before though. “Study your organization as a system.” But what if you discover a system that is not consonent with how the organization represents itself to its customers, or worse (and more likely) to itself.

Oct 30
Permalink
Oct 29
Permalink
Oct 28
Permalink

“Don’t shout at your drives, they don’t like it” see the full story at Unusual disk latency : Brendan Gregg. Thanks to Rupert Watson at root6 for the link.

Oct 21
Permalink
Oct 11
Permalink
 Christoph Niemann as linked to by the also excellent http://www.informationisbeautiful.net, as linked on the ever inspiring CAN… (do I have to go on listing nested sources?)

Christoph Niemann as linked to by the also excellent http://www.informationisbeautiful.net, as linked on the ever inspiring CAN… (do I have to go on listing nested sources?)