HN Books @HNBooksMonth

> OKRs don't fix dysfunctional organisations.

Very true.

However -- note that the process of implementing OKRs has caused the leadership team to write down their expectations, which previously might have been unspoken. This is a first step towards resolving the problem. The next step is for the CTO to push back, hard, on the bits of these that aren't actually realistic, and hopefully get the leadership team aligned on what can actually be done. And so, the process of OKRs potentially has value here in flushing out unrealistic or mismatched expectations between different parts of the org.

This is one of those rare "my way or the high way" moments in leadership; as CTO at this company it's your job to either get the leadership team to realize that they are asking you for more than you can be expected to deliver, or quit. You can't stick around and put your name on a plan that you know is impossible; otherwise you're going to be the one that failed for every quarter to come. And even worse, you can't sign your team up for this BS. It's your job to shield them from this kind of shit.

> Half the Objectives were outside the scope of the engineering team.

Shared OKRs are difficult, but sometimes they are unavoidable. The most difficult business problems usually are cross-functional. At their best, OKRs can help to make these cross-functional dependencies more explicit, and foster communication and collaboration around them.

If they are trying to have engineering take full ownership of a shared OKR, that's a big problem. But if you clearly call out the shared ownership, and consider both parties responsible for implementation, then I think that's OK.

> We were to going to increase our release cadence 10x. We were also going to reduce production issues by 100%. That's right, our objective was 0 production issues whilst massively increasing our release cadence with 0 extra resources.

As a tangential point, increasing release cadence can definitely decrease your long-term rate of issues (see "Continuous Delivery" by Humble[1]) -- this forces you to automate manual processes, and manual processes are one of the main places that errors creep in. Though I think "count of issues" is a very poor metric, you're better off with an uptime metric. And "100%" is the only strictly-incorrect number to pick for uptime, because it is literally impossible; my (super-unscientific, don't hold me to this) rule of thumb for business people is "every extra 9 costs you 10x". So do you need 99.9% uptime or 99.99%?

[1]: https://www.amazon.com/Continuous-Delivery-Deployment-Automa...

⬐ Traster

I’m glad you mentioned this, yes the CTO quit 6 months later.

I'm not sure there is one really, because deployment varies a lot depending on your technology stack, your architecture, your deployment model, your product. You sort of learn the fundamental concepts and then pick out the pieces that fit your use case.

Everyone should read Continuous Delivery to start (https://www.amazon.com/gp/product/0321601912/ref=as_li_tl?ie...). It's 10 years old but it's still the canonical reference for how most people should be deploying in the modern age.

A book on containers would be the next thing I'd learn very thoroughly. Whether you run them in Docker on a single host, or run them in a cloud orchestration system, doesn't matter really. Just having an app in a container provides the abstractions you want to enable rapid, reliable deployment on multiple platforms. Most deployments should be dead simple: pulling and starting a new container, pointing traffic at the new container, stopping the old one. Rollback is the same in reverse order of container. There should be a billion different services to manage this for you, but you can also do it yourself on a single Linux box easily.

Then a book on database migrations, which isn't really complicated once you get the jist of it. This teaches the idea that if you're using a database, you have to think hard about how you're using it in context of your code deployments, and gives you a model for how to handle both reliably.

Next, the tools Terraform and Packer are very useful for handling the "infrastructure" side of deployment. If you manage an actual VM that runs your apps, build the image with Packer and deploy it with Terraform. It's much better to use some managed provider that just runs your containers so you don't need to deal with this. But if you do need to manage a host OS, this will make it seamless and reliable to do the inevitable maintenance in a way that you can test first, and recover easily from failure.

Ensuring your app works along the methods of the 12 Factor App (it's just a website, no book) will make sure it fits into all the tools and methods. If you just look for the deployment piece of every part of 12FA, you'll build a very robust deployment system.

Finally, learn Bash and how to set up a web server like Nginx (and how to use it as a reverse proxy) and you will have basically all the skills you need to do modern best practice deployments.

devops is more of a principle than a job. that's my opinion though.

i've been reading through this book and it does a decent job of covering the principles for CICD, builds, tests releases: https://www.amazon.com/Continuous-Delivery-Deployment-Automa...

you'll run across various "thought leaders" in devops and its important to remember that a) each employer treats devops and cicd differently and you'll want to learn their practices as you bring about your own ideas to the culture and b) form your own opinions, just b/c thought leaders and books are out there its important to learn what you like to do and improve how you like to do it.

If you haven't read it already, read Continuous Delivery.

https://www.amazon.com/dp/0321601912

Continuos Delivery by Jez Humble and Dave Farley

http://www.amazon.com/gp/aw/d/0321601912

Just started reading "Continuous Delivery" by Jez Humble, et al. Really wish I would have grabbed this years ago, great primer on what (for me) is a confusing topic. http://www.amazon.com/Continuous-Delivery-Deployment-Automat...

One of my most popular blog posts (by a long shot) ended with the words "is dying" http://jmoses.co/2013/12/21/is-ruby-dying.html. I love figuring out ways to get people to click on my articles.

With that said, we also do a read only branch called stable that we only push to once unstable gets the OK in Jenkins. I would not say that it is dead, but just an extra safe guard. I do appreciate that book recommendation on http://www.amazon.com/gp/product/0321601912/ I have not heard of that before.

⬐ bubble_boi

You really should be starting your titles with 'why', for that extra punch.

In my opinion, this book[1] is the authority on continuous integration and continuous deployment.

Continuous Integration is fundamentally about creating a tight feedback loop between your developers and your code. When you program in your IDE, the instant you write uncompilable code, you get red squigglies, so you're getting an instant feedback loop on something you just wrote.

CI is the same thing, but at a higher level. The instant you commit your code, some automated process should take over and start analyzing / compiling / testing your code and look for things to give you feedback on. If your code doesn't even compile -- one of the first milestones of CI, you should know that immediately.

Since you just committed it, making the fix is easy. This is compared to a developer who downloads your code the next day, can't compile, comes and bugs you about it, etc...

As far as some real world use cases, we just setup Jenkins for a new Java project we're writing. It does an automated build test that compiles and executes all unit tests automatically on any commit to GitHub on any branch. It's a little slower than I like -- our still growing app takes a full 3 minutes to compile and give feedback.

But, it's been great. For example, the GitHub client on Mac OS X doesn't recognize when I change uppercase letters to lowercase and vice versa, so while my local compiles worked fine, my repo actually had a failing build. Once I committed, I got an automated email within 5 minutes telling me the build failed, and I fixed it. Without CI, I may not have found about that issue for weeks, making the change more difficult.

For production deployment, we're still in alpha, but we've got a 1-button push to deploy. Again, slower than it should be -- in this case 5 minutes -- but the automation is awesome and makes doing any deployment -- whether hot fixes or new releases that much more pleasant.

Regarding the performance, I see it as a win just to get anything automated, however slow it may be. Because once you're there, you can always look for ways to optimize it. For example, our current build process, re-downloads dependencies every single time. This could clearly be cached. When it's a priority for us, we'll do it.

[1] http://www.amazon.com/dp/0321601912?tag=contindelive-20

⬐ rubiquity

> [1] http://www.amazon.com/dp/0321601912?tag=contindelive-20

Did you just put your Amazon associates referral code in a link on HN? lol

⬐ joshpadnick

No, I didn't. I don't even have an Amazon associate's referral code, so I must have pasted someone else's. Hoping 1 person on Hacker News will buy a book I linked to in one comment so I could earn $0.25 does not strike me as a great earnings strategy.

I thought the continuous delivery book was written by Jez Humble and David Farley. Fowler provides a foreword for it http://www.amazon.com/gp/product/0321601912?tag=contindelive.... Other than that I totally agree with you comments - Lean Continuous and Agile are not orthogonal to Quality.

⬐ davesims

You're right, sorry. It's in the "Martin Fowler" Addison Wesley series of books, it's not written by Fowler. I've had the book on my shelf and read a good bit of it, and should have caught that!

"Martin Fowler" is on the cover in two different places, plus it looks just like the cover of Patterns of Enterprise Application Architecture, which he did write, so I've had that misconception in my brain for a while. Failure to test assumptions...

⬐ wr1472

Easy mistake to make. I believe Jez works for ThoughtWorks too and I'm guessing Fowler had some input in the idea.

If you are specifically interested in this kind of continuous deploy process then "Continuous Delivery[1]" is a decent book on the subject. The IMVU post "Doing The Impossible 50 Times A Day[2]" is another good place to start reading.

[1] http://www.amazon.com/gp/product/0321601912

[2] http://timothyfitz.wordpress.com/2009/02/10/continuous-deplo...

⬐ czzarr

thanks a lot