Important Name Thingies in CS

Note: this is just getting started, I’m missing A LOT of stuff. Give me a shout if something stands out

I’m a bit of an oddball - my mnemonic memory is sometimes quite poor and in computer science we have lots of law’s and rules which are referred to. It’s good we do, it gives us a more Ubiquitous Language. However it also has some downsides, if you suck at remembering names then it’s easy to mix these up.

I figured I’d create a cheatsheet of sorts, besides you might find something here which you’ve never seen before. If you’re new it’s OK to follow these dogmatically, if you are getting more experienced it’s good to think about when these are and aren’t good things to do.


Clockwise/Spiral Rule - David Anderson Parsing any C expression

Occam’s Razor or in latin: Lex parsimoniae: The simplest explanation is usually the best.

KISS: Keep it simple, stupid - Kelly Johnson

“Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away.” Antoine de St. Exupery, Terre des Hommes, 1939, chap.3.

Uncle Bob quotes: “And yet all developers feel the pressure to make messes in order to meet deadlines. In short, they don’t take the time to go fast.”

First Law of Programmer Creativity: Caveat Emptor: The cost of software maintenance increases with the square of the programmer’s creativity. Robert D. Bliss

Software Managment

Brooks’s Law: “adding manpower to a late software project makes it later.”
-Brooks, Mythical Man Month

LeBlanc’s law: Later equals never.

Possibly my favorite since you can’t beat a recursive law in CS
Hofstadter’s Law: It always takes longer than you expect, even when you take into consideration Hofstadter’s law.

Conway’s Law (Congruence): the structure of a software system will reflect the structure of the organization that builds it.
A great talk given by @rachellaycock of ThoughtWorks talks about how Conway’s law will limit or destroy your chances of success when moving to Continuous Delivery.

Software Engineering

Ward’s principle: “You know you are working on clean code when each routine turns out to be pretty much what you expected.”

DRY: Do not repeat yourself. In other words copy and pasting code can be bad. SOLID principles

the programmer thinks in terms of (genenerally) real life objects and their responbilities. See Steve Jobs explain it here

YAGNI: You ain’t gonna need it - don’t add functionality until it’s absolutely necessary.
This is closely tied to a quote from Donald Knuth:

Premature optimization is the root of all evil

Law of Demeter: this is the principle of least knowledge, it’s foundational to good OOP5. It says that an object should have the least amount of knowledge possible about how another class does it’s work. This is Steve Jobs explaining OOP, and this idea of not knowing is the law of demeter:

Objects are like people. They’re living, breathing things that have knowledge inside them about how to do things and have memory inside them so they can remember things. And rather than interacting with them at a very low level, you interact with them at a very high level of abstraction, like we’re doing right here.

Here’s an example: If I’m your laundry object, you can give me your dirty clothes and send me a message that says, “Can you get my clothes laundered, please.” I happen to know where the best laundry place in San Francisco is. And I speak English, and I have dollars in my pockets. So I go out and hail a taxicab and tell the driver to take me to this place in San Francisco. I go get your clothes laundered, I jump back in the cab, I get back here. I give you your clean clothes and say, “Here are your clean clothes.”

You have no idea how I did that. You have no knowledge of the laundry place. Maybe you speak French, and you can’t even hail a taxi. You can’t pay for one, you don’t have dollars in your pocket. Yet I knew how to do all of that. And you didn’t have to know any of it. All that complexity was hidden inside of me, and we were able to interact at a very high level of abstraction. That’s what objects are. They encapsulate complexity, and the interfaces to that complexity are high level.

Databases and System


BASE Read more here

ACID and BASE are a continuum. ACID is pessimistic about what might happen, BASE is optimistic and accepts the risks.

The CAP theorem states that any networked shared-data system can have at most two of three desirable properties:

It is traditionally said that you must choose 2 out of 3 for your system, because we believe that’s the best you can do. Here is a great article from the man who came up with the CAP Theorum and he talks about how thats not quite true, and how all these three theorums relate.

  1. You should probably depend on third party verification. Hello code reviews! [return]
  2. Single responsibility doesn’t mean that it does literally one small task, it just means it has a cohesive meaning - represents a person is single responsibility [return]
  3. or protocols or ducks [return]
  4. This allows for polymorphism! Hurrah! [return]
  5. Object Oriented Programming: Used to describe a way of programming where [return]
comments powered by Disqus