Recommended reads and videos of 2020

2020 hit hard on us and brought a lot of unexpected surprises: COVID-19 and burden on healthcare system, hard times for private business, especially for small-to-medium companies, restrictions, lockdowns and much more… On the other hand, a lot of companies and individuals changed the way how they work: in short terms remote work become as natural as it was going to the office in pre-Corona times. We got more time after all. We could dedicate it to our families and things we like to do most. From professional perspective, we could dedicate freed up time for online courses and readings. As for me, this year I started filling some gaps in certain areas like DevOps and Kubernetes, I discovered brilliant resources on Software Architecture and of course it was a year of deep dive to functional programming for me. Also I finally started my own blog, which you, my dear comrade are reading now. I would like to share with you my list of courses and readings which made up my year. Hope you will find it useful as well.

Righting Software by Juval Löwy

It doesn’t matter if you are experienced architect or just interested in Software Architecture, you definitely need to read that brilliant work. Author offers an idea of volatility based decomposition and compelling arguments to avoid functional and domain decompositions. The book is made up of two sections: one which describes The Method for System Design and one which describes the Project Design. System Design is all about technical implementation of volatility-based decomposition. It teaches you how to plan and split complex system into parts and create design which is flexible and maintainable for years of operation. Second part of the book gives you exhaustive knowledge on Project Design: how to plan project from the beginning to the final delivery. It covers staffing, cost planning, estimations and much more. What I found nice in the book is that author operates with very concrete examples and metrics, graphs and formulas. Everything in this book is concise, concrete and beautiful, however I should admit it is not something which is easy to read, you should have some background and experience with building software.

My verdict 9/10

The Pragmatic Programmer: 20th Anniversary Edition, 2nd Edition: Your Journey to Mastery by David Thomas and Andrew Hunt

20 years old classic revisited. All the main concepts described back in 1999 still valid in our field by current days. Authors made corrections to the current realities we live in like cloud computing and spread of microservices, but more important, they give invaluable advises on how to take responsibility on your own actions, how to develop your career, how to behave like Professional. This book reminds me another classic – The Clean Coder by Robert Martin, but I think it covers a bit wider range of aspects and from different angle. In my opinion it is a must read for every software engineer.

I have pleasure to listen to the audiobook version. Audiobook is organized as a series of sections, each containing a series of topics. It is read by Anna Katarina; Dave and Andy (and a few other folks) jump in every now and then to give their take on things.

My verdict 10/10

Release It!: Design and Deploy Production-Ready Software 2nd Edition by Michael Nygard

This book was published in the late 2018. I recommend this book for everyone somehow related to releasing software in production. It will save you years of try and learn in a hard way. Author already had all that experience and kindly shares it with us. You will understand typical problems with distributed systems. It touches a variety of different aspects like robustness of a system, security, versioning and much more. Very engaging book. As soon as you pick up this book, you will not put it down until you read it to the end. Also author had a great sense of humor, so the book is fun to read.

My verdict 9/10

F# From the Ground Up

F Sharp (programming language) - Wikipedia

Great course on Udemy by Kit Eason. Full of examples and quite interactive. Very good for beginners who wants to get grasp on functional programming and get practical experience.

The Art Of Code by Dylan Beattie

Glorious and hilarious talk on code from the perspective of an art. Dylan Beattie the author of the Rockstar programming language. The ending of the video is really epic 🙂

Where We’re Going, We Don’t Need Servers! by Sam Newman

Interesting talk by the author of Building Microservices books. Thoughts on where we are going and trends in cloud computing.

That’s it. Wish you all Merry Xmas and a Happy New Year 🎄🎅

Programming, Software design

Continuous refactoring

A son asked his father (a programmer) why the sun rises in the east, and sets in the west. His response? It works, don’t touch!

Fisrt rule of programming

How often you see software systems where adding new, relatively simple features takes ages, where it is hard to find the core logic or in which part of the system to apply changes? Does reading the code gives you a headache? Does any changes you need to introduce in that software makes you sick and you want to escape from that sinking ship? Well, unfortunately, you became a victim of a software rot.

Ivar Jacobson describes a software entropy as follows:

The second law of thermodynamics, in principle, states that a closed system‘s disorder cannot be reduced, it can only remain unchanged or increase. A measure of this disorder is entropy. This law also seems plausible for software systems; as a system is modified, its disorder, or entropy, tends to increase. This is known as software entropy

Ivar Jacobson

The Problem

In our daily work we too busy with adding new features as fast as possible and closing our tickets. Everyone is happy: the business sells features to customers, and we got paid, and if lucky, we even get some bonuses for that incredible performance. With time, however, software gets more complicated. You’re going to find out that adding more features takes longer and produces more bugs. This tends to grow very quickly and ends in a system which extremely hard and expensive to maintain.

Perhaps you heard of a term Technical Debt? It describes collective debt you owe to your software by doing some shortcuts when implementing some feature because you didn’t have time to do it properly. It could be on any level from overall software design to the low-level implementation. But it is a very optimistic term – it assumes that this debt will be paid off which we all know almost never happen. I prefer to think about it as a Software Rot actually and the whole practice which leads to that as a Shortcut-Driven-Development.

I think many companies just don’t realize what are the costs of maintenance of a poorly built software. But hey, wouldn’t it be nice if we can show and prove this mathematically? So that you will have strong arguments in your discussions with product owners and managers regarding the need of refactoring. Once upon a time, while I was reading Code Simplicity: The Fundamentals of Software , I reached chapter which describes the equitation of software design and it has brilliant math representation of that equation:

D = (Pv * Vi) / (Ei + Em)

Or in English:

The Desirability of Implementation is directly proportional to the Probability of Value and the Potential Value of Implementation, and inversely proportional to the total effort, consisting of the Effort of Implementation plus the Effort of Maintenance.

However, there is a critical factor missing from the simple form of this equation: time. What we actually want to know is the limit of this equation as time approaches infinity, and that gives us the true Desirability of Implementation. So let’s look at this from a logical standpoint:

The Effort of Implementation is a one-time cost, and never changes, so is mostly unaffected by time.

The Value of Implementation may increase or decrease over time, depending on the feature. It’s not predictable, and so we can assume for the sake of this equation that it is a static value that does not change with time (though if that’s not the case in your situation, keep this factor in mind as well). One could even consider that the Effort of Maintenance is actually “the effort required to maintain this exact level of Value,” so that the Value would indeed remain totally fixed over time.

The Probability of Value, being a probability, approaches 1 (100%) as time goes to infinity.

The Effort of Maintenance, being based on time, approaches infinity as time goes to infinity. What this equation actually tells us is that the most important factors to balance, in terms of time, are probability of value vs. effort of maintenance. If the probability of value is high and the effort of maintenance is low, the desirability is then dependent only upon the Potential Value of Implementation vs. the Effort of Implementation–a decision that a product manager can easily make. If the probability of value is low and the effort of maintenance is high, the only justification for implementation would be a near-infinite Potential Value of Implementation.

The Solution

Let’s take a look at definition of refactoring given by Martin Fowler:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of these transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is kept fully working after each refactoring, reducing the chances that a system can get seriously broken during the restructuring.

Keeping software systems in good order requires developer teams to follow strong practices. But first of all it is your personal responsibility and should be in your culture. Continuous Refactoring is a key factor in that sense. You should refactor and improve your code on a day-to-day basis. Plan this work if you need to, explain the importance of it to the managers and product owners. You should become refactoring machines. This is not only tremendously reduce the denominator part of equation (Em), but also will force you to protect your code from breaking by implementing all kind of testing , one of which is regression testing. Each bit of refactoring will make your code better and easier to extend with new functionality. Gradually, you can switch from Shortcut-Driven-Development to Software Engineering and enjoy from what you are doing and helping business to survive in the long run.

The Mantra

Mantra for TDD followers