Taran Rampersad's blog

Measuring Quality

On metricsAside from demonstrating just how much of a geek I am when I wrote 'Know How You Measure', I opened the door for a few people that know me fairly well to ask me why I spend 'so much time' measuring things like... mileage. In the context of a gearhead car geek, it's simple.

You can tell when things go wrong, as well as tell if what you do is an actual improvement. It's really that simple.

As Peter Drucker wrote, "You can't improve what you can't measure." You can think you improved something - like, for example, the air ram or, as they call it these days, 'cold air intake'. It's been proven (there's a video in that link) that it pretty much doesn't work (in a stationary vehicle on a dyno - 'know how you measure', right?). We all have theories on how things can improve, but in the end we have to take into account whether or not something is an actual improvement. How do you do that?

You establish a baseline. It's where everything starts. True gearheads do it. Engineers do it. Doctors do it (why do you think they do all those tests and x-rays?). Everyone who wants an improved result has to at first have a result to improve upon.

But it's not just improvement. It's also about catching failures. In the example I gave in 'Know How You Measure', the main reason I track mileage is not because of improvements but because mileage is a good indicator of whether something is wrong, particularly in a complex system. It's an integral part of maintenance as well as development.

In summary, it's about measuring quality, where quality is easily defined for a man-made system: Works as designed.

Know How You Measure

"Measure a thousand times, cut once"Last weekend, I put new tires on the car (no, not the RX7 which has since been sold, but the Subaru). And my mileage seemed to decrease. Yes, I'm the sort of person who keeps a running tab on the vehicle so I know when something is going wrong. Spreadsheets and everything.

A cursory explanation might be that the tires are heavier, but that's easily dismissed (or should be).

Clearly, something changed with the tires. But before we delve into that, it's important to understand how I calculate my mileage - every fillup - and what affects those things.

The way I calculate my mileage is by writing down my odometer reading at every fill up and dividing that by how much gas I use to fill up. I fill up at the same station every time so that variations on the fuel pump flow are minimized (in fact, really, I typically use the same pump at that station). The odometer reading - I have a mechanical odometer - comes directly from the transmission, and I've done nothing to the transmission. The spinning of the output shaft of the transmission, probably at the ratio of 1:1690, spins the odometer.

This means that for lower mileage, the output of the transmission would be spinning slower over the period between fill ups since it would show less fill ups. Think range of the vehicle on a tank of gas.

Odometer reading/gallons = mileage; => Odometer reading = mileage x gallons

So what could cause the engine to be burning more gas? Resistance is the first thought, so I checked the oil and transmission fluid. They're fine. The odometer seems to be in good shape, but that's part assumption. What changed? The tires. And what changed about the tires?

2 things changed about the tires. The tire tread is much better, which means effectively the diameter of the tires has increased. The tire inflation is proper (they weren't before because I spend time in sand and also because the tires were old and hard and I wanted more grip on the pavement). So if the tire diameter effectively increased slightly, that means that for every rotation of the transmission output shaft, the car goes a small amount further.

That, in turn, makes it look like the car is traveling less distance on the odometer which makes it look like the mileage has decreased. It hasn't. I crunched the numbers and the mileage, which itself is relative, simply shifted a small amount and showed a small but noticeable decrease in my calculated mileage.

And thus, you have to know how you measure things. I've seen it in electronics (uncalibrated instruments) and software engineering (no baseline). I've seen it in just about every setting imaginable - even in the medical field.

Knowing how you measure something is even more important than measuring it.

Gardening and Software Development Processes.

FlowerOn the way to lunch yesterday, a friend of mine was talking about how object oriented design works with the example of vehicles. It was a pretty good analogy. I've been considering processes a lot lately, and gardening works for that.

Of course, a lot of people won't understand the gardening aspect, but if they understand software development they may get some ideas on how gardening works. That's not a bad thing.

As it happens, after my father passed away I ended up doing some agriculture for a while - working on some land that he had passed down. Surrounding farmers advised me and I listened, but what I was really doing was applying software development principles to something else that has a life cycle, that needed to be managed and ultimately had value.

Let's start off with this simple principle: Everything has a life cycle, from seed (idea) to fruit, vegetable or flower.

In between there's an implementation, and that implementation - if planned well - can grow you rows of corn. The planning requires understanding the plant itself: How much light it will need, how much water, what soil nutrients are necessary and how much attention the land in between will need to keep out weeds and unwanted insects - where the analogy almost fails is with bugs, but some bugs are good (and those we call undocumented features in software development). 

So if we plan everything well, we have well spaced plants that have room to grow around them, and where they don't compete for light or nutrients. Planned better, they are as close together as possible but not close enough to rob each other of nutrients. Planned even better, like the Three Sisters, they nurture each other and help sustain one another. Just like a well planned and executed software project.

Without planning, you will likely end up with clumps of plants that aren't doing very well. They rob each other of the resources that they need; they may even grow so tangled that it's impossible to separate them - they occupy valuable space, but they do not actually produce anything. Just like a poorly planned or executed software project - something that seems endemic to startup companies as they rush to get income and develop code amazingly fast but without a plan for sustainability. If you've been in software development long enough, you've untangled things as companies mature, and you should grok that. In gardening, you might have to start from scratch - in software development, you typically cannot, and in this regard gardening can be much less frustrating. As a software engineer, you might want to consider gardening as a hobby. Very relaxing and rewarding.

Like software development, there are processes. There's irrigation, fertilization, pest elimination (maintenance - bug removal without tickets), maybe some pruning (bonsai) or maybe some removal of sick plants. There's quality assurance, where a discerning eye assures that all processes are resulting in what they should. There's configuration management, assuring that different plants are treated differently. Ultimately, there's a plan. There's the start of a life cycle, and there is the end - the planned obsolescence.

Both can have markets. Sure, if you're doing a personal garden your profit may be pride, but maybe you're doing this for money and expecting a fiscal return. The market, though, is where software deviates from agricultural produce.

Maybe I'll write about that sometime.