Introduction
— Chapter 0 —
Acknowledgements
I dedicate this book to two very special women in my life, my wife and my late grandmother.
Thank you, my love, for encouraging and supporting me to write this book. There would be no book without you.
Thank you grandma, for all your sacrifices to give me, my dad, and my uncle a great life we couldn’t have had without you.
My late grandma, Sefika Guler, was a daughter of Circassian refugees who built a new life for themselves after running away from their native land, Caucasus region, due to the Circassian Genocide.
She became a widow at a young age with her only child, my dad, and also took the responsibility of raising her late brother’s son. As a single mother, she worked as a tailor for decades to provide the best education opportunities she could to my dad and my uncle. Even though she went to school until 3rd grade herself, she managed to raise my dad to become a chemical engineer and my uncle to become an economist, who worked as the VP of the Turkish Central Bank in the mid 1980s.
She also raised me until the age of 18 and sent me off to the US to carry on my education in Atlanta, Georgia.
Special Thanks
My heartfelt thanks to Gregor Altvater, Markus Breitenbach, and Craig Wang for giving me their valuable time and challenging/honest feedback.
Warm thanks to Gan Khoon Lay for the stick figures that brought a spark of fun to my writings! Please find Gan’s work and more at: https://www.leremy.com/
Introduction
Users are generally over trusting of software. And that is a bad thing.
Because erroneously written software can actually be quite dangerous.
Most of us in the world seem to put a blind faith in technology. We readily share all our information on the internet, without giving any thoughts to our privacy. We take our cell phones everywhere with us. Those machines have the potential to listen to every one of our conversations, and even take pictures/videos without us noticing. We put trust in our home automation systems that can be easily hacked without proper security precautions. And now we are all looking forward to putting our trust in self-driving cars, which will be controlled by software alone, and not by a human being. And the list goes on.
It is a minor annoyance when the website goes down while we are watching cat videos. But software is not just web browsers or video players. Software is becoming a part of everything we use on a daily basis.
Software is already in the cars we drive, on the planes we fly, in the pacemakers some of us wear. It’s in the myriad of devices that we use in our everyday lives.
And when some of that software malfunctions for some reason, it might create severe consequences.
Software is going to get even more pervasive as we move into the future. We are going to find it in even more devices and things we use in our daily lives.
We really do not want to deal with the consequences of bad software. This means we genuinely should pay more attention to how we develop software.
Beyond the Best Practices
There are many best practices in designing and developing software: Clean coding and clean architecture design, necessary processes like CI/CD, code reviews, and testing. I have chapters dedicated to all of these in this book where I go in detail about what they mean and how they should be done.
However, after decades of being a software engineer, there is one important fact I came to realize: These best practices are not enough.
Software is developed by human beings. And as it turns out, the psychology of the people who build the software matter greatly when it comes to how well that software is built.
To give an example, an engineer could know all of these best practices by heart; on the other hand, if they are under immense deadline pressure, are heavily micromanaged, and have no meaningful incentives in their workplace, the software they produce will most likely end up being terrible.
When it comes to building software, management matters a lot. Not just the direct management of the people who build the software, but the management of the entire organization.
For these reasons, I have entire chapters dedicated to the criticisms of bad management practices alongside the suggestions to potentially resolve these issues. Putting deadline pressures, setting up detrimentally unnecessary software development processes, hiring, and incentivisation are among those topics. There is also an entire chapter about us, engineers, in this book. After all, it is only fair.
To be honest, a lot of these criticisms could apply to most of the corporations and organizations in the world. When you spend even a couple of minutes on an internet forum these days, you come across the same kind of complaints and issues that I raise in this book, coming from people who work in sectors that have nothing to do with the software industry. However, my focus is software here. As a software engineer, I can only write about the things that I know.
I must also mention that there are some criticisms in this book that apply uniquely to the software engineering world. To give one important example: There are tradeoffs in building software. Building quality software takes time and effort. Business people on the other hand might want to deliver a product quickly to the market in order to grab the market share. This means the software might need to be built in a hurry. While the delivered software might be functional, it could have some defects that are overlooked, or some bad designs which could be problematic later on in time. Badly designed software makes it more difficult to maintain and add new features to the codebase. This is what we call “technical debt”. For the time being, the management would just want to release the software to the market, and then address that technical debt later in the future.
However, there is the danger that the aforementioned “future” might never come. The technical debt might never get addressed. The management could just keep on demanding the building of newer and newer features within shorter and shorter deadlines, which would just add to the growing technical debt.
Bad software grows like an avalanche, and can get absolutely out of control. Technical debt can bring the failure of projects and entire organizations.
Software development has some quirks like that. In order to lead an organization that builds software, the management needs to be aware of these quirks. The best kind of management would be the one who has years of actual software development experience. (Although as I will also mention in this book, just engineering experience is not enough to be a good software manager. Other skills are also necessary.)
Even though I am writing this book from the point of view of a software engineer, I am making lots of statements about good management practices. In the end, I believe I am just making a commentary on how I would like to be managed as a software engineer. I know that nothing in life is perfect or ideal. But one can still hope.
There Will Always Be Bugs (And a Legal Disclaimer)
I am hoping that following the advice in this book is going to improve the software development practices and the quality of software at an organization, whatever that organization might be: A large corporation, a startup, a non-profit, etc. However, there is one thing I need to caution and make a legal disclaimer for, so to speak:
There is always going to be a chance that there are bugs and defects in any given software. Following the advice in this book is not going to give you any guarantees that your software is going to be defect-free.
In fact, it is one of the main points in this book that defending software quality is always an ongoing battle. Whenever software development is done, there is always a chance that some kind of bug or defect is introduced. It could be a simple bug in your code, or it could be a bad architectural decision which could have bad ramifications for your software development months or years down the line.
I always defend the viewpoint that at any given time, a percentage of the development efforts should be dedicated to paying down the technical debt by refactoring and improving the software. I will re-emphasize this point more in the coming chapters.
Yes, there are always going to be bugs. But then again, I hope (and only hope, not guarantee) that following the advice in this book is going to decrease the probability of some of these bugs from happening, and make your software development experience a more smooth and joyful one.
Who Am I To Tell You All This?
All of this brings the question of who am I to tell you all this, give you all this advice. I have worked as a software engineer spanning more than 20 years, the last 14 of which was in Silicon Valley. I worked at prominent software companies. Throughout my career, although I ended up staying on the technical track and not going into the management track, I did end up managing and mentoring many interns and new employees respectively. I led many projects, designed, and implemented many important software components. In the more recent years, I performed as a software architect.
It was my experiences in these companies I worked which taught me how to be a better software engineer. I learned a lot of good software design and implementation practices, all of which I will try to share with you in this book.
In this book, I share a lot of cautionary tales as well. Please keep in mind that for the majority of my professional life, I not only worked for a Silicon Valley company, I also lived in Silicon Valley. Almost all of my friends were (and still are) engineers, my neighbors were engineers. Even my barber there was an ex-engineer. I heard a lot of stories and cautionary tales about things that could derail software development. In this book, I also took some artistic license in telling these cautionary tales. I depicted events that could happen when dysfunction and incompetence are hypothetically taken to their ultimate logical conclusions. Which brings me to my second legal disclaimer:
Any characters, events, and depictions described in this book are a work of fiction and the products of the author's imagination. Any resemblance to actual persons, living or dead, or actual events is purely coincidental.
However, I believe that the cautionary tales I tell in this book are the ones that could really happen in real life. Some of them might have even already happened to some of you readers, and might resonate with you strongly.
What This Book Really Is
This book is ultimately an opinion piece. All of the points I raise in this book are my own opinions. If you are looking for a rigorous scientific study of the points I make in this book, you will be a bit disappointed.
But then again, the Agile methodology that has taken over the software development world today also seems to lack rigorous scientific study. The Agile Manifesto was written by a group of software engineers who came together and declared how software development should be done. The last time I checked, there were not so many scientific papers written about the validity of the various Agile practices. While I actually agree with some points of Agile, I disagree with and criticize some of its other claims. I have dedicated an entire chapter to this subject.
In the end, this book and the points that I’m trying to make here are just my observations and my thoughts. My purpose is to start a conversation about how to improve the software engineering field for the better. If I am presented with any good counter arguments and/or data that supports these opposing arguments, I am more than ready to change my opinions.
In this book, I am not only making criticisms about the way software is developed in today’s world, I am also making some suggestions to make improvements. I believe that one should not just blindly criticize, but should also make suggestions for better alternatives. Again, these are mostly my own opinions, and I hope to start a healthy discussion here.
I love being a software engineer and building products that people can benefit from. Ultimately, I have no control over how my products are actually used. However, I have control over how I design and develop my software. I have the power to push back the management if they want me to hurry up and write subpar code. They might consider me a nuisance, but over the years I have been vindicated many times for defending software quality.
And now I will try to introduce you to these various ways of defending software quality.