logo

Software Engineering Philosophies

Last Updated: 2022-02-05

Philosophy = love of wisdom

Unix: Do One Thing and Do It Well

https://en.wikipedia.org/wiki/Unix_philosophy

Do One Thing and Do It Well

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

... the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools.

https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

The UNIX Philosophy:

  1. Small is beautiful.
  2. Make each program do one thing well.
  3. Build a prototype as soon as possible.
  4. Choose portability over efficiency.
  5. Store data in flat text files.
  6. Use software leverage to your advantage.
  7. Use shell scripts to increase leverage and portability.
  8. Avoid captive user interfaces.
  9. Make every program a filter.

Python

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Philosophy Pages of Open Source Projects

Laws

Law of Demeter

principle of least knowledge

Benford's law

Also called the first-digit law, is an observation about the frequency distribution of leading digits in many real-life sets of numerical data. The law states that in many naturally occurring collections of numbers, the leading significant digit is likely to be small.

Conway's law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure

Postel's Law

(robustness principle): Be conservative in what you do, be liberal in what you accept from others.

Gall's law

All complex systems that work, evolved from simpler systems that worked.

LAMPSON’S LAW

"Get it right. Neither abstraction nor simplicity is a substitute for getting it right." ("Hints for Computer Systems Design")

LAUER’S LAW

LESS CODE IS BETTER CODE () “If the same people had twice as much time, they could produce as good of a system in half the code.

Occam’s Razor

All other things being equal, the simplest solution is the best.

Maven: Convention over configuration

Convention over configuration: to decrease the number of decisions that a developer using the framework is required to make without necessarily losing flexibility.

Worse Is Better

https://en.wikipedia.org/wiki/Worse_is_better

worse is better: simplicity of both the interface and the implementation are more important than any other attributes of the system — including correctness, consistency, and completeness.

Developer progression

  1. Simple and wrong
  2. Complicated and wrong
  3. Complicated and right
  4. Simple and right

Choose Boring Technology

http://mcfunley.com/choose-boring-technology

Halting Problem

Alan Turing, 1936: no algorithm exists that will take as input a computer program (and its input data), and output 0 if the program halts and 1 if the program does not halt.

"Halting Problem" is therefore undecidable by algorithm.

Others

  • "Don't Repeat yourself" (DRY) principle
  • Do not communicate by sharing memory; instead, share memory by communicating.
  • You cannot improve what you cannot measure
  • data visualization: "Overview first, zoom and filter, then details-on-demand."
  • Strong cohesion, Low coupling
  • AWS: primatives, not frameworks.
  • Docker: Batteries Included, But Replaceable
  • spullara: I once asked Gordon Moore what the software equivalent of Moore's law was, he responded without pause: "the number of bugs doubles every 18 months".
  • git: porcelain and the plumbing
  • tolerant reader(Martin Fowler): ignore changes we do not care about, e.g. use XPath(xml) or JsonPath(json) to extract the parts we care
  • Erlang creator Mike Williams point: “If you don’t make experiments before starting a project, then your whole project will be an experiment”.
  • Glenn Vanderburg: “Developers should always understand one layer of abstraction below their everyday work.”
  • Donald Knuth: “Premature optimization is the root of all evil.
  • Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove. -- Antoine de Saint-Exupery
  • Everything should be made as simple as possible, but not simpler. -- Albert Einstein
  • if you’re not embarrassed by the first version, you waited too long to ship it.
  • "as with all software, at times older tools required shims and bridges to make everything work together."
  • A good programmer is someone who always looks both ways before crossing a one-way street. (Doug Linder)
  • Don’t worry if it doesn't work right. If everything did, you’d be out of a job. (Mosher’s Law of Software Engineering)
  • The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. (Seymour Cray)
  • Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris. (Larry Wall)
  • Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. (Martin Golding)
  • One man’s crappy software is another man’s full time job. (Jessica Gaston)
  • If builders built buildings the way programmers wrote programs, then the first woodpecker that came along wound destroy civilization. (Gerald Weinberg)
  • The most likely way for the world to be destroyed, most experts agree, is by accident. That’s where we come in; we’re computer professionals. We cause accidents. (Nathaniel Borenstein)
  • It’s a curious thing about our industry: not only do we not learn from our mistakes, we also don’t learn from our successes. (Keith Braithwaite)
  • Once a new technology starts rolling, if you’re not part of the steamroller, you’re part of the road. (Stewart Brand)
  • If at first you don’t succeed, call it version 1.0 (unknown)
  • All programmers are playwrights and all computers are lousy actors. (Anonymous Hack Actor)
  • The sooner you get behind in your work, the more time you have to catch up. (Anonymous Scheduler)
  • When a programming language is created that allows programmers to program in simple English, it will be discovered that programmers cannot speak English. (Anonymous Linguist)
  • Why do we never have time to do it right, but always have time to do it over? (Anonymous)
  • Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
  • 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. (Eagleson's law)
  • Measuring programming progress by lines of code is like measuring aircraft building progress by weight. (Bill Gates)
  • Programming is like sex. One mistake and you have to support it for the rest of your life. (Michael Sinz)
  • Walking on water and developing software from a specification are easy if both are frozen. (Edward V Berard)
  • 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.(Tom Cargill)
  • Commenting your code is like cleaning your bathroom — you never want to do it, but it really does create a more pleasant experience for you and your guests. (Ryan Campbell)
  • Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. (Rick Cook)
  • The hardest part of design … is keeping features out. (Donald Norman)
  • In order to understand recursion, one must first understand recursion. (Anonymous)
  • There are only two kinds of programming languages: those people always bitch about and those nobody uses. (Bjarne Stroustrup)
  • The best thing about a boolean is even if you are wrong, you are only off by a bit. (Anonymous)
  • If Java had true garbage collection, most programs would delete themselves upon execution. (Robert Swell)
  • In theory, there is no difference between theory and practice. But, in practice, there is. (Jan L. A. van de Snepscheut)
  • Ready, fire, aim: the fast approach to software development. Ready, aim, aim, aim, aim: the slow approach to software development. (Anonymous)
  • Programming is 10% science, 20% ingenuity, and 70% getting the ingenuity to work with the science. (Anonymous)
  • It is easier to measure something than to understand what you have measured. (Anonymous)
  • Benchmarks don’t lie, but liars do benchmarks. (Anonymous)
  • Better train people and risk they leave – than do nothing and risk they stay. (Anonymous)
  • The goal of Computer Science is to build something that will last at least until we've finished building it. (Anonymous)
  • Java is to JavaScript what Car is to Carpet. (Chris Heilmann)
  • 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)
  • Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. (Stan Kelly-Bootle)
  • Programs must be written for people to read, and only incidentally for machines to execute. (Abelson / Sussman)
  • Programming can be fun, so can cryptography; however they should not be combined. (Kreitzberg and Shneiderman)
  • Copy and paste is a design error. (David Parnas)
  • Computers are good at following instructions, but not at reading your mind. (Donald Knuth)
  • Deleted code is debugged code. (Jeff Sickel)
  • If debugging is the process of removing software bugs, then programming must be the process of putting them in. (Edsger Dijkstra)
  • 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.
  • It's hard enough to find an error in your code when you're looking for it; it's even harder when you've assumed your code is error-free. (Steve McConnel)
  • It’s not a bug – it’s an undocumented feature. (Anonymous)
  • Without requirements or design, programming is the art of adding bugs to an empty text file. (Louis Srygley)
  • Bad code isn’t bad, its just misunderstood. (Anonymous Code Behaviorist)
  • There are two ways to write error-free programs; only the third one works. (Alan J. Perlis)
  • Beware of bugs in the above code; I have only proved it correct, not tried it. (Donald Knuth)
  • Before software can be reusable it first has to be usable. (Ralph Johnson)
  • Software undergoes beta testing shortly before it’s released. Beta is Latin for “still doesn't work". (Anonymous)
  • The best performance improvement is the transition from the nonworking state to the working state. (J. Osterhout)
  • The cheapest, fastest, and most reliable components are those that aren't there. (Gordon Bell)
  • I think Microsoft named .Net so it wouldn’t show up in a Unix directory listing. (Oktal)
  • Software and cathedrals are much the same – first we build them, then we pray. (Sam Redwine)
  • The software isn’t finished until the last user is dead. (Anonymous)
  • 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. (Alan Kay)
  • “A multithreaded file system is only a performance hack” or, as Tony Hoare remarked, “concurrent programs wait faster”.
  • As every parent of a small child knows, converting a large object into small fragments is considerably easier than the reverse process.

Sarcasm / Humor

  • We just had a discussion in the team, and we decided, that we need add-one microservice that would get a number and return the number increased by one. A nice separation of concerns in modern distributed web application
  • Norvig's Law: Any technology that surpasses 50% penetration will never double again(in any number of months). http://www.norvig.com/norvigs-law.html
  • Perl – The only language that looks the same before and after RSA encryption.
  • Java = domain-specific language converting large XML files into stacktraces
  • The nice thing about standards is that you have so many to choose from.
  • if you google "recursion", you will see "Did you mean: recursion"

More

https://en.wikipedia.org/wiki/List_of_software_development_philosophies