How the Israeli Mossad Deals with Legacy Code and Other Lessons from DevOpsDays

How the Israeli Mossad Deals with Legacy Code and Other Lessons from DevOpsDays

Recently we visited the DevOpsDays conference in Tel Aviv, and thought to summarize our impressions from that day.

The conference is a worldwide series of technical conferences covering topics of software development, IT infrastructure operations, and the intersection between them.

At the Israeli event, one runs into a who’s-who of the hottest tech companies both in and outside of Israel: Facebook, Google Cloud, Microsoft, WalkMe, GitLap, Akamai, and logz.io, to name but a few.

How can we survive continuous innovation?

The first keynote speaker we heard was Sebastien Goasguen, the senior director of cloud technologies at Bitnami.
He is the author of the book “Docker Cookbook“. This work offers 130 ‘recipes’ for developers, operators, and IT professionals on how to work with Docker. Docker is a software technology providing containers and an additional layer of abstraction and automation of operating-system-level virtualization on Windows and Linux.

Empathy for users

The IT industry has been taken by a storm of new technologies boosted by open source. How can we follow all of these changes? How can we make decisions and keep up with wave after wave without being overwhelmed by all the applications that are out there?
The speaker’s point was that you have to develop a culture that adapts to that constant change without forgetting what DevOps really means. He said that these new tools will not break your silos, and he encouraged their use. He also stressed the importance of always staying curious, being critical while not becoming a “hater”, and not dismissing changes out of hand.
Sebastian emphasized the development of “empathy for the users”, and suggested the following books:
  1. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win” – according to Goasguen this is a very light and fun read: “It’s like a novel…”
  2. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition”

Who of our readers has read these books?

The Theorist of Constraint

The next keynote speech was given by Rami Goldratt, CEO of Goldratt Consulting. He shared his insights regarding developing and implementing ‘theory of constraints’ (TOC) applications. TOC is a term that was coined by his late father, Dr. Eliyahu Goldratt, who identified the importance of achieving goals by identifying one’s limits.
Many fail to reach their objective because they focus on ‘chupchick’ ideas. Chupchick is a Hebrew word, derived from Russian, that translates to ‘tiny thing’.  Goldratt argued that focus should be on big, meaningful things that remove significant limitation, and not on just anything that comes to mind (the so-called  ‘chupchick’ ideas) .
What’s that got to do with the DevOps world? Goldratt’s message is universal and adapts the approach of acknowledging one’s weaknesses and turning them into leverage. This is a perspective that technology companies can benefit from. Apparently Amazon and Google benefited from those principles but unfortunately, Goldratt ran out of time before he could elaborate on this. Maybe we’ll discover how Google and Amazon did it another time.
People busy communicating

Dealing with the Legacy Code Mess

Before we returned to work, we listened in to the ‘open space’ discussion on how to deal with legacy code. Legacy code has been described as “the code no-one wants to deal with any more” and this was expressed by many attendees of this discussion. People sat in a circle and very quickly the discussion began to feel like a support group meeting in which the participants shared their accounts of traumatic encounters with legacy code.

Though a solution wasn’t found during this discussion, just dealing with the burden collectively felt like some kind of recovery. Hope spread with the realization that a legacy code doesn’t necessarily need to be a bad thing as long everything functions as it was intended – no matter in what language it was written and how old it is.

Accepting the code for what it is was another conclusion that helped the group. It is said that acceptance is the first step towards rehabilitation, and it definitely felt comforting to learn that companies and organizations such as Citi Bank, Visa and Mossad all have to deal with the issue and feel burdened by it. Someone mentioned that the company Wix rewrote their entire code four times. While this endeavor is possible for a young(ish) tech company, established institutions such as the Israeli Mossad are less likely to be flexible enough to make such drastic changes.

There is a constant fear of touching (and destroying) legacy code. However, as the German saying goes, ‘shared misery is half misery’ – this meeting may have helped some be less afraid.

These were some of our observations from the conference. Were any of you there as well? Did you enjoy it? There were other discussions that seemed interesting too:

If anyone attended these sessions and would like to share their impressions, we’d be happy to hear from you.

TOP