The Case For Space

Sunrise over a planetI recently read “The Case For Space“, by Robert Zubrin. It was great. Now, I have a degree in physics, but it’s been a long time since I did any math more complicated than algebra. So I can’t speak to the nuances of his calculations–I didn’t verify them. (A google search for reviews where people work through the math doesn’t turn up anything either.)

But I thoroughly enjoyed this overview. This book is in two parts.

The first covers where we are in space exploration now, and where the physics can let us be. He spends a lot of time on what we could do right now. But he also write a number of chapters on where we can be if there are scientific advances in energy generation (namely fusion). The author starts with low earth orbit (LEO) and then heads to the moon, Mars, the asteroid belt, the gas giants and beyond.

This section is a lot of fun. Zubrin covers areas that I never considered to be related to space (the power of transorbital flight to make the earth even smaller than it is today for travelers). He also talks about the economics of space flight and colonization. What exactly will the moon settlers or Martians have that they can sell? There’s a reference to a three way trade between Earth, Mars and the asteroid belt. I really enjoyed the details he dove into. For example:

“In the almost Earth normal atmosphere of Titan, you would not need a pressure suit, just a dry suit to keep out the cold. On your back, you could carry a tank of liquid oxygen, which would need no refrigeration in Titan’s environment…and could supply your breathing needs for a weeklong trip…”

The second part is supposed to be more inspirational, as if getting to space wasn’t inspirational enough. He covers various reasons (freedom, security, survival) that we should be getting off Earth. I found this section less exciting, but I can understand why he included this–if you aren’t excited about space travel for the adventure, Zubrin might convince you in this section.

There were parts of this book that dragged on a bit, but for the most part the prose is accessible and the math skippable. The real world plans that he outlines, especially at the beginning of the book focused on reusable spacecraft technology, LEO, the moon and Mars, are fascinating for their audacity and specificity. Recommended.


Book Review: Goliath

I recently read Goliath, by Matt Stoller. It was, I’ll be honest, hard going. Not because it wasn’t interesting or because the writing was bad. Just because it’s a dry subject and there are a lot of people involved.

The book is about how we (the USA, there’s really no coverage of any other country) think about the economy. Who is in charge? Big business, or people opposed to big business, who Stoller calls anti monopolists, and who most often act through government institutions.

The author starts with Teddy Roosevelt and the early 1900s, covers Wilson’s presidency (I had no idea he was so progressive, nor what an impact Brandeis had), the 1920s and the power of the financier and secretary of Treasury Andrew Mellon. The Great Depression gets some interesting coverage and we learn about how Mellon was almost impeached (he resigned before the House took up the matter). The anti monopolists were ascendant in the 1930s, interestingly in part because of fear of fascism coming to the USA. During the 1940s and 1950s when there was a pretty firm understanding that large enterprises were not good for the country. This was based on an shared understanding of the causes of the Depression. Then the Chicago school begins and starts to chip away at the intellectual underpinnings of the anti monopolist move. This combines with a re-imagining of the American populace as consumers rather that small business owners and farmers.

This accelerates in the 1970s, and the fed starts to rescue failing enterprises like Penn Central. In the 1980s the author discusses Michael Milken and how he ran the junk bond markets through a combination of market making and outright fraud. He also talks about how the savings and loans crises and the uneven unwinding of regulation affect the economy. He also covers briefly the rise of Walmart. Stoller also discusses turning points where the free-market philosophy could have been reversed, but instead, due to a lack of understanding of the monopolistic roots of the Great Depression, it is not. This happens with both Bill Clinton and Barack Obama, both of whom came to power during economic downturns, and both of whom followed financiers’ advice. At the end he discusses how the intellectual foundation of anti monopolyism is being rebuilt, and invites everyone to join.

The book was much more interesting to me when it was covering earlier history. He threads a lot of it together by talking about Wright Patman, a Texas congressman who was a valiant defender of the anti monopoly practices and institutions that were created after the Depression (the FTC, the Justice Department’s Antitrust division).

This book, long and dry as it was at times, was important for two reasons. First, you have to know history before you can understand the current day. Second, there’s a lot of populist anger (justified in my mind) about the way that the Great Recession was handled, and I think that is shown in both Trump and some of the current Democratic candidates. I’m very interested in that anger being harnessed in as constructive a way as possible. I also think that it’s a valueable conversation to have about the tradeoff between economic efficiency and economic resilience. From what I’ve read of systems thinking, the way the US economy has been structured since the 1980s has been tilted towards efficiency, but is that the right answer? I don’t know, but I do know that I believe that the economy exists to serve society, not the other way around, and so if a democratic society wants to restructure the economy, that’s fine by me.


The Challenger Sale

I just finished reading The Challenger Sale, a book about consultative selling. I really appreciated its data driven approach. The book, written in 2011, outlines a new approach to selling that is fundamentally about bringing the seller’s business knowledge to bear to provide value to the seller. But not just value, value in a way that is both striking (something new the customer hasn’t thought of before) and that emphasizes the product the seller has to offer. An example they give is Grainger, who sells parts. Grainger did research and determined that a large amount of the dollar spend with them was for unplanned part purchases, which can be expensive in both purchase price and staff time. They worked with customers to take advantage of their sprawling inventory to better plan parts purchases.

They cover the different kinds of sales techniques that their research uncovered, as well as tactics to help people adopt “challenger” traits to become more successful. They also cover how to sell this methodology to front line sales managers.

Two things really stood out for me. The first is that every company needs to answer why their customers should purchase from them, as opposed to anyone else. This can be a hard conversation to have because once you strip away all the “innovation” and “customer centricity” sometimes you aren’t left with much. I know that when I was a contractor, I would have had a hard time with this–my best answer would probably have been “I’m trusted, available, knowledgable and local”, which kinda sounds like a copout.

The other great part of the book was at the very end when they talked about how these techniques could be used for the “selling” of internal services (IT, HR, market research, R&D). I found that really interesting in the context of larger corporations where some of the functions aren’t valued for strategic insight, but rather are order takers from the business. I have in fact myself been an order taker. It’s easy, but not as fun as being part of the strategic conversation.


Book Review: The Economists’ Hour

I recently finished The Economists’ Hour, a book about the rise of economics professionals in public policy. It focuses primarily on the USA during the 1960s-2010s, but it does cover some other countries (Taiwan and Chile primarily). It covers a variety of topics including monetary policy, deregulation, shock doctrine, and inflation. The book also focuses on personalities, from the more prominent like Milton Friedman to the more obscure (at least to me) like Alfred Kahn, and uses them to humanize the economic topics by framing the economics through the human beings who argued for and against them.

This book was a bit heavy going at times, but given the breadth of topics and time it covered, I found it pretty compelling. I lived through part of these times, but there were many things I learned, including the impetus behind US airline deregulation (the power of the airline industry relative to trucking and the success of intrastate carriers in CA and TX) and how Taiwan became an electronics powerhouse (a meeting over coffee and strong industrial policy). If you’re interested in the intersection of economics and government policy, this book is highly recommended. (Here’s a great podcast with the author as a bonus.)


Obstacles to building high availability software systems

Open sign

Is your system available?

I saw a discussion on a slack about obstacles to high availability systems and wanted to record the edited version for posterity (mostly for future me, as I blog for myself). Note that in any mention of high availability systems would be remiss if I didn’t mention the Google SRE book, which is slow reading but free and full of great information.

First, what is high availability? I like this definition from Digital Ocean:

In computing, the term availability is used to describe the period of time when a service is available, as well as the time required by a system to respond to a request made by a user. High availability is a quality of a system or component that assures a high level of operational performance for a given period of time.

Design considerations of a system that will hinder high availability fall into two categories.

The first category is actions that you don’t take, but could take:

  • single points of failure: if you have a piece of your system which is unique and it fails (and everything fails, all the time), the entire system’s availability will be affected.
  • missing or incomplete automation: if you need human beings to resurrect failed parts of your system, it will meaningful amounts of time and will be error prone.
  • failing to build in elasticity and scalability of resources: when usage increases, new resources should be automatically brought online. Failure to do so will impact system performance and that could impact system availability
  • missing or incomplete system instrumentation: if you don’t monitor your system, you won’t be able to even know its availability (until you hear from your users).
  • application statefulness (on the compute nodes): this impacts your ability to use elastic resources and to grow parts of your system that are under load. (If you aren’t designing a greenfield system, this may be an externally imposed requirement due to existing software.)

The second is in actions you can’t take because of external requirements on the system:

  • data sovereignty: if you are legally limited to certain data centers, you have fewer options for your system, this can hinder building the system.
  • tenancy: if you need to have single tenancy for security or legal reasons, you may have fewer options for elastic solutions.
  • data models and authority requirements: poorly performing data models can impact performance. If your application requires certain operations must be from the source of record (permissions checks, for example) then a poorly performing source data model can impact performance which can impact availability.
  • latency: if you have a highly latency sensitive system, then you may need to trade availability for decreased latency. Since availability often means geographic dispersion (to avoid disasters impacting multiple pieces of a system), it impacts latency requirements.
  • cost: high availability systems, because they have no single points of failure, cost more.

Again, this was a discussion from a slack of AWS instructors, but the commentary is mine, as are any mistakes. Thanks to Chad, Richard, Jon, Ryan and everyone else!


Book Review: Working With Coders

Woman with 1s and 0sSoftware is so integral to business processes and relatively inexpensive compared to labor that I believe every company is going to be a custom software company, in the same way that every company is an accounting company or every company uses paper. I happened on an interesting blog post and saw the author had written a book, “Working With Coders”. How non technical folks interact with coders is a topic of perennial interest to me, so I picked it up after reading the first few pages on Amazon. The book is written for clients, CEOs or project managers who are going to be working with developers to deliver applications that will provide business value.

Frankly, I couldn’t put it down.

The author, Patrick, is an engaging, opinionated writer. He breaks down complicated concepts into easily digestible pieces. Where there’s more to the story, there’s a footnote with a snarky comment or a link to more information. Patrick also provides nuts and bolts examples to show why something that seems simple to change is not (scaling text in a browser, for example). He also covers how big decisions like language, frameworks and library choices at the beginning of a project constrain freedom and choices further down.

Patrick covers what developers do, how they think, and why projects often fail. I thought his explanation of the benefits of agile development was darn good, and his explanation that even agile projects fail more often then they succeed was pretty depressing. He also discusses how the house construction metaphor for building software is just a big fat untruth.

I also enjoyed the section about testing in general, the various types of testing, and where they make sense. There’s also a section on finding coders, including a good explanation of why not to hire them as employees (you might be better off just hiring a development shop, depending on your needs). The chapter on how to deal with common issues (“the team hates each other”, “we’re behind schedule”) was worthwhile. His solutions won’t work for everyone. Maybe you’ll want to deal with these issues differently, but considering them before they happen will only help you prepare.

Of course, I also enjoyed the chapter on how to keep coders happy (continuous learning, quiet, a fast computer). In general the author is careful to avoid stereotypes, but does do a good job of covering common themes. I haven’t met too many developers who love working in bullpen environments.

I am definitely not the target audience. Neither is someone who is an experienced manager of developers. However, I am a subject of the book, so it resonated with me and I definitely found myself nodding along. There aren’t too many books I have wanted to distribute copies of (the two others are “The Hard Thing About Hard Things” and “Climate Wars”), but this is one.

If you work in a consulting practice with inexperienced clients or if you work in a product company with an owner or higher up that isn’t technical, reading this book will give you insights into their questions and thought processes. And if you can find a way to give them this book without being condescending (“hey, I found this book fascinating for helping facilitate conversation, maybe you will too”), both they and you will benefit.


Book Review: Beforelife

I really enjoyed Beforelife. It’s a whimsical stroll through a fantasy land that exists after death.  The main character, Ian, arrives in the afterlife with an unusual trait: perfect recollection of his life before death.  This leads him to be institutionalized, where he meets some madcap associates, including multiple people who think they are Napoleon and someone who thinks he was a dog.

The rest of the book is all about how this group helps Ian discover what’s special about him.

I enjoyed the plot twists, which I won’t outline because spoilers.  There are several other historical characters, some named (Socrates, Isaac Newton), others hinted at.  I also enjoyed the world construction.  The world after death is populated by immortals, with interesting ramifications for areas of study like science and social constructs like policing.

If you’re looking for a light hearted jaunt and you liked Douglas Adams or Terry Pratchett, you’ll enjoy Beforelife.


The UNIX and Linux System Administration Handbook

I’ve been reading the UNIX and Linux System Administration Handbook.  It’s a real tome, with about 1500 pages.  It’s got five authors and some great cartoons, and covers everything from shell scripts to disk to email to system management daemons (check out the table of contents).  No one should ever read this book cover to cover.  That would be just silly.

I’ve been really enjoying picking and choosing chapters to read, however.  The sheer breadth of this book means that anyone with an interest in modern software development can find something useful in it.

Given my interest in AWS, I read all the sections about cloud computing.  These were high level and not super interesting to me, but I think they’d be great if you were a novice about cloud computing, and they did have a great survey of the major public cloud providers and when it made sense to use each of them.

Then I moved on to the networking sections.  I honestly can say that I didn’t understand fundamental routing protocols before I read that section.  This is obviously closer to the heart of system administration, and the authors did a great job with concepts and hands on knowledge of networking.

After that I moved on to containers.  Did you know that Docker is the new hotness?  I had heard of it, but didn’t understand why.  Now I do.  It’s hot for much the same reason as the ‘fat jar’ deployment is preferred in java land.  Having one single artifact that rolls up code and dependencies is a way to simplify deployments of production code, including rollbacks.  The authors focus on the fundamentals of containers, primarily Docker, but they also cover various orchestration layers like Mesos and Kubernetes.

I’m now in the middle of a chapter about continuous integration and continuous deployment, where they are discussing the concepts as well as Jenkins, one of the key technologies (see, I told you everyone could find something in this book).  After that, I look forward to reading about configuration management.

If you work in software at all and are involved in production systems, you’ll be able to find something in the UNIX and Linux System Administration Handbook (and if you aren’t, I’d be interested in knowing who owns that responsibility).


Review of Modular Rails

I am currently working on modifying an existing large rails app.  I am customizing some of the look and feel and extending functionality.

The app is under current development and I wanted to be able to take advantage of bug fixes or improvements, without impacting my customizations.  Or at least minimizing that impact.

Being fairly new to Rails, I surveyed the landscape and thought that building my customizations as an engine would be a good way to go.  (I was wrong, because engines have a hard time reaching out and modifying the application that they are part of.  At least that seemed to be a non standard use of engines from what I can find.) The author of Modular Rails has some good blog posts about engines and modularity, so I bought his book.

Pluses:

  • Good overview of how to extend three major components of rails app, models, views and controllers
  • Easy reading style
  • Leverages existing gems like deface
  • Mentions testing
  • Starts from first principles and then later gives you a gem to speed up development
  • Not too long
  • Information on setting up your own gems server

Minuses:

  • Focus on ‘greenfield’ apps.  No mention of integration with existing monoliths.
  • Uses nested modules, unlike every other engine article out there
  • Assumes relatively advanced knowledge of rails
  • Fair bit of fluff–lots of ‘mv’ commands
  • Extra charge for source code

All in all I am glad I read this book.  It didn’t fit my needs, but it didn’t promise that either.  I found it a good overview of the engine concept, even if he did do some things in a non standard manner and was a bit verbose about unix commands.

If you have done more Rails development, it will be more useful, and it is a great way to think about building new freestanding applications.  I haven’t surveyed the entire rails book landscape but I haven’t found anything out there focusing on Rails engines that is better.


On failing to enter a partnership

I recently explored a business partnership opportunity that was quite exciting.  I had met the possible partner a few years ago.  He has technical chops (a software developer) and runs a company in a sector I’m very interested in.  He had a SaaS application that had real traction–users, revenue.  It wasn’t profitable, but looked like it could be shortly.  If we could find a way to work together, I could own the technical side of things and let him focus on selling and marketing.

However, it didn’t end up working out.  No blowups, thankfully, just a failure to find an arrangement that worked for both parties.

It was quite the emotional roller coaster ride for me.  A business partnership is like marriage without the sex, and so we were both cautious, but it was very easy to get excited about working together and building a big business.  It was all the more exciting to me because he’d done this before.

Here’s what went right:

  • We had open conversations about each of our financial needs.
  • He built a budget and business plan.
  • We used Skype for conversations so that non verbal cues were available.
  • We worked together for a month before hand, which gave us some context.
  • We checked references and had our spouses meet.
  • We planned to get together and work face to face.
  • We used Google docs, which was a great way to share spreadsheets and documents about the business.
  • I reached out to a few mentors to get advice.  Every single person said: “write your expectations down”.  Every one.
  • On the advice of one of the mentors, I read the Nolo books about LLCs, partnerships and business buyouts.  These were tremendous.  Not only did they lay out scenarios I had never considered (what if one of the members of the partnership is disabled?  what if you want to bring someone new in?  what if you want to give time rather than money in exchange for equity?  and many many more), they also give you sample agreements.
  • We set deadlines, both for documents and for coming to a final decision.  We stuck to those.
  • We parted amicably.

And here’s what went wrong:

  • We put off explicitly valuing the existing company until late in the game.  Then it became clear we had pretty different numbers in mind.  We should have done this as soon as we were both interested.
  • We didn’t really know each other, the month of working together notwithstanding.  Just as for investing, I am beginning to think that partnerships work best with lines, not points.
  • The budget and business plan were limited in scope (one year out, then some major assumptions about future years).  Hard to make more detailed predictions about the future, especially since the plan called for major new products.
  • I was in a different state than he was.  This would have made finding common service providers (CPA, mediator, etc) difficult.  No real fix for this, other than one of us moving.
  • Valuing an ongoing, non profitable bootstrapped business is really hard, because most of the value of the business is in the future.  I found some articles, but didn’t find much about this particular scenario.
  • We didn’t really nail down whether this was a partnership, a buy in to an existing business or a valued employee relationship.  Each of these have different equity implications.
  • I didn’t sell myself as well as I should have.

All in all a great experience.  I learned a ton.  Of course, I would have been happier if we could have reached agreement, but I understand why we ended up where we did.



© Moore Consulting, 2003-2020