Rogish Reading Writing

Software, management, people.

What Happened and What’s Going On

Wow! What a difference a year (and more) makes!

In an effort to hold myself accountable, I’ve started blocking out time in my calendar to do outreach. Dusting off this site is part of it. I’ve been relatively quiet about what I’ve been up to, for reasons that are equal parts “I’m too busy” and “If it blows up, I’d rather not talk too much about it.”

Both are still true, but it’s worth doing a retrospective so I can clear out some posts I’ve had in the hopper. I joined Rails Machine as CTO early 2014 with the goal of stabilizing the company, reducing customer churn, and figuring out business and technical strategy. I was able to take a down and to the right trend and turn it around to a (gentle) up and to the right (with the awesome Dustin Beason taking over and growing that slope), made some tough personnel changes, and prototyped, piloted, and released a new product/service called “Managed Operations”.

This prototype quickly reached product/market fit, and Bradley (RM’s founder) and I decided the best course of action was to spin out the service into a new firm. Thus, we launched a new business called ReactiveOps. Although I’ve been CTO/Director of a number of very early stage (nascent) businesses, it’s something else entirely to go from zero to incorporation to functional entity.

In under a year, we’ve gone from me and one other engineer to a team of 8, all self-funded/bootstrapped. It’s been an incredible learning experience – and one not without a significant amount of stress. We’ve achieved some amount of success and it’s looking like 2016 will be a significant one for us. There’s still risk – we started off as a consultancy to write/build product – and until product revenue outstrips consulting (by Q4 of this year, if all goes well), we’re still in a precarious position should consulting revenue dry up.

I’m looking forward to another look back early next year, showing us growing to about 14 people, closer to a 50/50 split of consulting and product revenue, and lots of new opportunities.

Technology Leader Mentorship Program

Yesterday I was talking with a CTO colleague and we were lamenting the lack of educational or support resources for technology leaders (CTOs, CEOs of tech cos, etc.) on the “softer” side of the job (people management, group dynamics, process selection, etc.)

I realized we could do something about it, so I decided to organize a technology leadership mentoring program where technology leaders can connect 1:1 with mentors and discuss the challenges of working with the software of our greatest assets: our people.

The format is simple: you’ll either be a mentor or a mentee (or both!) and I’ll connect you with the requisite partner.

We’ll have periodic group events where mentors will present a topic (google hangouts on air) that focuses on the people side.

The mentorship program will run 3 months, although there’s no need to stop if you find that you’re working well with the other person.

If you’d like to be a mentor, or connect with one, please register your interest here:

Powered by Typeform

I’m going to keep it small to start, so sign up quickly!

A Modest Proposal: How to Replace Semver

I was browsing the Twitterscape and saw this tweet:

Mercifully I’ve been able to ignore Semver for a long time, but all this bru-ha-ha got me thinking about how we solved it in a previous open-source project (years ago).

APIs/libraries/projects/etc. need two versions. No, wait – don’t go. It’s pretty simple and looks something like 3.2.1-44 (marketing release-API version).

Marketing release: Major.minor.patch

API version: monotonically increasing integer

Whenever you introduce a breaking change, no matter how small, increment the API version to communicate that someone will need to do something to upgrade. At the same time, increase the marketing release to communicate the expected impact. I’ve found these work well:

Major: A really really big release. Likely you will have to change many things. Rails 2 to Rails 3 would be a good example.

Minor: It breaks some things, but should be migrateable in under a few days to a week.

Patch: Something small is broken. Likely you realized that some method had a security hole and now you have to patch it by changing the semantics. Intent is that upgrading to this release is doable in under a day.

Drop-in change? Leave the API ver alone. Adjust marketing however you want to communicate whatever you want.

That’s it! Super simple. Let the marketing version communicate the magnitude of the change and let the API version let someone know if they need to fix anything. Works for both people and machines!

If your project follows this, someone could even write a simple little status page that would give you rough estimates on how long it would take you to upgrade your app.

Maybe even integrate it into something like bundler

> bundle update --estimate

1
2
3
4
5
6
7
8
9
lib: current marketing version - API version ->
     latest marketing version  - API version ::
     effort estimate

rails: 4.1.1-4003 -> 4.2.0-4003 :: no breaking changes    (0 days)
rspec: 2.2.0-300  -> 3.2.0-433  :: major breaking changes (1+ weeks)
pry:   1.2.0-13   -> 1.3.0-14   :: minor breaking changes (2-5 days)

how far behind: 2 gems, 1-2 weeks est

Note: if you are concerned about the API version growing annoyingly big and “looking weird” then you are sort of missing the point. I concede you could reset it when you increment the major ver, but then you run the risk of automated systems failing to report a version conflict if they just do a simple check, e.g. upgrade gem unless my API ver < your API ver. Better to leave it alone, the API ver is primarily for machines anyway.