Building Better Software With Info-Ops: An Interview With Daniel B. Markham

My friend, Daniel Markham, just published a remarkable book called Info-Ops: Build the Right Thing. It’s the type of book which could easily be overlooked if you were to judge it by its cover.

I was so impressed by the book that I decided to ask Daniel a few questions, and he kindly agreed to be interviewed.

Who is Info-Ops for and what will I learn from reading it?

Daniel: Info-Ops is for people organizing product information. It teaches you to organize any kind of project information you have in the minimum amount of space necessary and so that each piece works together with the other pieces to provide more value than if you just kept it all separately stuffed in directories all over the place.

A “project” is any effort where folks creatively make something that didn’t exist before: an app, a deck, a game, and so on. Doing something by an instruction list wouldn’t be a project. If you’re not thinking up creative stuff to make stuff people want, this book isn’t for you.

Once you learn all of that, there is also a tool I introduce in the second part that allows you to gather and store all of your information using your favorite text editor. There’s even a SublimeText plugin to do syntax highlighting. You don’t have to use the tool, but you can do your work faster if you do.

If you decide to use the tool, there’s help for plugging the tool into the rest of your DevOps pipeline. This means that information can flow around your organization continuously, just like code should be flowing out to your production environment continuously (After having passed tests, of course. Insert long discussion here about CI/CD/DevOps.)

Since the ultimate goal is continuous information delivery using most all of the same ideas as DevOps, the title of the book is “Info-Ops”.

This book is also scoped down to one person or team building stuff people want after the Product Owner figures out what they need. The sequel, Info-Ops2, will be about huge groups of people and teaching Product Owners how to figure out what they want. The second book builds on all of the stuff in the first one.

Let’s say that my team has already adopted a SCRUM or Kanban approach for managing processes. Will the information management best practices you suggest in your book alter our existing workflow?

Daniel: Not necessarily! Info-Ops is orthogonal to whatever development/management process you have.

The best analogy I know is this: various practices, meetings, and rituals are like those old kits you could buy to build a radio or something.

A big box full of parts and pictures of how everything goes together. There’s nothing wrong with that. If you want to have 2-week sprints and use Trello or something that’s great. Or if you want Kanban and continuous flow. But the problem with those old kits was once something didn’t go as planned, you were stuck.

You really didn’t understand why you were doing things the way you were (aside from maybe some slogans), so when things didn’t work exactly right? You either hacked up something that barely worked or you hired somebody.

Info-Ops is like learning electronics. You understand the underlying principles behind whatever processes you have, so you can tweak them up any way you’d like. Looking at businesses as flows of information turns out to be a powerful explainer of why some things work and some things don’t — and what to do when they don’t. I’m surprised nobody has really done this before.

In the book, I take one of the processes, backlog refinement, and talk about it, but only as an example of why it works, what it has to do, and how to know if you’re doing it the best way possible or not.

I’ve thought about doing some more processes, but I really didn’t want to write a process book. That seemed too much like a way to get into a bunch of religious wars over which process is better than another, and those things never end.

Instead, I wanted a book that would still be valid 100 years from now. I have no idea if I’ve succeeded, but it’s been a fun ride so far. 🙂

Uncle Bob, a friend, at one point told me the book had the potential to be as important as his Clean Code. I have no idea whether the actual book will turn out that way or not, but I agreed with him enough to stick with it this long.

You start off the book with an entertaining summary of ancient philosophy. What does Socrates have to do with information flow that builds software products which delight customers?

Daniel: Ha! Bet you didn’t expect that, huh?

If you had told me ten years ago that I would write a book with philosophers in it I wouldn’t have believed you, but as it turns out, philosophers play an important role in how we gather and process information.

Philosophers for a long time have been wearing togas, drinking beer, and looking around asking “Why are we here?” and “How do we know stuff?”

Or maybe that was Animal House. I get them mixed up sometimes.

Philosophers ask a bunch of questions about a lot of stuff, then if they’re lucky? They come up with a new science. Technology developers ask a lot of questions about a lot of stuff, and then if we’re lucky? We come up with a new app — or better yet, a new business.

It is the same thing, only philosophers have been doing it for thousands of years. So when we want to know about how to build out useful stuff in a domain we have no experience in, we can look to the history of philosophers and how they did it. Socrates, Plato, and Aristotle are really the Big Three when it comes to philosophy.

One person said all of modern philosophy is basically just footnotes to Plato, and there’s some truth in that. If we understand the general nature of what they did, we’ll also understand the general nature of what we have to do.

In a lot of ways, technology development is simply applied philosophy.

Asking the right questions and ensuring that the team has the same mental model is paramount for successful collaboration on creative projects. Your book provides the details of how to accomplish those two vital tasks, but could you give my readers a high-level overview of what’s involved?

Daniel: We work in complex and technical environments, so the trick is being able to keep it conversational and high-level as much as necessary — then be able to have a conversation at a very low level of detail. Then back to conversational again.

If you think about it, this is how all the “real” professionals you interact with do it. A good lawyer or doctor can sit and chat with you about seemingly trivial stuff. Meanwhile, they’re doing extremely technical work organizing your problem, evaluating outcomes, and so forth.

There’s no reason technology developer shouldn’t be as professional as other folks. In fact, if we want to be considered as professionals, and get the results professionals do, we have to learn to do this.

So there are three things we learn to help us do that. We learn how to map high-level conversation items to low-level, technical ones. We learn how to make a map of where important conversations have happened and where they might happen in the future, and we learn how to put together things we’ve already learned in new ways to ask questions and have conversations we wouldn’t have thought of before.

The trick is doing all of that without much paperwork. Sometimes you might get away with just a piece of paper or two. Throughout the book, I emphasize only taking the minimum amount of notes necessary. This isn’t a book about creating a lot of documentation. Just the opposite.

You advocate that we keep track of only the minimum amount of necessary information. How does EasyAM help us with this task?

Daniel: EasyAM was a quick pet project program I wrote in support of the book. I teach Gherkin and other languages. It occurred to me that if I was going to teach people how to take notes to keep track of important conversations, why not make a Gherkin-like language to do that?

It would be human-readable, people could use notepad or something to take notes, they could use version control, and there were dozens of various useful outputs you could have from the same simple set of notes.

One of the things I do is create a starter backlog in like 12 lines of notes. There are a few more cool things like that. So it was really a side project.

Interestingly, I’ve been working on the book for six years in various formats: Powerpoints, a science-fiction book involving a mechanical chicken factory, a book and videos, and finally Info-Ops. It was only when I added EasyAM to the mix that it all came together.

What made you choose F# for its implementation?

Daniel: I chose F# because that’s the language I currently enjoy playing with. I’ve been meaning to write a tokenizer/lexer for some time. This was my chance. Although I’ve covered the heck out of it with tests, there are still a bunch of bugs. I need to rewrite it using FParsec! Or maybe Haskell.

The book-writing sort of took over my life for a while and has prevented me getting back to EasyAM like I want to.

Is there a hard copy available?

Daniel: There is no hard-copy available yet. I’m using LeanPub and writing updates every couple of weeks or so throughout this year. At the end of the year, I hope to have it all solidified enough for a “real” book.

Anything else?

Daniel: If anybody’s interested, there’s also a three-day on-site workshop that covers the material in interactive form. Thanks for giving me the opportunity to chat about my work!

I want to thank Daniel for his time and hope that you’ll check out his book. I’m certain you’ll find it thought-provoking and valuable.