What do you think?
Rate this book
Code Simplicity: The Fundamentals of Software
Every complexity of software design, simplified and codified at last, for use by every programmer, from the novice to the architects of major applications. This book contains the fundamental laws of software development, the primary pieces of understanding that make the difference between a mid-level/junior programmer and the high-level senior software engineer. The book exists to help all programmers understand the process of writing software, on a very fundamental level that can be applied to any programming language or project, from here into eternity. Code Simplicity is also written in such a way that even non-technical managers of software teams can gain an understanding of what the “right way” and the “wrong way” is (and why they are right and wrong) when it comes to software design. The focus of the book is primarily on “software design,” the process of creating a plan for a software project and making technical decisions about the pattern and structure of a system.
80 pages, Paperback
First published January 1, 2012
97 people are currently reading
956 people want to read
About the author
Max Kanat-Alexander
2 books21 followersMax is a Senior Software Engineer at Google and former Chief Architect of the Bugzilla Project. He has been fixing computers since he was eight years old and writing software since he was fourteen. He is the author of http://www.codesimplicity.com/ and http://www.fedorafaq.org/, and is currently living in Northern California.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 109 reviews
August 11, 2014
I wish every programmer read this book.
It's a very short (~70 pages) book on the mindset needed for simple and maintainable code. The author sets to coin a few universal laws and rules for software development. He does great in my opinion. It's full of very good advice. It might be "common sense" for some, but it's also the kind of common sense that people agree on, but then never do. I can easily say that everything in that book is (1) very true and (2) very relevant.
I can wholeheartedly recommend it. Even if you're familiar with the ideas, the brevity and clarify of expression are very refreshing and make the book a pleasant read.
It's a very short (~70 pages) book on the mindset needed for simple and maintainable code. The author sets to coin a few universal laws and rules for software development. He does great in my opinion. It's full of very good advice. It might be "common sense" for some, but it's also the kind of common sense that people agree on, but then never do. I can easily say that everything in that book is (1) very true and (2) very relevant.
I can wholeheartedly recommend it. Even if you're familiar with the ideas, the brevity and clarify of expression are very refreshing and make the book a pleasant read.
Read
November 19, 2019A must read books for every software engineer or wannabe software engineers. The advice in the book is general enough to benefit any professional pursuing their careers in any field and who aspire to be the best at what they do. Loved it!
May 25, 2020
So many of the reviews are critical but end with a statement that it would be good for new developers. I do think that new developers and others missing fundamentals are the target audience so I gave it 5 stars. It does what it intends to do and does it well.
November 18, 2019
For a software engineer of any level, this book has a lot of GREAT ideas to make your code more readable and maintainable. I wish I had DISCOVERED it earlier.
October 10, 2013
[Code Simplicity: The Fundamentals of Software](http://shop.oreilly.com/product/06369...) by [Max Kanat-Alexander](http://max.kanat-alexander.com/) is crisp book about writing better software.
The book is just 88 pages, but insights are useful for any software engineer. Author is creator of bugzilla project.
Whenever I come across bold statements in the book, I would sit and think for 2 minutes to corelate with my programming experience. Most of the time I was able to come up with valid example.
This book is highly recommended for programmers who had spent significant time reading other programmers code. If you are an experienced programmer you can consider the points in the books as to validate your current beliefs. I tend to agree on all of the points mentioned in the book and corelate with open source projects in postive and negative sense.
Few of my favorites:
- Everybody who writes software is designer.
- Design is not democracy. Decisions should be made by individuals.
- There is something about future you don't know.
- Be only as generic as you know you need to be right now.
Rating: ****
The book is just 88 pages, but insights are useful for any software engineer. Author is creator of bugzilla project.
Whenever I come across bold statements in the book, I would sit and think for 2 minutes to corelate with my programming experience. Most of the time I was able to come up with valid example.
This book is highly recommended for programmers who had spent significant time reading other programmers code. If you are an experienced programmer you can consider the points in the books as to validate your current beliefs. I tend to agree on all of the points mentioned in the book and corelate with open source projects in postive and negative sense.
Few of my favorites:
- Everybody who writes software is designer.
- Design is not democracy. Decisions should be made by individuals.
- There is something about future you don't know.
- Be only as generic as you know you need to be right now.
Rating: ****
April 26, 2012
Code Simplicity by Max Kanat-Alexander (published by O'Reilly, 2012) is the kind of book you might give to a junior or journeyman programmer and say: "Read this over the weekend, and then on Monday we'll talk about your design." There are many quotable passages, pithy aphorisms, and axioms that take the form of definitions, facts, rules, and laws. Kanat-Alexander uses a conversational tone that takes this already common-sense study on the subject and makes it even more approachable and straightforward. And just what is the subject here? As the title dictates, the subject of the book is code simplicity: dealing with complexity, identifying areas where complexity is likely to creep in, and strategies for eliminating or reducing that complexity.
At a high level, Kanat-Alexander's discussions of the component parts of this subject are deft and lucid. He is able to evoke familiar situations and scenarios (e.g., coding under a deadline; e.g., dealing with large legacy code bases) and uses those to frame and present his recommended methodologies for keeping code "simple". A lot of the techniques and suggestions will all seem like common sense to anyone who has been programming for a non-trivial interval: reduce maintenance effort before trying to reduce implementation effort; the larger your change, the more likely you are to break something; don't "fix" things unless you know that you have (and have evidence of) a problem -- and so on. Again, to experienced programmers (and, arguably, also to someone who has just sat in on 4+ years worth of computer science lectures?) these suggestions will all seem like conventional wisdom, like the elements of craftsmanship that they perform and preach every day. To those programmers, I say: Give it a whirl for the sake of the reminder, and if nothing else, at least be familiar with it so you'll know whether it is a good tract to hand out to your young and eager recruits.
Again, the book has a conversational style and is filled with pithy aphorisms and witticisms that make it easy to absorb and retain Kanat-Alexander's message. I found myself frequently transcribing passages into my notebook for later reference and for sharing with peers. Many stand out, but two in particular that I wanted to share. First:
I felt this was worth calling out because it was highly illustrative, and emblematic of the theme. Every programmer has had in-depth discussions about comments; and every programmer has committed code that should have been commented, and wasn't; and every programmer has committed code that was commented unnecessarily; etc. This is something that we've all done, and that we'll all do again. Thus, it is easy to identify with the message embedded in this lesson. But what makes it particularly demonstrative of the book's theme is that Kanat-Alexander is trying to teach you first how to do without the comments. "If it isn’t obvious, the code should be made simpler. Only if you can’t make code simpler should you have a comment explaining what it does." And yes, he does immediately go on (in the next paragraph) to state that comments are really more about capturing the ephemeral why of a piece of code, but again the message remains: Consider first what you may add in value by taking away what is written and committed. [1]
Kanat-Alexander's take on the comments is interesting one to me because it underscores the book's message about taking the time to engage with the code, to execute on thoughtful designs, and to take the time to understand what you're "doing" -- the problem you're trying to solve, the technologies that you've chosen to use, the sacrifices that you're making by choosing one approach instead of another, etc. He talks quite a bit about understanding, about taking the time to read and fully comprehend code before changing it; about taking the time to engage with the problem space and design a solution instead of simply stabbing at one. [3] Not taking the time to arrive at that understanding is (he asserts) a disastrous source of recursive complexity:
Which reminds me of a joke we have going at the office:
But this is a point which seems to prove itself: that "of course if you don't understand [the problem domain / the programming language / the library / the requirements / the legacy code / the customers / etc.] then of course you're just going to create an at-best mistake-riddled solution." And to those "experienced programmers" out there, stroking your beards and condescendingly shaking your heads with your unspoken "I told you so": I've seen you do it, too.
As for Code Simplicity itself: I do not actually have all that much in the way of critique. As I have said, it is a short text, pithy and aphorismic -- but this is indicative that it has accomplished its goal. So what would I have liked to see, or see more of? First off, there is effectively no code presented at all; not that Kanat-Alexander promises us any -- just the opposite, he eschews code to drive home the philosophical points. Perhaps specific code examples would detract from that -- but there is a part of me that would liked to have seen something concrete in this area. My other nit to pick was that the book's sub-heading is "The Science of Software Development", and though Kanat-Alexander presents things as "facts" and "laws", I didn't exactly see... science. I read a lot of anecdotes, but I didn't see too many experiments of empirical methods. Given Kanat-Alexander's pedigree, and given the common-sense nature of so much of the advice contained in the book, I'll grant him a pass on this -- but I cannot in good conscience call it all scientific, even if I find myself vigorously agreeing with (say...) 99% of it.
So where do I land on this one? I'd heartily recommend it to any junior or journeyman programmer that is looking for some insights into how to improve their craft and how to cultivate simplicity in their designs. I know I'll likely be recommending it to folks that I mentor in the future -- again: as a quick weekend read, but with the caveat that you'll want to keep a notebook and jot down those really good parts.
---
[1] Which of course immediately brings to mind this quote: «The more code I write, the more code I get wrong. Therefore, it behooves me to write as little code as possible.» ...which I saw tweeted by @al3x, and is attributed to "Pony" in a piece called "Why Haskell?" and/but the original source link has 404ed for as long as I've known about it.
[2] #refactoringleadstomoreanger - source.
[3] It is worth noting that there is a tacit acknowledgment in the text that you cannot "waterfall" your way through designing your solution. He doesn't come right out and use that phrase, nor does he come out and admit that Agile-style rapid iterations are the way to go either. That isn't the subject of the book, and he is wise to stay away from "going there" -- but it's in there, at least a little bit. (No one could help that.)
At a high level, Kanat-Alexander's discussions of the component parts of this subject are deft and lucid. He is able to evoke familiar situations and scenarios (e.g., coding under a deadline; e.g., dealing with large legacy code bases) and uses those to frame and present his recommended methodologies for keeping code "simple". A lot of the techniques and suggestions will all seem like common sense to anyone who has been programming for a non-trivial interval: reduce maintenance effort before trying to reduce implementation effort; the larger your change, the more likely you are to break something; don't "fix" things unless you know that you have (and have evidence of) a problem -- and so on. Again, to experienced programmers (and, arguably, also to someone who has just sat in on 4+ years worth of computer science lectures?) these suggestions will all seem like conventional wisdom, like the elements of craftsmanship that they perform and preach every day. To those programmers, I say: Give it a whirl for the sake of the reminder, and if nothing else, at least be familiar with it so you'll know whether it is a good tract to hand out to your young and eager recruits.
Again, the book has a conversational style and is filled with pithy aphorisms and witticisms that make it easy to absorb and retain Kanat-Alexander's message. I found myself frequently transcribing passages into my notebook for later reference and for sharing with peers. Many stand out, but two in particular that I wanted to share. First:
Having good comments in code is a big part of making it readable. However, you generally should not add comments that say what a piece of code is doing. That should be obvious from reading the code. If it isn’t obvious, the code should be made simpler. Only if you can’t make code simpler should you have a comment explaining what it does.
I felt this was worth calling out because it was highly illustrative, and emblematic of the theme. Every programmer has had in-depth discussions about comments; and every programmer has committed code that should have been commented, and wasn't; and every programmer has committed code that was commented unnecessarily; etc. This is something that we've all done, and that we'll all do again. Thus, it is easy to identify with the message embedded in this lesson. But what makes it particularly demonstrative of the book's theme is that Kanat-Alexander is trying to teach you first how to do without the comments. "If it isn’t obvious, the code should be made simpler. Only if you can’t make code simpler should you have a comment explaining what it does." And yes, he does immediately go on (in the next paragraph) to state that comments are really more about capturing the ephemeral why of a piece of code, but again the message remains: Consider first what you may add in value by taking away what is written and committed. [1]
Kanat-Alexander's take on the comments is interesting one to me because it underscores the book's message about taking the time to engage with the code, to execute on thoughtful designs, and to take the time to understand what you're "doing" -- the problem you're trying to solve, the technologies that you've chosen to use, the sacrifices that you're making by choosing one approach instead of another, etc. He talks quite a bit about understanding, about taking the time to read and fully comprehend code before changing it; about taking the time to engage with the problem space and design a solution instead of simply stabbing at one. [3] Not taking the time to arrive at that understanding is (he asserts) a disastrous source of recursive complexity:
Programmers who don’t fully understand their work tend to develop complex systems. It can become a vicious cycle: misunderstanding leads to complexity, which leads to further misunderstanding, and so on.
Which reminds me of a joke we have going at the office:
Anger leads to hate. Hate leads to suffering. Suffering leads to re-factoring. [2]
But this is a point which seems to prove itself: that "of course if you don't understand [the problem domain / the programming language / the library / the requirements / the legacy code / the customers / etc.] then of course you're just going to create an at-best mistake-riddled solution." And to those "experienced programmers" out there, stroking your beards and condescendingly shaking your heads with your unspoken "I told you so": I've seen you do it, too.
As for Code Simplicity itself: I do not actually have all that much in the way of critique. As I have said, it is a short text, pithy and aphorismic -- but this is indicative that it has accomplished its goal. So what would I have liked to see, or see more of? First off, there is effectively no code presented at all; not that Kanat-Alexander promises us any -- just the opposite, he eschews code to drive home the philosophical points. Perhaps specific code examples would detract from that -- but there is a part of me that would liked to have seen something concrete in this area. My other nit to pick was that the book's sub-heading is "The Science of Software Development", and though Kanat-Alexander presents things as "facts" and "laws", I didn't exactly see... science. I read a lot of anecdotes, but I didn't see too many experiments of empirical methods. Given Kanat-Alexander's pedigree, and given the common-sense nature of so much of the advice contained in the book, I'll grant him a pass on this -- but I cannot in good conscience call it all scientific, even if I find myself vigorously agreeing with (say...) 99% of it.
So where do I land on this one? I'd heartily recommend it to any junior or journeyman programmer that is looking for some insights into how to improve their craft and how to cultivate simplicity in their designs. I know I'll likely be recommending it to folks that I mentor in the future -- again: as a quick weekend read, but with the caveat that you'll want to keep a notebook and jot down those really good parts.
---
[1] Which of course immediately brings to mind this quote: «The more code I write, the more code I get wrong. Therefore, it behooves me to write as little code as possible.» ...which I saw tweeted by @al3x, and is attributed to "Pony" in a piece called "Why Haskell?" and/but the original source link has 404ed for as long as I've known about it.
[2] #refactoringleadstomoreanger - source.
[3] It is worth noting that there is a tacit acknowledgment in the text that you cannot "waterfall" your way through designing your solution. He doesn't come right out and use that phrase, nor does he come out and admit that Agile-style rapid iterations are the way to go either. That isn't the subject of the book, and he is wise to stay away from "going there" -- but it's in there, at least a little bit. (No one could help that.)
April 18, 2012
The books deals with Software development mostly with the design of the software. Though the "science" part of it isn't really science, because it all boils down to the individual and how they interpret the so called laws. If you are beginner in software design, then this would be a good read as it doesnt deal with the topics in depth and hence its redundant information for an experienced developer.
Another motivation for someone to read would be its small size, you can read it end-to-end in one sitting.
Another motivation for someone to read would be its small size, you can read it end-to-end in one sitting.
August 9, 2019
I was always saying: If the developer will read one and only one book in software development, it should be "Clean Code" by Uncle Bob. Now I am saying, he should read "Code Simplicity" first, then follow up with "Clean Code". I am saying that for 2 reasons:
1. If it is correct, I would say that "Code Simplicity" installs the correct mindset, then "Clean Code" will come with the details.
2. "Code Simplicity" is is short enough to read end-to-end in a single sit; it is just less than 90 pages.
1. If it is correct, I would say that "Code Simplicity" installs the correct mindset, then "Clean Code" will come with the details.
2. "Code Simplicity" is is short enough to read end-to-end in a single sit; it is just less than 90 pages.
November 29, 2018
El libro ideal para leer después de haber comenzado a programar, te da las herramientas mentales y metodológicas para acercarte más a un ingeniero y no a un artesano.
Read
October 25, 2021An inspiring book about code simplicity, if you are looking for motivation on make programming simpler might this book fits for you. Full of empirical rules and laws extracted from author's experience, these philosophical lessons could help you make coding simpler through reflections.
March 4, 2021
As harsh as it sounds, this book should never have been written. The author makes a bunch of assertions like "write code that is simple" and "you can't know the future". But there is nothing to back those up, no additional context, examples, or explanation. No steps for how to write better code. The tone throughout is "just stop writing bad code, come on guys, let's write good code". Yeah, it's so easy when you write good code instead of bad code, just write the good code and you won't have any bad code! This book is so utterly unhelpful, I cannot fathom how the author thought this short book would be helpful to anyone. Which is sad because it sounds like the author was part of a team that cleaned up a significantly messy codebase, but instead of talking about real world examples and that experience, we just get a bunch of zen-master truisms that are totally devoid of value.
December 19, 2014
Great explanation of why software and it's design must have a simple purpose.
The book is short, but complete. It doesn’t touch on “how” to abide to the rules it sets and focuses on the “why”, instead.
The language is clean and to the point. Most of the examples are practical enough, only a few too vague.
I love that the content wasn’t buried in a blog post and at the same time I love the author kept the book very very short (70 pages).
Before saying it’s all common sense, give it few minutes to appreciate that it’s all of the knowledge about why we need simpler designs and purposes in one place. And take few minutes to look through your experience and find better examples than those in the book.
The book is short, but complete. It doesn’t touch on “how” to abide to the rules it sets and focuses on the “why”, instead.
The language is clean and to the point. Most of the examples are practical enough, only a few too vague.
I love that the content wasn’t buried in a blog post and at the same time I love the author kept the book very very short (70 pages).
Before saying it’s all common sense, give it few minutes to appreciate that it’s all of the knowledge about why we need simpler designs and purposes in one place. And take few minutes to look through your experience and find better examples than those in the book.
February 29, 2016
Many books, totaling thousands of pages, teach the mechanics of creating "good" code. This is the first book I've read that speaks of the underlying principles behind all the others. Simplicity. That is it. A one word answer to the age old question of what makes great software. Max Kanat-Alexander distills years of experience into six laws of software. Like Asimov's Three Laws of Robotics (http://en.wikipedia.org/wiki/Three_La...) or WWJD (http://en.wikipedia.org/wiki/WWJD%3F) they form a foundation for making the myriad design decisions software developers face every day.
At only 81 pages, lack of time is no excuse for not reading this book.
At only 81 pages, lack of time is no excuse for not reading this book.
January 30, 2013
The author is chief architect of some software project, yet the examples he gives here feels as if he had never written a line of code in his life. I learnt very few thing from this book, but all other stuff are more or less common sense.
August 7, 2015
A short list of rules, facts, and laws for software design. They are so universal and logical that it's hard to disagree with anything written and examples what happens when people violate them are everywhere around us.
May 3, 2017
I think this is a great book for developers of any level. In times where we are overwhelmed by new technologies, patterns, tools and frameworks, this book steps back to the most important part of software development: design.
November 16, 2018
Favorite quote: "The difference between a bad programmer and a good programmer is understanding. That is, bad programmers don’t understand what they are doing, and good programmers do."
Philosophical version of Clean Code. Good & light read, it's shorter than I expected. Easy to finish.
Philosophical version of Clean Code. Good & light read, it's shorter than I expected. Easy to finish.
August 4, 2018
On the second reading, I can say that I 100% agree with this book.
August 31, 2018
Why has there been no Science of Software Design?
This book gives some answers and tries to make real fundamentals for software design.
Worth reading .
This book gives some answers and tries to make real fundamentals for software design.
Worth reading .
July 30, 2021
I wasn't able to read the hole book, it's full of opinionated ideas and never refers to other authors or ideas to make them valuable, and worst, I've read the worst advise given to Senior developers and is that they should take code written by more juniors dev and write them to teach them how that must be done. it just loose me totally there.
January 29, 2023
Good, easy to read book with nice recommendations for writing software that is easily updatable and transferrable. It's very short and informative so I would recommended to anyone writing software. It feels a bit dogmatic at times but the laws proposed are logical consequences of wanting to have code whose simplicity enables its maintenance and longevity.
December 10, 2019
An easy, digestible book to understand principles of Software Engineering. Perhaps this would serve as an introduction to Software Engineers.
Outline:
1.Introduction
2.The Missing Science
3.Driving Force of Software Design
4.Future
5.Change
6.Defet and Design
7.Simplicity
8.Complexity
9.Testing
0 Laws of Software Design
Chapter 1:
The difference between bad programmer and good programmer is understanding. Why do computers break? They break a lot, a lot. It’s due to bad programming. But what is this root cause? It boils down to complexity.
We’d need programming to reduce complexity. Art in programming - reducing complexity into simplicity.
A good programmer needs to do everything in his power to make what he writes as simple as possible to other programmers. A good programmer creates things that are easy to understand.
A Program is sequence of instructions given to the computer, it’s the actions taken by a computer as a result of being given instructions. Improving the code, improves quality of software. It’s one of the most important problem we’d need to solve.
Chapter 2: Missing Science
The Author writes that this book is about Software Design. We know what a software is about, it’s about a set of instructions to achieve many functions. What would be Software Design?
Design is to make a plan for creation, in this case, we are planning in advance about the software. This would involve, tools, structure of code, technical decisions.
A Code that exists also has a design, in which structure or the plan that seems to follow. We’d need to ask questions like:
-What should the structure of our program code be?
-Is it more important to focus on having a fast program or a program whose code is easy to read?
-In this software design, which programming language should we use?
To make it concise, I’d say — anything that involves architecture of the software, technical decision while creating the system falls within the purview of software design.
We’d need to know that every programmer is a designer. Usually, the lead developer is in-charge of designing overall architecture of entire program. “Every programmer who writes a software is a designer.”
Can we say Software design is a science? The easiest answer is no, let’s look at why it is not a science:
- Science must contain knowledge that has to be collected
- This knowledge must have a way to be organized
- It ought to contain basic laws or general truths
- It also needs to tell how to do something in physical universe
- As far as we know, science is discovered through scientific method, which involves observation and experimentation
Let’s look at the fundamental laws of software design:
-Definitions tell you what something is and how you would use it
-Facts are true statements about something
-Rules are statements that give advice over something
-Laws are facts that always be true and cover a broad area of knowledge
In the above, laws are the most important. How does this book help us? It’s teaching us the science of software design (we think it is a science or assume to be), very few people are taught the software design process, instead they are taught a programming language and then asked to write some software. This book is filling the gaps between them.
Chapter 3: Driving Forces of Software Design:
Every time we write a software, we’d need to know exactly what the purpose of the software and why we are crafting the software. If we analyze it deeper, the single purpose of all software is to, “Help People.” If we break this purpose, we can understand it concretely:
Some specific pieces of software exists to help specific groups of people. A word process exists to write things. A Web browser exists to help people browse the web. The author says, purpose of software is not to make money or to show of how intelligent a person has become. It would violate principle of purpose in software, and lead to low-quality software. When we are given feature requests, we’d have to think, which feature would help the most number of people.
The author backs up his statement of purpose of a software is not to make money through expanding it. He says, to make money would be a personal purpose or purpose of an organization, but it ought not to be the case of the software. The two main primary factors that determine the income of software company is probably, the business skill and how much your software helps people. Business skill involves administration, management, marketing and sales.
Let’s summarize from the above paragraphs about purpose of software. We do know that, the goal of software is to help people. To be specific, the following points should be considered:
1) To allow us to write software that is as helpful as possible
2) To allow our software to continue to be as helpful as possible
3) To design systems that can be created and painted as easily as possible by their programmers, so that they can be and continue to be as helpful as possible.
Chapter 4: Future
An important question that faces every software designer is, how do I make decisions about my software and which decision would be the best? To rephrase this question, given possible decisions, which of those decisions are best out of all possibilities.
D = V/E,
D stands for desirability of change
V stands for value of change
E stands for the effort involved in performed the change.
Essentially, it says any change is directly proportional to value of change and inversely proportional to effort involved in making change. Value here means the degree to which this change helps anybody anywhere. It adds financial support to your own self as adding value. Value could be potential value and probability of value. In the above equation, we miss one important component, time. Features within a software change in value over time. If we include time and other attributes, then it becomes:
D = Vn + Vf / Ei + Em
Where Vf is value in future, Vn is value now. Ei effort of implementation, Em its effort of maintenance. We don’t want a situation where effort is $100k and value is $0.10, We’d want the opposite way, where effort is $10 and value is $100k.
The idea solution for guarantee success is to design our system in such a way that maintenance decreases over time, eventually becomes zero. In short, it’s important to reduce effort of maintenance than it is to reduce effort of implementation.
It’s easy to write software that helps one person right now, but it’s difficult to write software that would help millions of people now and to continue that in the future. If we just make things work in the present, then our software becomes hard to maintain in the future. Sometimes we are safest if we don’t assume to predict the future, but make design decisions with the information present now.
Chapter 5: Change
We know that the longer our software exists, the more probable it is that any piece of it will have to change. The common mistakes that software designers make when coping with change:
-Writing code that isn’t needed
-Not making the code easy to change
-Being too generic
We don’t write code that we do not need it. Un-used code clogs the system. Code should be designed based on what you know now, not on what you think will happen in the future. Being too generic in the design doesn’t help users
Chapter 6: Defects and Design:
Good programmers introduce one defect into a program for every 100 lines of code. The best programmers introduce for every 1000 lines of code. The chance of introducing a defect into your program is proportional to the size of changes you make to it. So if we have smaller changes, we have fewer defects and less maintenance.
The best design is one that allows for the most change in environment with least change in software.
“Never fix anything unless it’s a problem and you have evidence showing that the problem really exists.”
Don’t repeat yourself, this means that in your software system, any piece of information should ideally exist only once. We should not be copying/paste blocks of code, instead we allow one piece of code to call others. This helps us in making changes, if we make changes in one piece of coding, then it will automatically change in other aspects of the software system.
Chapter 7: Simplicity
The ease of maintenance in any piece of software is proportional to simplicity of its individual pieces. We cannot have perfect ease of maintenance, but it’s the goal we strive for in our system. Remember this doesn’t apply to whole system but only individual pieces. An average human being cannot comprehend whole pieces of the software. He can only comprehend pieces of it. The simpler each pieces of the software is, the easier to maintain.
We’d need to write code in simple, self-contained pieces where fixing defects and maintaining the system is easy. If we design a large, complex chunk, then each piece of work doesn’t get polish as much but it’s harder to maintain. However simple is relative, what we write as simple would be simple to us but not simple for our co-workers or customers. Always write good documentation that starts with, “New to this code?” So that a person who has no understanding can read your code. The worst of all is a software with no documentation, where you are just expected to figure out for yourself, or already know, how the code works. We’d need our code to be simple, in this case, stupid and dumb simple. What this means is when other programmers look at your code, do you want them to feel frustrated and angry or confused and frustrated? In addition to keeping it simple, being consistent in the code is important. Finally some other things that add to simplicity is readability that includes spacing, naming things so other programmers can understand the code, commenting it.
If we don’t pay attention in designing a system, it evolves into a massive, complicated beast. Sometimes when we design it, which takes more time, a lot of credit might not come in our way. If you think about design, your users and fellow developers will see benefits, working software, on-time released and a clear understandable code-base.
Chapter 8: Complexity
This is a common story in big projects. Someone working on a project would say, we were working on a project few years ago and this technology we were using was modern back then but it’s obsolete now. We can’t develop fast enough to keep up with modern user needs or while we were developing company x wrote a product better than ours much more quickly than we did.
If we think about this issue, what’s the source of this problem? Complexity. We start with a simple project that takes a month, but when we add complexity, it takes three months, if we add more, it takes nine months. Complexity builds upon complexity. In the first release, we don’t shoot for the moon, we start with something that works and doable. Adding Features is one way to add complexity to the software. Here are the most common ways:
1) Expanding the purpose of software
2) Adding Programmers
3) Changing things that don’t need to be changed
4) Being locked into bad technologies
5) Misunderstanding
6) Poor Design or no design
7) Reinventing the wheel, the only time we invent a wheel is when we need something that doesn’t exist, all of existing technologies are bad and will lock us in, existing wheels are incapable of meeting our needs, they aren’t properly maintained.
We add all these, we get, “Never-Shipping” Product.
If our purpose of our software is to help users write, but then we add some other purpose to it, then it gets very complex quickly. The purpose of word processor is to help us write things. A user needs to understand the purpose of the software, he wants a purpose behind it like to help doing taxes. To make a user get angry, make it difficult for the user to accomplish their purpose. Sometimes marketing, sales would bring up purpose of a software is to be cool, edgy design, become popular but we’d need a technical director or software designer to take the responsibility of this. Users are happiest with a focused, simple product that never violates, it’s basic purpose. A Technology’s survived potential is linked with maintainability. To have a sense of it’s survivability, look at the recent release library. Another attribute is interoperability which is the ability to switch away from a technology if you have to decide with another technology.
We’d have to ask, what problems are we trying to solve? We should ask the question, how in general, in a perfect world, should this sort of problem be solved? We don’t ask, how does Professor Anne solve this in her program or how do I solve this using my code.
In order to handle complexity, we can redesign a system that is too complex into smaller steps. If it’s too complex, it will take a lot of effort and time, but we’d need to conceive of a system that is simpler than what we have now, but it’s important to keep releasing new features. Unless we do this, we won’t be keeping up with the amount of change. One of the best ways to handle writing features and complexity is to do our redesigning purely with goal of making some specific feature easier to implement and then implementing that feature. It’s helpful to know multiple programming languages, and be familiar with many different libraries, because it involves different ways of thinking about problems.
Chapter 9: Testing:
I believe that every software developer has faced this, the software is running now, there is no certainty that it will run in the future. The degree to which you know how your software behaves is the degree to which you have accurately tested it.
When we say, it works, it’s vague. We should rather test our software so that it behaves in the way we intended it to be. We have to know what behavior we intended it to be.
Unless we have tried it, we don’t know that it works. We must ensure that our tests are accurate. The results of our tests show us that the features of the software to be valid. Usually testing is over-looked. Developers build automated tests for every piece of code that they write.
Let’s summarize the book in concise points:
1) Purpose of software is to help people
2) Equation of Software Design
3) Law of Change which is longer our software exists, the more probable that any piece of it will have to change
4) Law of defect probability: Chance of introducing a defect is proportional to size of changes you make to it
5) Law of simplicity: Ease of maintenance is proportional to simplicity of individual pieces.
6) Law of Testing: The degree to which you know how your software behaves is the degree to which you have accurately tested it
The most important points are that it is important to reduce the effort of maintenance than to reduce the effort of implementation. The effort of implementation is proportional to complexity of the system.
Outline:
1.Introduction
2.The Missing Science
3.Driving Force of Software Design
4.Future
5.Change
6.Defet and Design
7.Simplicity
8.Complexity
9.Testing
0 Laws of Software Design
Chapter 1:
The difference between bad programmer and good programmer is understanding. Why do computers break? They break a lot, a lot. It’s due to bad programming. But what is this root cause? It boils down to complexity.
We’d need programming to reduce complexity. Art in programming - reducing complexity into simplicity.
A good programmer needs to do everything in his power to make what he writes as simple as possible to other programmers. A good programmer creates things that are easy to understand.
A Program is sequence of instructions given to the computer, it’s the actions taken by a computer as a result of being given instructions. Improving the code, improves quality of software. It’s one of the most important problem we’d need to solve.
Chapter 2: Missing Science
The Author writes that this book is about Software Design. We know what a software is about, it’s about a set of instructions to achieve many functions. What would be Software Design?
Design is to make a plan for creation, in this case, we are planning in advance about the software. This would involve, tools, structure of code, technical decisions.
A Code that exists also has a design, in which structure or the plan that seems to follow. We’d need to ask questions like:
-What should the structure of our program code be?
-Is it more important to focus on having a fast program or a program whose code is easy to read?
-In this software design, which programming language should we use?
To make it concise, I’d say — anything that involves architecture of the software, technical decision while creating the system falls within the purview of software design.
We’d need to know that every programmer is a designer. Usually, the lead developer is in-charge of designing overall architecture of entire program. “Every programmer who writes a software is a designer.”
Can we say Software design is a science? The easiest answer is no, let’s look at why it is not a science:
- Science must contain knowledge that has to be collected
- This knowledge must have a way to be organized
- It ought to contain basic laws or general truths
- It also needs to tell how to do something in physical universe
- As far as we know, science is discovered through scientific method, which involves observation and experimentation
Let’s look at the fundamental laws of software design:
-Definitions tell you what something is and how you would use it
-Facts are true statements about something
-Rules are statements that give advice over something
-Laws are facts that always be true and cover a broad area of knowledge
In the above, laws are the most important. How does this book help us? It’s teaching us the science of software design (we think it is a science or assume to be), very few people are taught the software design process, instead they are taught a programming language and then asked to write some software. This book is filling the gaps between them.
Chapter 3: Driving Forces of Software Design:
Every time we write a software, we’d need to know exactly what the purpose of the software and why we are crafting the software. If we analyze it deeper, the single purpose of all software is to, “Help People.” If we break this purpose, we can understand it concretely:
Some specific pieces of software exists to help specific groups of people. A word process exists to write things. A Web browser exists to help people browse the web. The author says, purpose of software is not to make money or to show of how intelligent a person has become. It would violate principle of purpose in software, and lead to low-quality software. When we are given feature requests, we’d have to think, which feature would help the most number of people.
The author backs up his statement of purpose of a software is not to make money through expanding it. He says, to make money would be a personal purpose or purpose of an organization, but it ought not to be the case of the software. The two main primary factors that determine the income of software company is probably, the business skill and how much your software helps people. Business skill involves administration, management, marketing and sales.
Let’s summarize from the above paragraphs about purpose of software. We do know that, the goal of software is to help people. To be specific, the following points should be considered:
1) To allow us to write software that is as helpful as possible
2) To allow our software to continue to be as helpful as possible
3) To design systems that can be created and painted as easily as possible by their programmers, so that they can be and continue to be as helpful as possible.
Chapter 4: Future
An important question that faces every software designer is, how do I make decisions about my software and which decision would be the best? To rephrase this question, given possible decisions, which of those decisions are best out of all possibilities.
D = V/E,
D stands for desirability of change
V stands for value of change
E stands for the effort involved in performed the change.
Essentially, it says any change is directly proportional to value of change and inversely proportional to effort involved in making change. Value here means the degree to which this change helps anybody anywhere. It adds financial support to your own self as adding value. Value could be potential value and probability of value. In the above equation, we miss one important component, time. Features within a software change in value over time. If we include time and other attributes, then it becomes:
D = Vn + Vf / Ei + Em
Where Vf is value in future, Vn is value now. Ei effort of implementation, Em its effort of maintenance. We don’t want a situation where effort is $100k and value is $0.10, We’d want the opposite way, where effort is $10 and value is $100k.
The idea solution for guarantee success is to design our system in such a way that maintenance decreases over time, eventually becomes zero. In short, it’s important to reduce effort of maintenance than it is to reduce effort of implementation.
It’s easy to write software that helps one person right now, but it’s difficult to write software that would help millions of people now and to continue that in the future. If we just make things work in the present, then our software becomes hard to maintain in the future. Sometimes we are safest if we don’t assume to predict the future, but make design decisions with the information present now.
Chapter 5: Change
We know that the longer our software exists, the more probable it is that any piece of it will have to change. The common mistakes that software designers make when coping with change:
-Writing code that isn’t needed
-Not making the code easy to change
-Being too generic
We don’t write code that we do not need it. Un-used code clogs the system. Code should be designed based on what you know now, not on what you think will happen in the future. Being too generic in the design doesn’t help users
Chapter 6: Defects and Design:
Good programmers introduce one defect into a program for every 100 lines of code. The best programmers introduce for every 1000 lines of code. The chance of introducing a defect into your program is proportional to the size of changes you make to it. So if we have smaller changes, we have fewer defects and less maintenance.
The best design is one that allows for the most change in environment with least change in software.
“Never fix anything unless it’s a problem and you have evidence showing that the problem really exists.”
Don’t repeat yourself, this means that in your software system, any piece of information should ideally exist only once. We should not be copying/paste blocks of code, instead we allow one piece of code to call others. This helps us in making changes, if we make changes in one piece of coding, then it will automatically change in other aspects of the software system.
Chapter 7: Simplicity
The ease of maintenance in any piece of software is proportional to simplicity of its individual pieces. We cannot have perfect ease of maintenance, but it’s the goal we strive for in our system. Remember this doesn’t apply to whole system but only individual pieces. An average human being cannot comprehend whole pieces of the software. He can only comprehend pieces of it. The simpler each pieces of the software is, the easier to maintain.
We’d need to write code in simple, self-contained pieces where fixing defects and maintaining the system is easy. If we design a large, complex chunk, then each piece of work doesn’t get polish as much but it’s harder to maintain. However simple is relative, what we write as simple would be simple to us but not simple for our co-workers or customers. Always write good documentation that starts with, “New to this code?” So that a person who has no understanding can read your code. The worst of all is a software with no documentation, where you are just expected to figure out for yourself, or already know, how the code works. We’d need our code to be simple, in this case, stupid and dumb simple. What this means is when other programmers look at your code, do you want them to feel frustrated and angry or confused and frustrated? In addition to keeping it simple, being consistent in the code is important. Finally some other things that add to simplicity is readability that includes spacing, naming things so other programmers can understand the code, commenting it.
If we don’t pay attention in designing a system, it evolves into a massive, complicated beast. Sometimes when we design it, which takes more time, a lot of credit might not come in our way. If you think about design, your users and fellow developers will see benefits, working software, on-time released and a clear understandable code-base.
Chapter 8: Complexity
This is a common story in big projects. Someone working on a project would say, we were working on a project few years ago and this technology we were using was modern back then but it’s obsolete now. We can’t develop fast enough to keep up with modern user needs or while we were developing company x wrote a product better than ours much more quickly than we did.
If we think about this issue, what’s the source of this problem? Complexity. We start with a simple project that takes a month, but when we add complexity, it takes three months, if we add more, it takes nine months. Complexity builds upon complexity. In the first release, we don’t shoot for the moon, we start with something that works and doable. Adding Features is one way to add complexity to the software. Here are the most common ways:
1) Expanding the purpose of software
2) Adding Programmers
3) Changing things that don’t need to be changed
4) Being locked into bad technologies
5) Misunderstanding
6) Poor Design or no design
7) Reinventing the wheel, the only time we invent a wheel is when we need something that doesn’t exist, all of existing technologies are bad and will lock us in, existing wheels are incapable of meeting our needs, they aren’t properly maintained.
We add all these, we get, “Never-Shipping” Product.
If our purpose of our software is to help users write, but then we add some other purpose to it, then it gets very complex quickly. The purpose of word processor is to help us write things. A user needs to understand the purpose of the software, he wants a purpose behind it like to help doing taxes. To make a user get angry, make it difficult for the user to accomplish their purpose. Sometimes marketing, sales would bring up purpose of a software is to be cool, edgy design, become popular but we’d need a technical director or software designer to take the responsibility of this. Users are happiest with a focused, simple product that never violates, it’s basic purpose. A Technology’s survived potential is linked with maintainability. To have a sense of it’s survivability, look at the recent release library. Another attribute is interoperability which is the ability to switch away from a technology if you have to decide with another technology.
We’d have to ask, what problems are we trying to solve? We should ask the question, how in general, in a perfect world, should this sort of problem be solved? We don’t ask, how does Professor Anne solve this in her program or how do I solve this using my code.
In order to handle complexity, we can redesign a system that is too complex into smaller steps. If it’s too complex, it will take a lot of effort and time, but we’d need to conceive of a system that is simpler than what we have now, but it’s important to keep releasing new features. Unless we do this, we won’t be keeping up with the amount of change. One of the best ways to handle writing features and complexity is to do our redesigning purely with goal of making some specific feature easier to implement and then implementing that feature. It’s helpful to know multiple programming languages, and be familiar with many different libraries, because it involves different ways of thinking about problems.
Chapter 9: Testing:
I believe that every software developer has faced this, the software is running now, there is no certainty that it will run in the future. The degree to which you know how your software behaves is the degree to which you have accurately tested it.
When we say, it works, it’s vague. We should rather test our software so that it behaves in the way we intended it to be. We have to know what behavior we intended it to be.
Unless we have tried it, we don’t know that it works. We must ensure that our tests are accurate. The results of our tests show us that the features of the software to be valid. Usually testing is over-looked. Developers build automated tests for every piece of code that they write.
Let’s summarize the book in concise points:
1) Purpose of software is to help people
2) Equation of Software Design
3) Law of Change which is longer our software exists, the more probable that any piece of it will have to change
4) Law of defect probability: Chance of introducing a defect is proportional to size of changes you make to it
5) Law of simplicity: Ease of maintenance is proportional to simplicity of individual pieces.
6) Law of Testing: The degree to which you know how your software behaves is the degree to which you have accurately tested it
The most important points are that it is important to reduce the effort of maintenance than to reduce the effort of implementation. The effort of implementation is proportional to complexity of the system.
November 20, 2018
Programmers who don't fully understand their work tend to develop complex system. It can become a vicious cycle: misunderstanding leads to complexity, which leads to further misunderstanding, and so on.
People seems to just accept that system will bloat over time, becoming unmaintainable and need to be rewritten. However, none of this is inevitable. Various code problems doesn't arise out of natural law, instead they arise from complexity. Indeed as a software grow, they will become larger. In fact, effective software systems are inherently complex. However, we can maintain each of the component as simple as possible, so that we can comprehend as we look to that pieces. Programming in essence must be an act of reducing complexity. If each of developer don't simplify their code each part will become hard to be understood (thus the system can no longer be maintained). We must also consider the value for both of now and the future. Looking at it, realistically, it actually involves the effort of implementation and maintenance. Future value and effort of maintenance itself is tightly coupled with time, where value will be measured by how much money the change will make us.And how much it will cost to change the implementation.
People seems to just accept that system will bloat over time, becoming unmaintainable and need to be rewritten. However, none of this is inevitable. Various code problems doesn't arise out of natural law, instead they arise from complexity. Indeed as a software grow, they will become larger. In fact, effective software systems are inherently complex. However, we can maintain each of the component as simple as possible, so that we can comprehend as we look to that pieces. Programming in essence must be an act of reducing complexity. If each of developer don't simplify their code each part will become hard to be understood (thus the system can no longer be maintained). We must also consider the value for both of now and the future. Looking at it, realistically, it actually involves the effort of implementation and maintenance. Future value and effort of maintenance itself is tightly coupled with time, where value will be measured by how much money the change will make us.And how much it will cost to change the implementation.
January 17, 2019
This book is short and concise. It provides general advice that most programmers have heard, yet never apply in their code. The advantage I found in reading the book was that it actually goes a step further, and demonstrates the effects of failing to follow the laws/rules of program design. This gave me a better perspective of software design. I also really like the idea that the job of a software dev is to reduce complexity.
September 20, 2017
Very concise and information-dense book about building simple and maintainable code. Even if you are familiar with all the ideas inside, the good structure in terms of universal laws, rules and facts is still worth the reading.
I would definitely recommend it for any developer that wants to spend more of his time bringing value for his customers and less value fixing problems.
I would definitely recommend it for any developer that wants to spend more of his time bringing value for his customers and less value fixing problems.
June 29, 2014
Read this in 40 minutes. Full of platitudes that are somewhat obvious at this point in my career. I think Pragmatic Programmer is a better version of the same book.
June 30, 2017
Awesome book.
Simplicity for the win
Simplicity for the win
September 29, 2019
Hilarious bullshit disguised as science.
June 11, 2023
This is a short book on—as the title suggests—writing simple code, as the root cause of every problem in software is complexity.
The main purpose of any software, the author believes, is to help people. Therefore, your ability to write good code is determined by your ability to imagine ways to assist others. Speaking from experience, that makes sense. Every developer I’ve seen writing bad code—and by bad I mean code that can’t be understood easily by others and is hard to be changed in the future—has written code for themselves, not for others. Some even put extra effort to make their code less readable as they think—wrongly, of course—that it would make them irreplaceable at their company. So, if you’re an engineering manager and find a developer who writes bad code and never makes an effort to improve, you need to make a decision sooner rather than later.
Max also argues that “It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.” The reason is that most software systems are maintained for a long time, therefore the effort of implementation becomes less and less significant; the effort of maintenance, on the other hand, is what really matters. So, write code that’s easy to maintain even if it takes you more time to write it. How? Follow software development best practices such as DRY and SOLID, and most importantly, make your code as simple as possible; or as Max puts it, “dumb simple.”
All in all, this is a great book. However, if you're looking for code samples, you're not going to find that many.
The main purpose of any software, the author believes, is to help people. Therefore, your ability to write good code is determined by your ability to imagine ways to assist others. Speaking from experience, that makes sense. Every developer I’ve seen writing bad code—and by bad I mean code that can’t be understood easily by others and is hard to be changed in the future—has written code for themselves, not for others. Some even put extra effort to make their code less readable as they think—wrongly, of course—that it would make them irreplaceable at their company. So, if you’re an engineering manager and find a developer who writes bad code and never makes an effort to improve, you need to make a decision sooner rather than later.
Max also argues that “It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.” The reason is that most software systems are maintained for a long time, therefore the effort of implementation becomes less and less significant; the effort of maintenance, on the other hand, is what really matters. So, write code that’s easy to maintain even if it takes you more time to write it. How? Follow software development best practices such as DRY and SOLID, and most importantly, make your code as simple as possible; or as Max puts it, “dumb simple.”
All in all, this is a great book. However, if you're looking for code samples, you're not going to find that many.
October 19, 2023
This book is about the philosophy and general principles of software **design**. As such, it does not contain any code examples, as that's not needed for the purpose of this book.
The purpose is to explain the principles that make good software good, and then to convince you that if you don't apply them, you'll pay a price, regardless of how smart you are.
If I had to summarize the main thesis of the book in one sentence, it would be:
> The purpose of software is to help people for as long as possible, and since as time passes, requirements change, the best way to help people is to design your code so that its ease of change is maximized, a property which is accomplished only if the code as a whole is easy to understand, which implies its individual components must be as simple as possible.
In essence, to help people, you have to keep complexity under control. As in writing good prose, to write good code, you have to work hard to make it look simple. Other programmers will notice and will be a lot more capable to maintain/extend the code. Thanks to that, all users will be happier, with more demands met, and will keep using your products.
As Leonardo Da Vinci said, "simplicity is the ultimate sophistication."
Some people may find this book "too generic", but it's the kind of book that every new programmer should read right after they've finished their first "hello world" tutorial. This book will give new programmers the sensitivity to code smell that they'll need once they start cooking bigger and bigger code recipes.
The purpose is to explain the principles that make good software good, and then to convince you that if you don't apply them, you'll pay a price, regardless of how smart you are.
If I had to summarize the main thesis of the book in one sentence, it would be:
> The purpose of software is to help people for as long as possible, and since as time passes, requirements change, the best way to help people is to design your code so that its ease of change is maximized, a property which is accomplished only if the code as a whole is easy to understand, which implies its individual components must be as simple as possible.
In essence, to help people, you have to keep complexity under control. As in writing good prose, to write good code, you have to work hard to make it look simple. Other programmers will notice and will be a lot more capable to maintain/extend the code. Thanks to that, all users will be happier, with more demands met, and will keep using your products.
As Leonardo Da Vinci said, "simplicity is the ultimate sophistication."
Some people may find this book "too generic", but it's the kind of book that every new programmer should read right after they've finished their first "hello world" tutorial. This book will give new programmers the sensitivity to code smell that they'll need once they start cooking bigger and bigger code recipes.
Displaying 1 - 30 of 109 reviews