There are some great quotes I’ve been collecting.
I use them as inspiration or motto for some articles.
There are only two hard things in Computer Science: cache invalidation and naming things.
Make illegal states unrepresentable.
First make the change easy (warning: this might be hard), then make the easy change.
Object-oriented programming languages support encapsulation, thereby improving the ability of software to be reused, refined, tested, maintained, and extended. The full benefit of this support can only be realized if encapsulation is maximized during the design process.
Science is what we understand well enough to explain to a computer. Art is everything else we do.
The biggest issue on software teams is making sure everyone understands what everyone else is doing.
Object thinking focuses our attention on the problem space rather than the solution space.
We comfort ourselves with the belief that if the customers had just been happy with what they said they needed, the design would have been fine. It’s the customer’s fault for changing the requirements on us.
There is an art to knowing where things should be checked and making sure that the program fails fast if you make a mistake. That kind of choosing is part of the art of simplification.
You cannot teach beginners top-down programming, because they don't know which end is up.
Writing a class without its contract would be similar to producing an engineering component (electrical circuit, VLSI (Very Large Scale Integration) chip, bridge, engine...) without a spec. No professional engineer would even consider the idea.
A cache with a bad policy is another name for a memory leak.
The value of a prototype is in the education it gives you, not in the code itself.
When someone says, "I want a programming language in which I need only say what I want done," give him a lollipop.
Simple things should be simple, complex things should be possible.
Object-oriented programming increases the value of these metrics by managing this complexity. The most effective tool available for dealing with complexity is abstraction. Many types of abstraction can be used, but encapsulation is the main form of abstraction by which complexity is managed in object-oriented programming.
Make it correct, make it clear, make it concise, make it fast. In that order.
Indeed, the woes of Software Engineering are not due to lack of tools, or proper management, but largely due to lack of sufficient technical competence.
Hackers are arrogant geek romantics. They lack the attentive spirit of inquiry.
If someone claims to have the perfect programming language, he is either a fool or a salesman or both.
Thinking is not the ability to manipulate language; it's the ability to manipulate concepts.
Programming is not about typing, it's about thinking.
There’s nothing more permanent than a temporary hack.
The purpose of software engineering is to control complexity, not to create it.
The purpose of computing is insight, not numbers.
The trick is to fix the problem you have, rather than the problem you want.
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
Software and cathedrals are much the same. First we build them, then we pray.
Software is a gas; it expands to fill its container.
I can’t be as confident about computer science as I can about biology. Biology easily has 500 years of exciting problems to work on. It’s at that level
I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
Simplicity is prerequisite for reliability.
Edsger W. Dijkstra
Types are essentially assertions about a program. And I think it’s valuable to have things be as absolutely simple as possible, including not even saying what the types are.
Before software can be reusable it first has to be usable.
Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
The Scrum idea of a separated Scrum Master is good for Scrum, but not appropriate for most projects. Good development requires not just talkers but doers.
Premature optimization is the root of all evil
When in doubt, use brute force.
Any problem in computer science can be solved with another level of indirection.
Computer science is not about machines, in the same way that astronomy is not about telescopes. There is an essential unity of mathematics and computer science.
Michael R. Fellows
Computer scientists have so far worked on developing powerful programming languages that make it possible to solve the technical problems of computation. Little effort has gone toward devising the languages of interaction.
Developers are drawn to complexity like moths to a flame, frequently with the same result.
In programming, the hard part isn't solving problems, but deciding what problems to solve.
Walking on water and developing software from a specification are easy if both are frozen.
Edward V Berard
The Diagram is Not the Model. The model is not the diagram. It is an abstraction, a set of concepts and relationships between them.
The best performance improvement is the transition from the nonworking state to the working state.
I’m not a great programmer; I’m just a good programmer with great habits.
I can’t be as confident about computer science as I can about biology. Biology easily has 500 years of exciting problems to work on. It’s at that level.
Architecture is the tension between coupling and cohesion.
The role of a trainer or consultant is to empower the customer, not to make himself indispensable.
It is very hard to predict, especially the future.
A computer lets you make more mistakes faster than any other invention with the possible exceptions of handguns and Tequila.
Many people tend to look at programming styles and languages like religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy.
If debugging is the process of removing software bugs, then programming must be the process of putting them in.
More good code has been written in languages denounced as “bad” than in languages proclaimed “wonderful” — much more.
Computers are good at following instructions, but not at reading your mind.
Sun Microsystems had the right people to make Java into a first-class language, and I believe it was the Sun marketing people who rushed the thing out before it should have gotten out.
There are only two kinds of languages: the ones people complain about and the ones nobody uses.
The cost of adding a feature isn’t just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion. The trick is to pick the features that don’t fight each other.
Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer.
Subclasses shouldn’t always share all characteristics of their parent class but will do so with inheritance. This can make a program’s design less flexible. It also introduces the possibility of calling methods on subclasses that don’t make sense or that cause errors because the methods don’t apply to the subclass.
Programmers are as emotional and irrational as normal people.
There is nothing so useless as doing efficiently that which should not be done at all.
You can mass-produce hardware; you cannot mass-produce software; you cannot mass-produce the human mind.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
Optimism is an occupational hazard of programming: feedback is the treatment.
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Successful software always gets changed.
Thinking about my experience of modifying code, I see that I spend much more time reading the existing code than I do writing new code. If I want to make my code cheap, therefore, I should make it easy to read.
If you have to spend effort looking at a fragment of code and figuring out what it’s doing, then you should extract it into a function and name the function after the what.
The nice thing about standards is that there are so many to choose from.
Andrew S. Tannenbaum
It’s harder to read code than to write it.
Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test, it introduces security challenges, and it causes end-user and administrator frustration.
It is not the language that makes programs appear simple. It is the programmer that make the language appear simple.
We have to stop optimizing for programmers and start optimizing for users.
If you have three pet dogs, give them names. If you have 10,000 head of cattle, don't bother. Nowadays, the idea of giving a name to every file on your computer is ridiculous.
Error handling is important, but if it obscures logic, it’s wrong.
When debugging, novices insert corrective code; experts remove defective code.
A good programmer is someone who always looks both ways before crossing a one-way street.
The cleaner and nicer the program, the faster it's going to run. And if it doesn't, it'll be easy to make it fast.
Writing software as if we are the only person that ever has to comprehend it is one of the biggest mistakes and false assumptions that can be made.
The best smells are something that's easy to spot and most of time lead you to really interesting problems. Data classes (classes with all data and no behavior) are good examples of this. You look at them and ask yourself what behavior should be in this class.
It's not at all important to get it right the first time. It's vitally important to get it right the last time.
Andrew Hunt and David Thomas
Prolific developers don’t always write a lot of code, instead they solve a lot of problems. The two things are not the same.
Programs are meant to be read by humans and only incidentally for computers to execute.
A programming language is low level when its programs require attention to the irrelevant.
This will surprise some of your readers, but my primary interest is not with computer security. I am primarily interested in writing software that works as intended.
You will fall to ruin because you believe that exceptions to the rule make new rules.
Every time you write a comment, you should grimace and feel the failure of your ability of expression
Simplicity is the soul of efficiency.
Programming can be fun, so can cryptography; however they should not be combined.
Kreitzberg & Shneiderman
So much complexity in software comes from trying to make one thing do two things.
Deleted code is debugged code.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
The ratio of time spent reading (code) versus writing is well over 10 to 1 ... (therefore) making it easy to read makes it easier to write.
Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.
One day my daughter came in, looked over my shoulder at some Perl 4 code, and said, "What is that, swearing?"
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
If you say “I told you so”, you are the one who has failed. Because you knew, but did not manage to stop the train wreck.
Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.
Don’t comment bad code — rewrite it.
Code is like humor. When you have to explain it, it’s bad.
A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.
Talk is cheap. Show me the code.
Legacy code is code without tests.
Somebody will say they have a program that’s verified and it’s only verified because it met its specification according to some verifier. But the verifier might have bugs in it. The specifications might have bugs in them
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time
One man's crappy software is another man's full time job.
The pesticide paradox. Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffective.
I try to think mostly in terms of preconditions, and checking things in the constructor and the beginning of a function.
Good software, like wine, takes time.
Pasting code from the internet into production code is like chewing gum found in the street.
Discovering the unexpected is more important than confirming the known.
George E. P. Box
Pay attention to zeros. If there is a zero, someone will divide by it.
Beta testing is a symptom of weak testing practices and poor communication with customers
Beware of bugs in the above code; I have only proved it correct, not tried it.
The key to building a great product is building a great team first. To me, great teams aren’t bound by roles, but they’re driven by moving forward.
With tests, we can change the behavior of our code quickly and verifiably.
Without them, we really don’t know if our code is getting better or worse.”
Correctness is clearly the prime quality. If a system does not do what it is supposed to do, then everything else about it matters little.
A Perl program is correct if it gets the job done before your boss fires you.
As the Tests get more Specific, the Code gets more Generic.
Software testing is not only ensuring absence of bugs but also ensuring presence of value.
Quality is free, but only to those who are willing to pay heavily for it.
DeMarco and Lister
Developer testing is an important step towards accountability. It gives developers a way to demonstrate the quality of the software they produce.
Nothing makes a system more flexible than a suite of tests.
As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications.
There are two ways to write error-free programs; only the third one works.
Alan J. Perlis
Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.
Let there be no doubt that object-oriented design is fundamentally different than traditional structured design approaches: it requires different ways of thinking about decomposition, and it produces software architectures that are largely outside the realm of the structured design culture.
I invented the term ‘object oriented’, and C++ was not what I had in mind.
Part of the objective of this series of articles is to generate spaces for debate and discussion on software design.
We look forward to comments and suggestions on this article.
Original Thread on Twitter