“Success is the ability to go from failure to failure without losing your enthusiasm”

Evidently Churchill said this. I’m not sure where or when. It’d be nice to think he said this during the darkest hours of WWII, but for all I know it might’ve been at some conference in the 50s (kind of like Eisenhower’s “Plans are worthless, but planning is everything”).

It’s an interesting quote. I think most people take this to mean “don’t give up” or “hang in there”. That was how I initially viewed this. However, I think there’s a better, more constructive way of looking at this, especially from the perspective of a startup.

Failure is active

“Going from failure to failure” is not just about enduring hardship passively. Failure is something active. It comes after actually trying to do something. It only happens after real effort. You can’t go from failure to failure by sitting around and waiting for something to happen. “Achieving failure” is real work.

Failure is also a public thing. Others can see it. In fact, others must see it because if no one sees it, you didn’t really fail—failure is a kind of social interaction. Sending e-mails to potential customers without getting responses doesn’t count as failure–maybe they were on vacation, maybe their e-mail filter stopped your message, maybe your message got lost in the hundreds of new messages they got that day. However, when you talk to someone in person and they tell you they don’t need your product, that’s the kind of failure you need to reach, the kind of failure that gives you the opportunity to go to the next failure enthusiastically. This type of failure teaches you something: your message was off, or your ROI assumptions were too strong, or the problems you’re solving aren’t important, etc. Whatever it is, you can use this to improve for next time.

When can you ever fail?

“True failure” happens when you’re too scared to try. It comes when we don’t want to look stupid or wrong. “True failure” stems from a fear of failing.

When do you ever really “succeed”?

When you go from failure and strive for the next failure, sometimes you fail to fail. I think that counts as success

Trust but Verify

I’ve never liked the phrase “Trust but Verify” (especially in organizations). To me trust means you firmly believe in someone’s integrity and their ability to do something. It means when they say something will be done, you, personally, know it will be done. No need to check. It’s money in the bank.

When you feel you have to verify someone’s work, you’re essentially saying “I’m not sure if you’re gonna do this right”. When you feel you have to look over someone’s shoulder to make sure the work is ok, you can’t really say that you trust them.

Some people may think what I mean by “trust” is “faith”. While close, these are not the same. Faith is like trust except you believe without proof. Trust is something that builds up over time. Trust develops when you’ve seen evidence of someone’s performance and abilities, repeatedly, in many different situations. Trust takes time— it’s a key part of a strong relationship.

When someone says “trust but verify”, I take it to mean they don’t really trust someone’s ability yet, but they’re in the process of observing how someone works and what they’re able to do so that they can get to a state where they can trust this person.

On the other hand…

A less charitable take on “trust but verify” is that someone is pretending to trust, and hoping that people will believe them, when in fact, they don’t really trust people at all. I believe there are people who are unable to trust others in the workplace. These are the micromanagers, or worse: highly political people with closely-held personal agendas. Because they are unable trust others, they can never develop mutual trust with their reports or their managers. While they may reach positions of power and be able to flex and distort organizations, their ultimate impact and potential will always be limited. They may be skilled and successful within an organization, but they will never be truly great contributors or leaders.

In any case…

Whenever you hear someone say “trust but verify”, watch out! Trust me

Multi-level Vision

I remember watching a TED talk a while back where the speaker described how to represent data from different scales at the same time. The example had a picture of a house superimposed onto a street map superimposed onto a city map superimposed onto a country map, etc. It was hard to see all of this information at once, but occasionally you’d get flashes of how everything fit together.

Software architects have to do this all the time

One of the most important architectural skills is seeing through all of the layers of a piece of software at the same time. I don’t think you can be an effective architect without this. An architect has to know how a change in one layer will affect all the layers in a system. Often, something that makes sense in one layer is a terrible idea in another.

What makes this even more challenging is that each of these layers may involve different technologies. Not only must an architect have the vision to see potential problems, but they must do so in a way that holds multiple paradigms and structures in place simultaneously while threading multiple paths through all the layers. Occasionally, while doing this, an architect will see everything fall into place and have a momentary, deep insight into the entire system. The challenge then becomes capturing something coherent enough to act on before the insight vanishes.

It requires lots of practice and experience to develop this kind of multi-level vision. I don’t think you can learn how to do this casually—it’s something that you have to work at for a long time. How long? I think the current rule of thumb is for about 10,000 hours.

Pulling Threads

Son #2 was wearing a shirt that was embroidered with “Istanbul!” (my parents bought the shirt for him on one of their vacations). The thread making up the “I” in Istanbul came undone and he was pulling on it, causing the “I” to disappear. We told him to stop because he would start erasing the whole word.

It’s the same in software

One of the software teams I used to manage talked about the danger of “pulling threads”. In any piece of software that’s been around long enough, there are bound to be parts that are just a little bit off. There might be an extra parameter that you shouldn’t need, or there might be some extraneous code somewhere. You might think to yourself, “Well, why don’t I just fix this right now since I’m looking at it?” That’s a good attitude, but sometimes pulling on these “loose threads” will cause the entire module to unravel. Often, you may find that the thread runs through several modules and fixing this will involve touching a bunch of files.

The danger in pulling on threads in your spare time is that you won’t have enough spare time to finish. Inevitably, you’ll have a half-done pile of work that isn’t fit to check in and that doesn’t provide any visible value.

If you want to pull on threads, tie them to features

The best way to pull on threads is to associate them with features. If you can let features drive things, you’ll pull on the threads that matter. You’ll end up with cleaner code that does something new. It’s really hard to justify work that only (potentially) reduces maintenance.

Pre-emptive thread pulling

Sometimes you can prevent future thread pulling with a little thought today. One of the features that people have asked for in my company’s product is the ability to log notes against effort entries. On the surface, this is easy to implement. You just add a notes field to an applied effort entry and there you go. However, I’ve been hesitant to do this because I know this would create a thread that would have to be pulled at some point.

How do I know this? It’s because I know the data architecture of Frontier, and I know this isn’t the right way to solve this problem here. The right way involves architectural changes. It’s a little more involved, but the result will be something much cleaner and much more powerful. So that’s what I’ve spent the past week doing–pulling this thread before it exists.

Don’t do too much pre-emptive thread pulling

Too much pre-emptive thread pulling, though, leads to overdesigned software. You’ll never get it done. You’ll spend too much time analyzing cases and sub-cases, and inevitably, one of the cases you hadn’t considered will be the one that turns out to be important…and many of the cases you did consider will turn out to be threads that will need to be pulled some day

Driving in San Jose vs Portland

Sorry I haven’t been able to post lately. I was hoping to get a backlog of posts ready, but my house sold in that period so I had to get everything packed up in Portland, then drive down to San Jose, unpack everything, and then get it put away.

Since I’ve been doing a lot of driving lately, I thought I might comment on the differences between driving in San Jose and Portland. In Portland, the freeways go over lots of hills, especially as you head in to downtown from the West Side. Because of this, you find yourself changing your speed a lot (if you drive stick, you change gears a lot, too). It makes driving a more conscious activity. In the Bay Area, the freeways are pretty flat. I found myself using cruise control for the first time in many years. Also, since the speed limit in the Bay Area tends to be 65 mph instead of the 50 mph in Portland, you don’t have to worry as much about speeding. Also, now that many of the freeways have been widened to at least 4 lanes (in the past 15 years that I’ve been away), traffic seems to flow pretty well.

What this all adds up to is a more reflective driving experience in the Bay Area. Once you have cruise control on, and you have your 2+ car lengths in front, and you have your 4 lanes of straight flat highway in front of you, there isn’t all that much to do but think (particularly if you turn off the radio).

Rino’s Freeway Thoughts

I find that I go through the same set of topics whenever I drive in the Bay Area. I often think about traffic as water flowing through a tube. I wonder if anyone’s tried to model this using the Navier-Stokes equations. I wonder if you can compute a Reynolds number for traffic and what turbulence means.

I’ll look at street signs and remember what I thought about them when I was growing up. I still don’t know if the Tennyson Rd exit was named after the poet or if the Jackson exit was named after the general. The exit for “A street downtown” still brings a chuckle.

After this, I start thinking about things I’m working on. I used to think about homework. Now, I think about how to build my company. Now that I’m starting to get settled in San Jose, I need to start putting some of those thoughts into action! I’ll keep you posted