Foreword

I started writing on www.codesimplicity.com in 2008 for one reason only – I wanted to make the world of software development a better place. I wasn't trying to be famous, or get contracting jobs, or push some ideology on people. My intention was purely to help people.

What I had observed was that there was a lot of opinion in the field of software engineering, but not a lot of facts or basic principles. Now, this might seem like a shocking statement to some people, because surely software development is a scientific field where we all know exactly what we're doing – we work with highly technical machines and we use a lot of complex systems to accomplish our jobs. There must be a science to it, right?

Well, the problem is that in order to be a science you must have laws and a system of organized information based on those laws. Usually, you also must demonstrate that your laws and your system actually work without exception in the physical universe. It's not sufficient to just have some information about technology. You must have basic principles.

There are many ways to derive these basic principles. The most popular and accepted way is through the scientific method. There are other ways, too. The whole subject of how you discover these things is covered by a study called "epistemology," which is a word that means "the study of how knowledge is known." For example, you know your name. How do you know that that is your name? How do you know that's true? If you wanted to understand how to build a house, what would you do to gain that knowledge? And so on.

I'm sort of over-simplifying it, and perhaps some philosophy professors will come after me and write bad reviews because I'm not really explaining epistemology or how I used it, but I hope that what I've written here is enough for the common reader to get that what I wanted was some method that would lead to the development of basic principles. Various methods of epistemology, including the scientific method, helped me discover these.

My first book, Code Simplicity, is a description of those basic principles of software development. But there's more to know than just those basics. True, you could derive everything there is to know about software design from those laws in Code Simplicity, but since I've already derived a lot of stuff from them, why not just share that with you now?

This book is a collection of my writings since Code Simplicity, as well as some additional content that I wrote before Code Simplicity but which didn't really fit in that book. Most of the content in this book is also on my website, but in this book it's been organized, curated, and edited for maximum readability. Also, you get to read it in book format, which is often easier to digest and understand.

There is one chapter in the book that is not on my website and never will be – the one called "Excellent Software." I actually wrote it years ago as part of the first draft of Code Simplicity, but could never bring myself to give it away for free.

The book doesn't have to be read in order. It's designed so that it reads nicely if you go from page to page and read each section in sequence, but you can also skip around and read any of the sections you want if you think some part will be more interesting than another.

To help both kinds of readers, I've split the book into a few parts. That way, people reading in order get a consistent flow, and people who want to skip around know what each part covers.

The first three parts of the book cover some foundational principles of being a programmer and then get into aspects of software complexity and simplicity. After that comes "Engineering in Teams," a whole new set of principles developed since Code Simplicity based on my experience successfully applying the principles of Code Simplicity across large engineering organizations.

Then comes a section where I write about the philosophy behind the principles of software design, "Understanding Software." This includes the article "The Philosophy of Testing," which is a more thorough coverage of the basic principles of testing than was found in my first book.

Then comes the section "Suck Less," based on one of my most popular blog articles of all time. It starts off explaining why "Suck Less" works as a philosophy for product management in software development, and then goes on to talk about how you can make your software suck less and specific ways to become a better programmer yourself.

Overall, the whole point of the book is to help you be a better software developer, and that is the only point. I would much rather live in a world where software is simple, well-designed, reliable, fast, and easy to make, wouldn't you? In this book and Code Simplicity, I've told you how to do it – all you have to do is apply the data that I've given you.

Best of luck.

Max Kanat-Alexander

August 2017