Book Review: Software Ownership Transfer

Have you ever been surprised when a book crosses your way and you look at its title and think, “hmm, I was wondering about that. Didn’t know there was a book-length treatment of *that* topic”?

Software Ownership Transfer by Vinod Sankaranarayanan was that kind of book for me.

For a variety of reasons, this topic had been on my mind for some time. I purchased the book almost immediately. It didn’t hurt that the author, Vinod Narayan, is at ThoughtWorks, where Martin Fowler (Refactoring, Analysis Patterns, and several more) and Sam Newman (Microservices) also work. [Clarification: Sam Newman announced recently on Twitter that he is moving on, as the cliché goes, to other adventures.]

Within the first few chapters, it seemed useful — an earnest treatment of a very unglamorous topic.

The Problem

Ownership transfer is a philosophical problem and an emotional problem. Knowledge transfer is a managerial problem. And therein lies the nub.


  1. You acquire a company and are in the process of incorporating the acquired code into an existing codebase. Your codebase already has owners by module, who need to now take ownership of this new code, whereas the acquired company — a small startup, say — had essentially shared ownership of the entire codebase.
  2. Your star engineer leaves. Her large corpus of code, produced at a pace that most others couldn’t learn or digest, awaits new ownership. But if you think this scenario is challenging, think about the next one :-)
  3. Flip that around. The weakest link on your team leaves. Her code isn’t even very good code. That now awaits new ownership.
  4. You incorporate, with modifications, some open source code as part of your commercial offering. Now you find a bug in that code. Your customer doesn’t give two hoots that you’ve “contacted the original author about the problem and have submitted a ticket on github”. You sold it, you own it.
  5. You sell a source code license to a partner and need to ensure, for the sake of managing your support burden (if nothing else), that the buyer is self-sufficient.

In these, and in fact in many other cases, you have a software ownership transfer problem. These five problems aren’t even explicitly covered in the book, which uses insourcing and internal ownership transfer as its primary case studies. The approaches, however, are not fundamentally different across those or the use cases I myself listed.

In the Author’s Own Words

Ok, here you go. A few quotes, listed in the order in which they appear in the book:

The focus on transitions is often on efficiency and not effectiveness. There is a greater focus on activity over outcomes.
Ownership is a lot more than knowing.
The [new] owner has to rely on the incumbent [to tell her] how much effort she needs to put in.
[Only] releases […] will reveal the maturity of the teams.
Ownership Transfer involves transferring history, context, and thoughts, as well as commitments.
Test scripts are a great way to build functional knowledge [of a module the programmers aren’t familiar with]
Business needs must be met even when the transfer is in progress.
Typical knowledge workers prefer to work on projects where they can gain rather than give knowledge.

And, fittingly, this one to end the list:

Ownership Transfer must end as a non-event.

I loved that line. (In my professional life working on network infrastructure equipment at Citrix, we joke that our greatest success is when users stop noticing we’re even in their network.) My bent of mind leads to me to think successful engineering is all about anti-climaxes — “it worked just as we said it would, ho-hum, onto to the next thing now”.

The Good

This is a topic that is hard to get excited about, and the author does his darnedest to deal with that problem and make sure you keep reading. Miraculously, he succeeds! It isn’t so much his choice of metaphors or any artistic ability that makes the book work, but the simple style and the short sentences, chapters, and — frankly — book itself.

The author’s folksy tone keeps the matter light, his practitioner’s angle keeps the matter applicable, and his true believer’s consistency keeps the book on message. (Well, mostly on message, except for a small diversion or two into Agile philosophies and methodologies.)

The key intuition — and this is why I myself repeat it in this review — is that ownership of a piece of code is very, very different from knowledge of a piece of code. A close second is the intuition that knowledge itself has many dimensions: the ability to explain the code, the ability to extend the code, the ability to debug the code, and — critically — the ability to defend the code, to be its champion.

Finally, the author really tries to lay out and understand the complete landscape of this topic. Here, to drive home the point, is a mind map from near the end of the book, showing the range of topics covered:

What I Wished For

Anything I would do differently?

Sure! Because I’m as good an armchair author as anyone. If I can critique Stephen Curry’s shot selection or Virat Kohli’s decision making, I can critique anything.

I felt some sentences very core to the message of the book were buried deep in the text. I thought some paragraphs could have been better represented as lists for clarity and conciseness. But these are clearly minor points, especially given there isn’t exactly a bookshelf’s worth of material on this topic.

I would have really liked to see more of the author’s thoughts on the world of open source and the (what I believe) are the many lessons that world has to offer the enterprise in terms of ownership transfer. For example:

  1. Design discusssions and code reviews on mailing lists. I use the phrase “work in the open” in business settings. Articulate discussions in writing, keeping in mind future maintainers and extenders.
  2. Automated tests. Particularly, unit tests. I’m amazed at how few people are amazed by the quality of some open source software and how important unit tests are in that context.

Most significantly, though, I would have loved to see the author try to take steps towards formalizing this space. For example:

  • A taxonomy of ownership transfer scenarios and activities
  • A concrete definintion of a knowledge unit
  • A simplified cost model such as story points for software estimation

All these could facilitate the emergence of a shared vocabulary as the basis for higher-bandwidth conversations on the topic.

Final Verdict: Solid Treatment of a Useful Topic

All in all, I was happy to have read the book. It is an able effort at bringing a frame of reference and some beginnings of formalism to thinking about the act of giving or taking ownership of code — a situation that, in my opinion, occurs surprisingly often but isn’t recognized as such, maybe simply because we haven’t developed a common vocabulary for it.

I took to Twitter again to summarize in that pithy 140-char way:

I’m afraid that many in software engineering management won’t read this book. I mean, it doesn’t have anything to do with Big Data or Artificial Intelligence or Microservices, for God’s sake.

But I wish they would!

While this book may not rise to the level of contribution made by other books in other areas, there is no denying it the kudos of being the first serious treatment of this topic.

Those looking for prescriptions might be disappointed. Management newbies looking for hand-holding and simple checklists they can simply adopt might be disappointed. Experienced managers looking for additional tools and perspectives to help frame their own unique software ownership transfer problems will, on the other hand, appreciate this gentle coach on their bookshelf.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.