Page 62 - MSDN Magazine, November 2019

Cutting EdgE DINO ESPOSITO 3 Things: A Few Last Words on Software
For more than two decades, I’ve worked to stay true to the mission of this column and to be constantly on the cutting edge of development. Now that this endeavor is coming to its end, I hope to leave you with insight that can help keep you on the cutting edge in the months and years to come. I won’t be covering any of the new amazing features coming to ASP.NET Core 3, .NET 5, Blazor, ML.NET or gRPC. Nor will I hazard any guesses as to what the future may bring to the IT and software development world in the next five to 10 years. I’m old enough to heed Socrates’ ageless motto: “One thing only I know, and that is that I know nothing.”
So in this, my final column, I’ll share my perspective about three topics and their related buzzwords that are of crucial relevance today.
The Case for Agile in Artificial Intelligence
Everyone in the industry is using artificial intelligence (AI) as a bullhorn to reach and impress the widest possible audience, and emphasizing AI as a tool that can solve any IT issue and streamline any convoluted process. This is all marketing hype.
At its core, AI isn’t magic—it’s data crunching, elbow grease and software acumen. Companies don’t need AI, per se, they need end- to-end solutions to their concrete business problems and measurable results for their efforts. AI, and more specifically machine learning, is the most powerful tool we have to provide a new generation of end-to-end, tailormade solutions, at a reasonable cost.
The problem is, doing AI in the real world is much more frus- trating than people think. For complex real-world problems (say, production forecasts in renewable energy) you don’t end up using a canonically trained model. Instead, you work with soft- ware artifacts that are only minimally trained (on a small number of variables) and analytically process frequently changing live data such as weather forecasts.
Another great example is fault prediction or predictive maintenance. If you search around, it may seem a problem good for an exercise— you can find plenty of short articles about it on Web sites. The thing is, fault prediction requires a Long Short Term Memory neural net- work, which is one of the trickiest flavors of neural networks to work with. Still, companies are actively looking into solving the business problem of reducing downtime and optimizing maintenance with more analytical, half-human, half-machine forms of predictions.
All of this is to say that AI is really just a newer and fancier name for problem solving, just with more advanced tools.
In companies, the data science team is often seen as the pana- cea team and charged with too many (or too few) responsibilities.
The reality is that too often a waterfall-style model is established to rule the collaboration between data science and software. One team delivers the trained model; another team mounts it into the host application. Sometimes it works with the live data of the real world, but, more often, it doesn’t. I’ve seen algorithms needing input that no client application could realistically provide. I’ve seen algorithms trained on data taken from one wind farm and tested for acceptance using data from another wind farm using different turbines and subject to different orography. The trained algorithm needs to be an integrated part of the software solution.
For serious AI, you need an agile process that positions the data science and software teams to work as a single team, or at least to work together closely. The importance of data/software collaboration is the reason I suggest looking into ML.NET rather than commit- ting to Python for general machine learning development. The rich ecosystem of coded algorithms and libraries for data manipulation in ML.NET mean that developers can leverage the power of SQL Server, Entity Framework and the .NET Framework to work with data. There’s no reason for .NET shops to use Python—thinking so is a clear sign that you may be missing some crucial points about AI.
Event Sourcing over Blockchain
More than a decade ago, blockchain was devised to function in the context of a very specific scenario: solving the double spending (DS) problem in a deliberately decentralized system. In a nutshell, in a digital cash system, DS is the problem of preventing digital money (which, ultimately, are just files) from being duplicated or tampered with. A physical coin can be spent once at a time, and a person can only spend it only if he or she has legitimately received the coin from another individual. Blockchain is the software platform devised to avoid DS in the context of the Bitcoin cryptocurrency. (By the way, DS is most decidedly not a trivial problem to solve.)
As Bitcoin gained traction, the term blockchain gained ascen- dancy. But from a development perspective, the various cloud services offering blockchain networks are ultimately providing storage. So what’s the difference between blockchain and other storage platforms such as relational databases? One is decentral- ized governance and another is stronger resistance to tampering. A third aspect is the event-based nature of the blockchain storage.
My personal thinking is that the inherent ability of a blockchain network to track every single transaction is the aspect that makes it so attractive and intriguing. Putting something on the blockchain records that a thing happened, and when and how that thing
50 msdn magazine