Soul of an Engineer #4

I missed this update for last 2 weeks. I got sidetracked with a systems update; I was moving all my writing to my own site (www.amsidhu.com). Check it out.

Back to the update...

Becoming a Software Company

"Every company needs to be a software company" is a common refrain within enterprise software industry. But how can an enterprise "become a software company"?

There is no formal knowledge or a manual. The best examples come from dominant software companies. The deep knowhow is mostly practical wisdom amongst good software engineers, leaders or teams. And there is just a lot of usual hype and noise of modern media.

Looking for an answer is highly unsatisfying. So I decided to write one through the lens of my experience. There are many more detailed tactics of course but I am proposing three foundational principles to master first.

1. Leveraging software as a "means to value"
2. Harnessing the power of iteration
3. Managing software as creative work

You can read the full post here (Link).

"Two Pizza Rule" and Origin Story of Microservices

Microservices based architecture is a popular pattern to scale big software systems these days. Jeff Lawson writes in Ask Your Developer that it originated as an effect of Jeff Bezos instituting the "Two Pizza Rule" to keep the size of software teams small.

"As Amazon split the organization up into small teams, they also kept carving up the code into small pieces so the teams could “take it with them” and operate it independently. These teams and their respective code needed a way to talk to each other, and “web services” turned out to be the answer. Instead of each team shipping code into some giant repository that somebody else would deploy and run on servers, each team would run their own code as a service that other teams could interoperate with. Over time, these became known as “microservices” because each individual service typically did one thing, and did it well."

Abstraction in the Real World

You all might have seen the pictures of the container ship stuck in the Suez Canal. No, I don't have anything to add to the already plentiful memes :) :).  

I was intrigued by this tweet from Grady Booch. Grady is a celebrated software engineer from IBM of the 1980s and inventor of Unified Modeling Language (UML). And an insightful Twitter follow.  

Abstraction has a specific meaning in software. Its main goal is to handle complexity by hiding unnecessary details from the user. Computer interfaces are a big abstraction. What presents on screen isn't how things work. But what's that got to do with the ship stuck in Suez Canal?

With the way we handle real world complexity, it turns out there is a link.

I was spending some time with a cousin of mine over the weekend. Her husband who works with corn farmers in Midwest was noting that planting of new crop will be delayed because fertilizer shipments are stuck in the Suez Canal blockage.

As Grady is saying,  a stuck packet (a ship with fertilizers) conveys how interlocked world's supply chains are. The real world complex details of which are hidden from us for the most part otherwise.  

Afterthought

Author, AI Researcher and Poet Brian Christian on the future of AI.

"To me the real, in-flux, changeable and changing world seemed far more interesting, not to mention fun. I’m no futurist, but I suppose, if anything, I prefer to think of the long-term future of AI as neither heaven nor hell but a kind of purgatory."