Page 63 - MSDN Magazine, November 2019

Figure 1 The Tight Coupling of Software and Data in Artificial Intelligence
happened, can be easily tracked back. It’s as if the coin in your pocket could let you inspect the entire list of handovers it was subject to since it was released from the mint. That’s what blockchain was made for—maintaining the history of transactions for all indi- vidual Bitcoins with the certainty that no transaction or past facts could be altered. Therefore, blockchain makes perfect sense in the context of Bitcoin and cryptocurrencies.
So in what way can blockchain help (some might say disrupt) the general industry?
The only reasonable value I see is for countrywide, or even transnational, networks that store shared and continuously edited information. Who manages these networks, though? In the end, it’s always about storing data at some location (centralized or not) and having someone review and approve it.
The issue goes far beyond the software aspect of storage. If we only talk about traceability of business facts, then event sourcing is a much more concrete alternative. Event sourcing is an approach to building the data layer of software applications in which all the changes to the application state are stored as a sequence of events and each change is treated individually. You have a record (or an event) when an order is created, another event when the order is updated the first time, yet another when it’s updated the second time, and so forth. To get the current state of the order, you must replay the entire list of events, similar to how you determine the balance of a bank account. It’s a number, but it results from the entire list of operations you made over time.
Event sourcing frameworks work in an append-only mode, with the deletion of objects tracked by adding an event that describes when and why the order was deleted. These frameworks typically don’t fully support blockchain key features such as decentralization, voting and anti-tampering measures. But the idea of tracking everything also can be achieved via event sourcing, and from event sourcing with some extensions you can get very close to block- chain. Hence, the focus returns on the actual problem you want to solve rather than how you’d like to solve it.
Over Engineering: Just Say No
We’ve seen modern software giants court complexity to adapt to rapid growth. Facebook adopted polyglot persistence to serve its hundreds of millions of active users. Amazon switched to Web services, Netflix tomicroservicesandGoogletogRPCoverREST.Alas,Ifearwemay be learning the wrong lessons from these success stories.
msdnmagazine.com
For instance, today it seems almost inevitable that any Web appli- cation must be designed around microservices. I’m old enough to have worked with Distributed COM and I recall the first (and only) law of Distributed Programming: Do Not Distribute It. A distributed architecture has pros and cons and it’s never obvious when the pros will overtake the cons. Working within a net- work brings new issues such as latency and synchronization, and amplifies others such as debugging and security. In a nutshell, everything is more complex.
Complexity is justifiable when it brings a tangible return. But in my experience, starting out with a complex design because it was used successfully in another scenario has never proved wise. Instead, you should constantly monitor the effectiveness of your design and add complexity only where and when necessary. Over-engineering is always costly and risky.
A Farewell Note
I’ve been asked many times how I can keep up with quickly changing software technologies and grasp the issues related to development problems without writing enterprise code around the clock. My secret is I try to get at the foundation of things and think of software as the mirror of business processes designed by humans. Deep understand- ing of the business smooths the task of writing software and makes it kind of mechanical work. Deep understanding of technologies makes it easy to see if it fits in a specific business problem.
To a certain extent, software is a physical thing and is subject to familiar physical laws, such as entropy. At the same time, software is a human thing and, as such, is influenced by some context-specific form of empathy—the ability to understand. While we all know about entropy and its impact on code over time, I’m more interested in empathy, which expresses the ability of software to penetrate the internal mechanics of processes. Empathy impacts the quality of software and can even reduce entropy in the long run.
The power of understanding things—call it software empathy— is what I leverage in my every day activities and that I tried to illustrate by example in my columns. I ended up writing because I had always wanted to be a writer, and I found that being a coder was one way to be a writer. So I put passion and empathy into it, the same way I worked to push passion and empathy into my code. Did it work? The fact that this column has thrived for more than 20 years is a clue!
I wish to end with wisdom from some great men, just adapted to software. Let’s call them my messages for posterity:
• Keep it simple, as simple as possible. Otherwise it’s over-engineered. (Adapted from Albert Einstein)
• Don’t forget to pay your technical debt. (Adapted from the reported last words of Socrates)
• Perhaps a problem did not want to be solved so much as to be understood. (Adapted from George Orwell)
Stay in touch at youbiquitous.net. n
Dino Esposito has authored more than 20 books and 1,000-plus articles in his 25-year career. Author of “The Sabbatical Break,” a theatrical-style show, Esposito is busy writing software for a greener world as the digital strategist at BaxEnergy. Follow him on Twitter: @despos.
November 2019 51