Quotes for large software projects

Again it is time to talk about larger software projects. This time not only about the "how's" and "where's", let us take a more... humorous approach. Let us have some famous qoutes you could use to get some brains straight back to line.

If someone shows off a very complicated software design to you, consider to quote the following:

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

C.A.R. Hoare

Let's say everything in a huge project is clear - theoretically. Why should implementing it be difficult? Because...

"In theory, theory and practice are the same. In practice, they're not."

Yogi Berra

Long-year-experience and wisdom from my friends:

"Frameworks like Ruby on Rails exist to make simple things even more simple and complex things impossible."

A colleague of mine

A deadline bites. But again, time - while developing in a large project - is somewhat relative:

"The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time."

Tom Cargill

Cutting the development time by throwing more developers into a project? Reply this:

"Nine people can't make a baby in a month."

Fred Brooks

Not exactly valueable for large projects, but, alas, said by a great man:

"Whereas Europeans generally pronounce my name the right way ('Nick-louse Veert'), Americans invariably mangle it into 'Nickel's Worth.' This is to say that Europeans call me by name, but Americans call me by value."

Niklaus Wirth

Something every programmer of a large project at least said once in his life:

"It works on my machine."

Anonymous Programmer

And, one of my favourites, not exactly from a programmer (but a wise man):

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

Antoine de Saint Exupéry

Look out for some more quotes at "Quotes: 5 different views on computers and programs".

About a stackoverflow-comment I wrote: Best practices, summaries and Zen

Once upon a time... I answered a question on stackoverflow.com (What do you consider the 1st principle(s) of programming?) a little bit zen-likely. The standard answers were "kiss", "dry" and "yagni" which I not only like but try to embrace wherever possible. Nevertheless, there is much more to say about that and therefore here is my little "zen-garden" of programming tips in 4 parts:

Zen, part I: Programming is only the road, not the way.

Programming is only the technique to teach a computer what it's gotta do. To be successful in creating fast, reliable software means to know your algorithms, best-practices and all the other stuff not necessarily connected to your programming (language).

Zen, part II: If you are in a hurry, stroll along. If you really are in a hurry then take a detour.

Sounds silly but do not let yourself get into compromises that (really) may trouble you afterwards. "Stroll along" when the project is in a total hurry? It works if done right.

For this I got a rule: In case you are at the core of a program, try to be as precise and good as possible. If you are using methods from the core that are deep in your software, try to be faster in coding. If you are coding above these two, you can even get a little bit more sloppy. This way you will prevail headaches by not spending time to trace "unexpected behaviour" of core functionalities (and all relying parts to them).

Remember: Design errors are the hardest to find and/or fix. Next step on the ladder are programming errors in parts everyone relies on, then the "real showing-off software parts" (like UI or web interfaces). If you need to fix a design error at the end of a project, it means to fix it through the persistence layer, the protocols, the client... ahem. Not good at all.

Zen, part III: Know your path, Neo.

Know your environment, tools and the stuff you rely on on a daily basis and get it sorted so that it works for you. Best if you use your programming "environment" so natural that you do not even have to think of it. If you have to get a job done do not introduce "fancy new stuff" but do your work. This stuff can be introduced in a new project, namely then when you have time to prepare and use it.

Which leads to the thought that you "should stay onto the stuff you ultimately know. Anytime." Right?

Completely wrong. Try to learn something new every day. At least try to inform youself about new thingies out there, not in detail, not remotely complete but open minded.

I am sure you accomplish this, because to learn something new you are reading this blog right at this moment. Aren't you?

Zen, part IV: Do you think that's air you're breathing?

Never, ever, think you're the best in what you are doing, if so, you only could get worse;-). And never be satisfied with the techniques you know and therefore stop listening or learning to new ideas.
At least try to be open minded enough to listen to new concepts, strategies or - even - programming languages and paradigms. That advice is the most necessary - and most valuable- I might give to you for your (programmers) life at all.

Quotes: 5 different views on computers and programs

Oldies but goldies: Gathering famous quotes on computers, programs, users and programmers. Have fun!

The users view on computers and programs:

Homer Simpson: "The Internet? Is that thing still around?"
Ted Nelson: "Any fool can use a computer. Many do."
Jeremy S. Anderson: "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence."
Dennie van Tassel: "I've finally learned what 'upward compatible' means. It means we get to keep all our old mistakes."

The programmers view on computers and programs:

Anonymous: "The best thing about a boolean is even if you are wrong, you are only off by a bit."
Stan Kelly-Bootle: "Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration."
Robert Sewell: "If Java had true garbage collection, most programs would delete themselves upon execution."
Alan J. Perlis: "There are two ways to write error-free programs; only the third one works."

The meta view on computers and programs:

Edsger W. Dijkstra: "The question of whether computers can think is like the question of whether submarines can swim."
Bjarne Stroustrup: "There's an old story about the person who wished his computer were as easy to use as his telephone. That wish has come true, since I no longer know how to use my telephone."
Dave Barry: "Computers are getting smarter all the time. Scientists tell us that soon they will be able to talk to us. (And by 'they', I mean 'computers'. I doubt scientists will ever be able to talk to us.)"
Oktal: "I think Microsoft named .Net so it wouldn't show up in a Unix directory listing."

The worlds view on Computers and programms:

Seymour Cray: "The trouble with programmers is that you can never tell what a programmer is doing until it's too late."
Eagleson's Law: "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."
Edsger W. Dijkstra: "If debugging is the process of removing bugs, then programming must be the process of putting them in."
Paul Ehrlich: "To err is human, but to really foul things up you need a computer."

The artists view on computers and programs:

Pablo Picasso: "Computers are useless. They can only give you answers."

More quotes to read at "Quotes for large software projects".