patkua@work

The intersection of technology and leadership

Category: Continuous Delivery

Book Review: Accelerate

May 27, 2018 / / 0 Comments

I first heard about this book when I saw Jez Humble (@jezhumble) keynote at OOP earlier this year. You will get significant value from this book. Jez has already made many contributions to our industry. He introduced Continuous Delivery (CD) and the Lean Enterprise. He also helped shape the field of DevOps, as we know it today.

The Science of DevOps: Accelerate Book

Think about this book as a very readable academic paper, based on the long-running State of DevOps report.

Rigour in its research method

The book describes how the authors gathered vast data and their research methods. They discuss their observations and lead you to their conclusions, with concrete examples. The author shared how some of their assumptions turned out false. An example is the study showing how there is a positive correlation with Trunk-Based Development (TBD) and quality. This technical book is a rare gem based on rigorous research methods. Nicole Forsgren obviously had a large impact on the book

I’m amazed at how rich their raw dataset is. The authors draw on four years of data from many responses around the world. Their sample size towers over many academic studies. Many academics rely on student control groups instead of real industry data. Rarely academics also get to study a few companies or teams within a single company. The wealth of the raw data gives more weight to the report’s authenticity and credibility.

Martin Fowler highlights one point in the Foreword which I agree with. Even though the survey raw data comes from many sources, it is still self-assessed. Self-assessments are naturally biased by Dunning-Kruger effects.

Strong guidance and good advice

Our industry struggles with useful performance measures in IT. Metrics are either irrelevant or drive poor behaviours. This book debunks false prophets like Gartner’s Bi-Modal IT. Spoiler: You can got fast AND have quality, unlike normal assumptions. The book, Accelerate, gives strong suggestions for useful KPI measures. The authors present convincing conclusions that any modern technology firm should take on. This book gives many ideas to improve software and organisational architectures, and processes.

Many studies such as this focus only on the technical practices (such as CD or TBD). Many experience people realise a focus on technical practices is not enough. They realise organisational processes or structures constrain the value technical practices bring. To make the most of technical practices, management must look at their processes and structures. (Disclaimer: We address this topic in our book about Building Evolutionary Architectures). Maybe it’s confirmation bias, but the chapter on Transformational Leadership is super important.

Here’s an simple example why. Imagine you have an organisation with a Head of Development and Head of Operations. Each have hundreds of people with different reporting structures and processes. If the Heads do not support new initiative like DevOps, collaboration won’t move very far.

Conclusion

I found this book extremely easy to digest. I wanted to read more about their research methods. The authors convinced me of their conclusions and made them come to life with concrete examples. I highly recommend this book for any technology executive in the modern world. Accelerate sets the standards for measuring the performance of technology firms in 2018.

Book Review: The Phoenix Project

April 3, 2016 / / 0 Comments

It has been a while since I read The Phoenix Project and I am glad to have reviewed it again recently. Described as a business novel, or The Goal for the 21st century, the book focuses on a story that large organisations need to realise when they feel they need to transform IT.

Title cover of the Phoenix Project book

The book focuses on a company in crisis – a company that is trying to complete lots of software projects, has a terrible number in flight and grapples with the problems many companies have – lack of visibility of the work, dependency on key individuals, marketing lead promises and IT treated as a cost-centre attitude. Bill, an IT Manager is one day promoted into a higher role where he is responsible for turning around and dealing with all the critical issues. He is given access to a mentor who introduces him to the “mysterious Three Ways” that are slowly uncovered throughout the book.

What I liked about the book

Business novels are refreshing to read as they feel less like reading a business book and sometimes makes picking up the book less of a chore. The authors manage to talk about generating insights and explaining some of the tools from a number of angles (Bill’s thoughts as well as from other characters’ perspectives) as well as relating it to existing material such as Theory of Constraints.

Like all good books, you follow the exciting story plot that descends into what seems like an insurmountable situation, only for the protagonist to find ways of overcoming it. For those who have never been exposed to visual ways of working (like Kanban), or understanding Work in Progress, Queueing theory and how IT capability matters to business, there are many useful lessons to learn.

What would have made the book better

Although the book has several characters who behave in a negative way, and pay for some of thoese consequences you don’t hear about the attempts by the protaganist which end up failing (with their consequences) unlike the real world. I also felt that the pace at which things changed seemed to occur at an unrealistic rate – but that’s proabably the downsides of a business novel versus what might actually happen in real life.

Conclusion
I would still highly recommend this reading if you’re interested in understanding about how modern IT, interested in how DevOps culture operates and some tools and techniques for moving IT management into a more responsive, flexible but still highly controlled manner.

Thoughts on OOP2015

February 4, 2015 / / 0 Comments

I spent the first half of last week in Munich, where I was speaking at OOP Conference 2015. I missed last year when Martin Fowler was a keynote but had presented both in 2013 and 2012.

The conference still seems to attract more seasoned people like architects and decision makers and I am still constantly surprised at the number of suits I see for a technical conference – I do not know if that is more of a German culture difference as well. I felt like there were significantly more German-speaking sessions than English ones, and I sat in a number of them when I expanded my vocabulary.

I was only there for three of the five days of the conference, and was lucky enough to be invited and attend a special dinner on Monday evening where Dr Reinhold Ewald (a former German astronaut) gave a presentation about what it was like being an astronaut, what they do in space and some of the interesting challenges.

I saw a number of the keynotes and talks which I’ll briefly summarise here:

  • Challenges and Opportunities for the Internet of Things (IoT) by Dr Annabel Nickels – A relatively introductory session on what the Internet of Things actually means. The talk explained the IoT well, why it’s not possible and what people are experimenting with. It was clear that security and privacy aspects had not advanced and that there was still a lot of work to go, as there were lots of questions from the audience, but no clear answers in this space – more “it’s something we’re looking into”-sort of answers
  • Coding Culture by Sven Peters – Sven is an entertaining, engaging and obviously well-practiced presenter who knows how to engage with the audience with pictures and stories. His talk focused on coding culture – but more particularly the coding culture of Atlassian, the company Sven works for. An entertaining talk about how they work inside the company, but was not particularly surprising for me since I know already a lot about that company.
  • Aktives Warten für Architekten by Stefan Toth (Actively Waiting for Architecture) – A nice introduction to the Last Responsible Moment or what is more popular in the Agile community these days, Real Options.
  • Ökonomie und Architektur als effektives Duo by Gernot Starke, Michael Mahlberg (Economics and Architecture as an effective pair) – From my understanding, the talk focused on bringing the idea of calculating ROI on an architectural front. The pair spent a lot of ideas introducing financial terms and then a number of spreadsheets with a lot of numbers. Although well-intentioned, I wasn’t sure about the “calculations” they made since a lot of it was based on estimates of “man-days” needed and “man-days” spent/saved – it all looks very good when calculated out, but they didn’t really spent much time eliciting how they get estimates. They spent a lot of time introducing Aim42 which I wasn’t familiar but will now look into.

I ran two talks that had both good attendance and great feedback (like the one below):

OOP2015 - Best Talk

The fist was “The Geek’s Guide to Leading Teams” where I focused on exploring the responsibilities and remits of what a Tech Lead does and how it’s quite different from being a developer.

The second was “Architecting for Continuous Delivery” which focused on the principles and considerations for when people build systems with Continuous Delivery in mind.

I had a great time visiting the conference and had an interesting time expanding my German vocabulary as I tried to explain what I and what my company do in German – something I didn’t really do a lot of when I was living in Berlin.

Why we moved off heroku

August 22, 2013 / / 1 Comment

We recently made the move off heroku to a more basic box because we ran into a couple of issues. Although I don’t think that these are issues you will face in many other places, it proved to be worth moving.

First, it’s worth noting a bit of context for the application we were building. Although being web-based, we are building a prototype application connecting up a pre-designed user interface to a number of backend systems. We do not own the backend systems, we simply integrate with them. Our goal is to quickly see how difficult some of the implementation of an interface such as one envisaged would be, and also to discover gaps or contradictions in the data structures we get back by working through a real example.

Our First Problem
The first problem we had is a hard timeout, limited to 30 seconds and enforced by the routing layer by Heroku. They document it very well here. As they mention in their document, “the timeout value is not configurable” and is a reasonable constraint on normal web applications that you want to scale. Given our current design and architecture, moving away from a synchronous, stateless application to a model of asynchronous, polling would certainly add more application complexity to our code.

Our Second Problem
The second problem we had was strange behaviour with a java application deployed. When connected up to other external systems, the java application seemed to continue growing in its memory use. Restarts, new redeploys didn’t seem to fix it. We tried this labs feature (log-runtime-metrics) to get more insight but could only see memory go up and up. We tried setting the max heap size to a small amount but that didn’t seem to do anything. Concerned we had a real memory leak, we ran the code locally with the same production settings with a very small heap size and could not replicate it.

Our conclusion
Given where we are, we wanted to move fast without worrying about the infrastructure taking more development time, or unnecessary application code complexity. So we simply moved off. Spun up a new virtual box and were up and running in about half a day. It probably took another day and half to move all of our continuous deployment tasks to our new platform too.

© 2024 patkua@work

Theme by Anders Noren — Up ↑