Max Kanat-Alexander

This slim volume covers the short list of principles of software development that can be considered absolutely fundamental for good software design. Because it focuses on the essential and leaves out all of the many areas where goodness varies from language to language or from project to project, it's not terribly novel for anyone who has read other books on good software design. The upside of this is that the book is short enough that I can say that any good software engineer ought to be regularly applying all of the concepts in this book.

I will admit that the framing of these concepts as the "science" of software development fell rather flat for me, as did the overly long (in my opinion) discussion of the purpose of software.… (mais)

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.… (mais)