There is always an occasion where there is a complex issue, one that even the most skilled engineer struggles with. I do quite a bit with cars (restoring, building, and racing) and they are fairly simple machines all things being said. In that problem solving phase, without fail, in will sweep the Sunday mechanics with the “oh you must need to adjust the carb floats – how hard can it be?” To which I quietly nod and say “yeah, I’ll have to give that a shot.”

Tuning cars for racing is hard, but computers are really hard and until I read this series entitled “Computers are Hard” put together by Wojtek Borowicz (@wojtekborowicz) a tech editor for medium.com I am not sure that I fully realized that. The series is written in 9 parts covering things like “bugs and incidents”, “networking”, and “system performance”. Each article is in an interview format with professionals like Jeff Fritz, program manager at Microsoft for ASP.NET, and Rita Kozlov a product manager at CloudFlare.

David Heinemeier Hansson, the creator of Ruby on Rails (and fellow car racing enthusiast), explains why the team at Basecamp doesn’t follow textbook Agile practices in one of the articles in the series. He provides a narrative that is candid but from my perspective likely true.

David reflects, “To be constantly reevaluating everything you’re doing every two weeks because that’s when the newsprint cycle starts — it’s going really fast, nowhere. This is why we don’t do daily standups. This constant churn, just spinning around in a circle on a very tight leash. I think it’s actually dehumanizing.” He continues, “Agile methodology as it’s practiced lately, over corrected and went way too short. It says two weeks with the daily standups is this magic cycle. No. People need some slack. Some autonomy. Some space.” David also reflects on something I have always agreed with and that is “Software development is not engineering in the same sense as building a bridge. They’re not just a different branch of the same root discipline.” Meaning they have the same principles but don’t require the same rigor.

pexels yan krukov 7793645 1

“You can tell this is a stock photo because no one is that enthusiastic during a standup meeting” – Wojtek

One of the installments that is all too relatable is an interview with Charity Majors, CTO of Honeycomb about bugs and incidents. 

There is no other industry so accustomed to its products breaking that it’s considered part of the daily routine. Think about it. If one day every Prius in the world refused to start for a couple of hours, Toyota would face international scrutiny and would be forced to recall hundreds of thousands of cars. If an app isn’t working, you google if it’s down for everyone or just for you and come back later.

Charity Majors, CTO of Honeycomb

The complexity of the microservice architecture exacerbates that by having systems that rely on end points that our system may depend on but we have no control over its actions.

At the end of the day, computers are hard. Harder than most people realize and will likely ever understand. At Cambria, we have a ton of really smart people who make computers work on a huge scale, under the toughest odds. Every once in a while, we should take a second to appreciate the lions we tame.