Anatoly Volkhover - Become an Awesome Software Architect: Book 1: Foundation 2019

Anatoly Volkhover

Become an Awesome

Software

Architect

Foundation

2019

Copyright 2019 Anatoly Volkhover

All Rights Reserved. No part of this book may be reproduced or used in any manner without written permission of the copyright owner, except for the use of quotations in a book review.

ISBN: 978-1-69727-106-5 (paperback)

In loving memories of Nika, who kept our cave warm and our minds sane for so many years.

Contents

My name is Anatoly. I am a serial entrepreneur and software architect from Silicon Valley, with a background in mathematics, physics and computer science. I am one very lucky dude. I studied at the best math & physics school in the former Soviet Union, which has given me a solid foundation for further technological and scientific advancement. I moved to California in early 1990s and immediately dived into an endless stream of projects of varying complexity, across many generations of computer hardware and software stacks.

I started coding when I was 12, initially working on IBM System/360 mainframes, then moved to DEC PDP and VAX systems in 1980s, then to early PCs running MS DOS and then Windows in early 1990, to Tandem NonStop in late 1990s, web apps in early 2000s, and mobile apps and AWS cloud nowadays. I was crazy enough to never shy away from a challenge. I designed and built distributed object-oriented databases, programming languages, virtual machines, business process automation, banking systems, e-commerce solutions, airline booking engines, social web sites, mobile apps, marketing platforms, games, biometric algorithms, and God knows what else. Just as I said, one lucky dude!

Throughout all this time, I remained hands-on with all my projects and continuously looked for ways to make myself and my teams more efficient in building and maintaining software solutions. The meant a lot of trial and error, lots of coding, thinking, and refactoring. At certain point, I became so efficient that I could build a full-fledged custom enterprise solution all by myself, or with a very small crew.

Thats when my wife Elena told me that keeping all this knowledge to myself is criminal. This is how the idea of this book came about.

San Francisco, California
October 2019

Contact

I love making new friends. Feel free to connect with me. I welcome any kind of feedback and enjoy meeting like-minded engineers and entrepreneurs. Below are the links to my web site and to my LinkedIn page. Use whichever one is more convenient for you.

My web site:

My LinkedIn page:

Acknowledgments

I am forever grateful to Victor Eydus, Wesley Tanaka, Max Kuperman, Ken Hilton, Andris Birkmanis, Arthur Shir and Stanislav Tsvetkov for their insightful feedback on the early draft of the manuscript. The comments I received not only helped making this book more accurate and more digestible, but also created a long list of topics for me to cover in the future publications. Thank you!

A very special thank you to my amazing wife Elena, who is the reason behind me getting into writing in the first place. It was Elenas idea for me to share what I learned over the years, paving way for this book and for a few more to come.

A warm hug to my Dad, who got me hooked on computer programming back in my childhood and created many code tinkering opportunities for me to master the craft early. Thank you, Dad!

Many thanks to all amazing engineers whom I worked with throughout my career, those who provided me with so many mind-boggling puzzles to solve, those who taught me by example, and of course those who invested years of their lives into implementing my designs.

I am also grateful to the engineering team at Minted, for trusting me and my methods, and for providing a continuous stream of inspiration.

Anatoly Volkhover

In early 2019, a young first-time entrepreneur (lets call him Joe) called me for advice. He had an awesome idea for his new startup. Joe raised some seed capital from his friends and family six months earlier and used most of it on development of the technology that would power his new business. As Joe was rolling the service out into the market, he realized that several changes must be applied to his technology for the business to succeed hardly a surprise, since most products go through a lot of fine-tuning before they are ready for their prime. Joe wasnt surprised at the need to make changes either. He got surprised by his team though. His engineers estimated the cost of the proposed changes to be extremely high, close to the original investment made into building the entire system. Joe was devastated. He had very little cash left, and it was all earmarked for PR and marketing. Joe called me, crying for help. He hoped that I might be able to find a smart way to fix his system on a shoestring budget.

Long story short, there wasnt a smart way. I couldnt help Joe, and not for the lack of trying. His team was correct in their assessment. The new requirements invalidated the principles on which his software was built upon. Essentially, Joe had to rebuild his entire technology from scratch. Needless to say, no investor would give him the $$ to fix his technology without having a solid proof of sales. Joe asked around, looking for either the capital or a technical solution, came out empty handed and, a few months later, folded his business.

This was not the first time when I was asked to save the day and couldnt. I met many entrepreneurs facing the very same challenge. I worked for a number of companies carrying an excessively large and expensive engineering workforce to maintain and extend their existing systems. I saw low engineering velocity slowing a business's ability to innovate to a crawl. My own very first startup caused countless sleepless nights and resulted in devastating personal financial losses, as well as years spent in an attempt to fix the early mistakes.

Anyone with experience in software engineering will readily explain this problem is hardly a new one. They may point you at the stats showing 70% of the software projects fail. They may also tell you of numerous books containing well-explained remedies, from reusable software design patterns to coding style guides. Yet, despite all the advice thats out there, the projects still fail in scores, and we are still surrounded by poorly constructed software the software that companies cannot improve, because every time they try, everything falls apart. And as complexity of the software grows, the problem gets worse.

What differentiates the failed projects from the successful ones? All successful projects had better architecture and better architecture comes from better software architects.

Great architects arent born. They are a product of decades of building real-life solutions and relentless learning. They become really good at their trade closer to the retirement age. But most startups are fostered by young entrepreneurs who dare to try but lack the experience. They also lack the $$ to hire a silver-haired architect to join their team from day one. Left to their own faculties, the entrepreneurs and their engineering teams quickly get on the path of learning from their own mistakes. Eventually they discover this is the most expensive way of learning. Over time they get better, and some become the true masters of the craft but way too late to make a difference for their early-day projects.