The Wisdom of Jim Gray: “It Doesn’t Exist Unless it is Written Down” (part 2)

My old boss, Jim Gray, drilled into me the rule that “it doesn’t exist unless it is written down.” As I described in part one of this post, I eventually came to internalize this value and apply it to our distributed team at Trōv.

Distributed teams have a special need for writing things down. During most of my tenure at Microsoft, I was the guy from California trying to work with a team at the Redmond mothership, and most of the time that team had a hallway culture. Q: How do you learn to use the team’s framework? A: Walk down the hallway and ask Joe. Q: How do you configure your service? A: Walk down the hallway and ask. Some of it was written down, but not enough. I recall flying up to Redmond to attend a training session. They handed out a list of instructions to create the “hello, world” of the platform we were learning. I got really stuck and raised my hand to get some help from the guru. It turns out there was a whole other set of unwritten instructions that everyone else in the room knew. They knew because they were on the team and had already learned it from the hallway. “How was I supposed to know that?” I asked the guru. He just looked at me like I was dunce and shook his head.

At Trōv, there is no hallway – at least not for engineers. I’m the only member of the entire engineering team in the office. Everyone else is remote, spread out from Melbourne to Madrid. So we need to write things down. Our GitHub wiki is loaded. We have Google Docs for material that needs to be shared with non-engineers. We have conversations saved and searchable in a number of places. We make sure that our APIs deploy with their documentation.

“Over-communicate,” is my challenge to our team. “Send too many emails, write too many wiki pages; we’ll let you know if it is getting to be too much.”

It never has.

Now, there is a possible dark side to writing things down. I’ve seen cultures where writing is the only output: endless slide decks, white papers, and emails – and no impact. Or places that insist on lengthy specifications, redundant comments in code, or detailed plans/projections beyond the foreseeable future. Three key concepts help keep us away from the dark side: (1) write to actually serve someone (2) let the tools do the work, and (3) write good, well-tested code.

When you write to serve someone, you aim to fill a need. For instance, we write down postmortems of our production issues to help the reader in the future, whether it be someone looking at a similar issue, or someone looking for the big picture and trying to improve our stability in general. We write down coding guidelines, design principles, and test strategy to help everyone deliver consistently and get new hires up to speed. Infrastructure setup, examples of library usage, and API documentation ensure that anyone can understand and use any part of the stack. Any time someone asks “how do I ….?” or “where do I find the information …?”, it is a signal that we may need to write something down to serve them.

Thankfully, we live in a wonderful time of tools that naturally document for us. Agile planning tools automatically document your work and your progress. Trello has our current high-level plan and captures our history. Pivotal tracks our stories and we use it to attach a conversation to a story. Our conversations in Slack are searchable and organized into channels. Github documents our commit history and code reviews, and also provides a nice forum for issue discussion and tracking. Using these tools in the right way satisfies “write it down” as a side-effect.

Finally, maintainable, well-tested code is also a communication medium. When you write an acceptance test or unit test, you have written the best spec of all: an always up-to-date one that clearly describes both behaviors and corner cases. When you adhere to guidelines to make code readable, including the right sort of commenting, the code itself becomes its own best description.

So write it down! Who knows, maybe it will help another future Turing award winner to be discovered.

Originally posted at the Trov Engineering Blog

Improved Performance by Having Your Life Uploaded

Sandy Pentland has a great paper in the Harvard Business Review called The New Science of Building Great Teams. There’s so much to glean from this paper; I’ll be reflecting for days on applying the ideas to my team. But one thing that jumped out at me was straight from the pages of Your Life, Uploaded:

Every day for a week, we provided team members a visualization of that day’s work, with some light interpretation of what we saw. (Keep in mind that we didn’t know the substance of their work, just how they were interacting.) We also told them that the ideal visualization would show members contributing equally and more overall contributions. By day seven, the maps showed, the team’s energy and engagement had improved vastly…

The notion that visual feedback helps people improve quickly shouldn’t be surprising to anyone who has ever had a golf swing analyzed on video or watched himself deliver a speech. Now we have the visual tools to likewise improve teamwork through objective analysis.

There’s not much question that quantitative feedback will increase in the workplace wherever it can be used to advantage. And we’ve seen it applied to sports like crazy, even at the amateur level. The question is: how much will people value and adopt this in other areas of life? I’ve gleaned a lot by looking back on old email exchanges. Seeing the exact words rather than the haze of memory makes one more tolerant of miscommunication. But I doubt people want every aspect of life under the microscope. Only time will tell how much territory the lifelogging revolution will take.

The Wisdom of Jim Gray: “It Doesn’t Exist Unless it is Written Down” (part 1)

In 1995, I was one of Jim Gray‘s first hires for his new research lab in San Francisco. Jim didn’t enjoy managing, so he never let the lab grow beyond about a dozen lab members. Consequently, I spent the following ten years enjoying regular small-group interaction with a “database legend” (as he was called on the cover of Database Magazine).

Jim won the Turing Award for “seminal contributions to database and transaction processing research and technical leadership in system implementation” and tech luminaries lined up at his packed-out memorial service to give him credit for his impact on the modern world of transaction processing: “every time you use an ATM machine you can thank Jim Gray.”

But Jim was very self-deprecating about his fame. “I just wrote it down,” he told me.

Ted Codd, of course, was the one who came up with relational algebra, and Jim minimized his own role as merely writing a tech report about building one of the first relational database systems (System R). This report ended up being read and cited by nearly everyone in the industry and Jim ended up famous – almost by chance, it seems, in his account. (Never mind that his genius gave us ideas like ACID, the five-minute-rule, and the data cube)

So the lesson he drilled into me was: “It doesn’t exist unless it’s written down.”

I would tell him my project was finished, and he’d reply: “No, it isn’t. Where’s the report? Where’s the memo? Where’s the web page?” He wanted something that others could find, that he could point to as the completed output. If it wasn’t written down, it wasn’t done. It didn’t exist for anyone to refer to, so it just didn’t exist. He also used to insist on a written monthly report, listing what I had accomplished the previous month and what I planned to do in the coming month.

Over time, I came to appreciate the wisdom of what Jim said. I internalized it to the point that I continued writing monthly reports even for managers who didn’t ask for them, and I always made sure that what I did ended up written down.

Now this is a value for my team at Trōv. In the life of a distributed organization it has more meaning than ever. We aren’t in the same time zone, never mind in the same hallway, so it is more important than ever that things are written down. “Where’s the wiki? Where’s the shared doc?” – “It doesn’t exist unless it is written down”

In part two of this post, I’ll speak more about this rule at Trōv, and also describe its potential dark side.

Originally posted at the Trov Engineering Blog

Ashok Chandra 1948-2014

I first met Ashok Chandra in the summer of 2007. He approached me with a novel idea: “let’s turn research on its head,” he said. “Instead of doing research first, publishing a paper, and then going in search of a product, lets look at what could make a big impact and then do research as needed.”

It sounded risky, but then I thought: when will I ever get a chance like this again? I just had to say yes.

That creative idea was the beginning of nearly five years of working for Ashok in a tiny team, where I enjoyed a day-to-day, familiar relationship with him.

And how I enjoyed it! Ashok was incredibly positive and affirming; more than anyone I had ever known. In our performance review meetings, he would look me in the eye and affirm my particular talents. He stretched me and pushed me, but with a spirit of joy and affirmation. Day in and day out, he was consistently positive. I realized that I was happier coming to work than I had ever been in my life.

Ashok was absolutely brilliant. He was also wise. He could put the technology in perspective, and he never underestimated the human aspect of the challenge we had set for ourselves.

When I left Microsoft, I asked him: “I’m going to be the CTO of a startup. You have the experience, Ashok. What advice would you give me?”

“Be flexible,” he replied instantly.

“OK, and…” I prompted, wondering if I should be taking notes.

“That’s it,” he said.

I thought he was kidding But he was serious. That was it.

Honestly, at the moment, I felt a little disappointed. Couldn’t he have said more? But as time went on I often thought of what Ashok had said. Whenever I found my plans disrupted, I would remember Ashok. Be flexible. Right. Deep breath. Keep going. He was so right! More than anything else he could have said about technology or management, these were the words I needed, time and again.

Ashok was wise, and kind, and thoughtful, and cheerful, and affirming. He will always be a role model for me as a leader, as a technologist, and as a friend. I loved him and I miss him.

The Wisdom of Gordon Bell: things “self identifying and tracked throughout their lives”

In 2012 I asked Gordon Bell if he thought Trōv was a good idea. “It’s inevitable” he told me, and then threw his weight behind it by joining the board of directors. No wonder: 6 years earlier he was leading a seminar in Australia called “The Enterprise of the Future:  When All Things Have a Digital Identity” that included the following in its description:

We imagine that all manufactured goods from automobiles… to sheetrock will be self identifying and tracked throughout their lives inside and outside their creating organization. People and organizations can have “perfect inventory” i.e. they know the whereabouts and state of all items and associated transactions at all times.

Gordon anticipated this trend as part of Bell’s Law of Computer Classes – a corollary to Moore’s Law that predicts the emergence of smaller, cheaper classes of computing over time. In the same seminar he explains the basis for his predictions:

Most information technologies are evolutionary, though they appear to be revolutionary because they have changed over a billion-fold since their inception.  Future capabilities can be accurately determined.

As the world catches up with Gordon’s vision, it is my job at Trōv to make incredible software that helps you benefit from every thing you own.

Tagged ,

iPhone 5s even better for life-logging

The recently-announced iPhone 5S includes an M7 coprocessor, which means that life-logging apps can now do their thing without being such battery hogs. The M7 “knows when you’re walking, running, or even driving” and it can track activity without requiring the power-hungry A7 chip that is used for regular applications.  Nike has announced Nike+ Move as the first app to take advantage of the M7.


Tagged , , ,

Robert Scoble says he would make his Trōv public


Trōv CEO Scott Walchek and I recently did an interview with Robert Scoble. It was lots of fun, but I enjoyed the post-interview discussion even more. We got into privacy or the lack thereof in the world, and Robert was leaning towards the “share everything, who cares?” point of view. I asked him “if we made a Trōv for you would you make it public?” – thinking that he would have to concede a desire for keeping what he owns private. But he answered with an emphatic “yes.”

As anyone who has heard me talk about life-logging knows, I am very private with my own lifebits (“I am a life-Logger not a life-Blogger”). So this attitude really blows my mind. But who knows? Maybe Robert is onto something. I think perhaps we should take him at his word and create his Trōv to find out.

Tagged ,