See through concrete

LiTraCon is a company that produces light transmitting concrete.



Cool.

Via Make.

"Will it work?" vs "Did it work?"

One of the main issues that concern people about Agile is the conflict between "Will it work?" vs "Did it work?"

One of those questions will be cheaper than the other. But it depends on the situation which one it is.

In any case, "Did it work?" must always be asked.

And in any case, even if this seems to be the main concern, it's definitely not the main point.

Wealth creation over poverty reduction

Andrew Mwenda talks about framing the problem correctly in Africa and how foreign aid is poisoning the incentive and participation structure of African governments.

But with the blast shield down I can't see a thing!

"In a word, what we are proposing here is to build artificial, wearable, light-based hairs (or antennae). The actual hair stem will be an invisible, steerable laser beam. In the near future, we may be able to create on-chip, skin-implantable whiskers using MOEMS technology. Results in a similar direction have been already achieved in the framework of the smart laser scanner project in our lab. Our first prototype (headband configuration) provides the wearer with 360 degrees of spatial awareness and had very positive reviews in our proof-of-principle experiments."

The Haptic Radar/Extended Skin project at Ishikawa Komoru Laboratory.  The proof of principle video is pretty cool but I'd like to see one where they dodge Nerf projectiles or something.

Via MAKE.

The history of TPS

Just stumbled upon Art Smalley's Art of Lean web site which is a fantastic resource including interviews with people who had directly participated and witnessed the early development of the Toyota Production System.  I especially found the corrections about Shigeo Shingo's actual influence to be quite interesting.  Isao Kato seems more diplomatic while Katsuya Jibiki seems quite annoyed.

The problem with the word "customer" in defining quality

I still like the Feigenbaum definition of quality:

“Quality is a customer determination, not an engineer’s determination, not a marketing determination, or a general management determination. It is based upon the customer’s actual experience with the product or service, measured against his/her requirements - stated or unstated, conscious or merely sensed - and always represents a moving target.”

However, the word "customer" is problematic.  Customer implies the person who is buying the product or service but is not necessarily equivalent to the person who is using (and nominally receiving direct value from) the product or service.

So I'm thinking Quality is only truly assessed at the end of the value stream.  Everything we do beforehand, including ensuring Customers buy the right thing for their Users, is attempting to improve the likelihood that the assessment is favourable.

The riskiest place in your code could still be where you have the highest "test coverage"

Let's say I have a software system with several components.  Based on a code coverage tool, component A has 0% coverage, component B has 50% coverage, component C has 100% coverage.

Which component is the most likely to have problems?  Where's the riskiest place to make a change?

Can we responsibly answer those questions without understanding clearly what the tests actually are?  Can we responsibly answer those questions without understanding clearly what the components are doing?

Even with a disciplined test-driven approach, the component that received the most attention can nonetheless remain the most risky if it happens to be the most complex part of the overall system.

Democracy is not about election

Democracy is not about election; democracy is about participation.

You must feel that change for the better is a biological need

Jon Miller translates an interesting story about Kikuo Suzumura, a disciple of Taiichi Ohno:

The famously hard-hitting Suzumura scolded Kondo him because it was evident that kaizen activity had not progressed at all in the area. In response to Kondo's excuse that "We are busy," Suzumura retorted "You must feel that kaizen is a biological need, just like eating and sleeping. Otherwise you won't be creative and you can't do kaizen. Do it now!" And further, he said "If you have the will to do kaizen, the time to do kaizen emerges by itself."

Don't look with your eyes; don't think with your head

Jon Miller at Gemba Panta Rei translated a recent Japanese article to bring us some new Taiichi Ohno quotes:

"Don't look with your eyes, look with your feet. Don't think with you head, think with your hands."

"People who can't understand numbers are useless. The gemba where numbers are not visible is also bad. However, people who only look at the numbers are the worst of all."

Data-driven requires data-independent

You can't have data-driven tests without data-independent tests.

Why do we only talk about measuring productivity?

Manufacturing organisations typically measure 5 (or 6) major things:

• Quality
• Cost
• Delivery OR Productivity
• Safety
• Morale
• Environment (more recently)

Safety and Environment is generally not relevant for the software development organisation.  We sometimes talk about measuring Quality and Cost but the discussions are invariably focused on Productivity.  And, it is rare indeed to be in a discussion about measuring Morale.

So perhaps the problem is not whether or not we can figure out how to usefully measure productivity in software development but rather that we tend to believe that productivity is the only thing worth looking at.

LAMDA vs PDCA

I recently read Ready, Set, Dominate which is about Lean Product Development, or as they prefer to call it Learning First Product Development.  There is a concept called LAMDA (Look, Ask, Model, Discuss, Act) which is supposed to be a variation of PDCA.

It seems to me that it was an unfortunate use of the word Act in LAMDA which doesn't really map to the Act in PDCA.  "Act" in LAMDA refers to implementation while "Act" in PDCA refers to changing the standard or adjusting the plan based on learning.  As I see it...

Look, Ask, Model, Discuss -> Plan
Act -> Do, Check, Act