he computer industry is the only industry that is more fashion – driven than women’s fashion. (Larry Ellison) => right, so much dogmas, lies and myths.

Well, it has been said over and over again that the tremendous cost of programming is caused by the fact that it is done by cheap labor. (Edsger W. Dijkstra) => needless to say, another so true dilemma!

I do believe I have post-traumatic Java syndrome. (Renae Blair) => me too, though not very serious!

One of my most productive days was throwing away 1000 lines of code. (Ken Thompson) => with me even more

Deleted code is debugged code. [Jeff Sickel] => 😬

Before code can be reusable it first has to be usable. (Ralph Johnson) => certainly!

The goal of Software Engineering is to build something that will last at least until we’ve finished building it. (unknown) => applied to many projects!

Better train people and risk they leave – than do nothing and risk they stay. (unknown) => it’s worse when they stay and untrained!

Benchmarks don’t lie, but liars do benchmarks. (unknown) => countless cases!

Why do we never have time to do it right, but always have time to do it over? (unknown) => the question answers itself!

Evolution always seems to win out over revolution when it comes to technology. (Rick Hightower) => don’t believe in one who screams for revolution!

If you have too many special cases, you are doing it wrong. (Craig Zerouni) => solving is not creating more problems (special cases = problems)!

C++ is popular because it is like C. Java is popular because it is like C++ and C. C# is popular because it is like Java. See a pattern! (Rick Hightower) => many techies fanboys forgets this!

What it comes down to is that Rails developers are just that: they’re not software developers, at least not most of them… Their framework dictates how their systems are designed instead of the problems the systems are designed to solve. (Samuel Tesla) => said this several years ago

Suppose you went back to Ada Lovelace and asked her the difference between a script and a program. She’d probably look at you funny, then say something like: Well, a script is what you give the actors, but a program is what you give the audience. (Larry Wall) => 😀

The structure of software systems tend to reflect the structure of the organization that produce them. (Douglas Crockford) => 😀 absolutely!

ver the years in our software community, I’ve seen a lot of dogmas, myths and lies that spread like ‘cholera’. That only reflects the fact that many programmers just repeat like parrots what they ‘learned’ from school, news, books… without their own justification, and to some extent, reflect their lacking of experiences. A good engineer should, at least, have some abilities to judge the pros and cons, weak points and strong points, when to use, and when not to use a method, a language or a technology.

Design first, then code!

The principle is, in general, not wrong. However, pragmatically, a software’s final structure, architecture… is not achievable as product of an immediate thought or a single design cycle. In most cases, the “first design” is certainly not the correct one. It’s not in a deterministic process that we can build software, complex product would always requires a lot of trial and fail. And from my experiences, good designs are sustainable solutions after a tedious process of experiments to eliminate wrong directions. We need coders of strong analysis and experimental skills rather than the “evangelic designers”!

Where are the documents?

We are going to make clear distinction: do we need coders who really understand what they are doing, or we just need some paper to present to customers? In countless cases did I see that coders do not understanding what they are doing: they don’t understand a feature, they don’t know how to archive that, they are unable to judge the pros and cons, they just mechanically copy and paste code from somewhere. Documents only provide rough, general views on the matters. If you’re going to mention about a static-web-page project, I would agree that document is something. But if you’re mentioning system programming, it’s the code that is the document!

Poor skills and wrong knowledges

This is simply put: countless! Just to name a few:

Poor skills: once, a coder being asked to fix a “null pointer exception”. What he did is adding a “if (pointer != NULL)” line into the code. It’s not fixing, it’s just hiding, fixing is find out why the pointer is NULL, not prevent it from being executed! Another time, another coder, getting frustrated under a crash situation, place a “try… catch” around the buggy code segment. This is again, not fixing, with this way of hiding, we’re just going to accumulate faultinesses until the software crashes silently for no reasons!

Object oriented programming rules: OOP is more beautiful in theory than in practice. OOP provides a nice way for modeling, but it come at costs: bloating code. It is not until the project grows above 1M LOC that OOP become a burden, that we would need to do the “functional decomposition” optimization tasks. It’s the execution (functional) tree that decides performance, not the inheritance tree that obscures runtime characteristics!

Design pattern rules: this is again, not true! I agree that patterns reflect some good coding practices, but software could never be built from the so call “patterns” (there hasn’t been any such proven process). I really don’t understand what is a “singleton” if it’s essentially (in C/C++ syntax) a static variable, I also don’t understand what we need from a “factory” if it’s essentially a “switch… case” structure!?

Management myths

Managers tend to forget what they’d learned when they were coders. There’re lots of myths in software management, just some examples:

• Software people is of a same type and the same background.

• We already have a book that’s full of standards and procedures for building software. That provide out people with everything they need to know!

• If we get behind schedule, we can add more programmers and catch up.

• Project requirements continually change, but change can be easily accommodated because software is flexible.

here 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. (Charles Antony Richard Hoare)

A good programmer is someone who looks both ways before crossing a one-way street. (Doug Linder)

Being abstract is something profoundly different from being vague… The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. (Edsger Dijkstra)

It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter. (Nathaniel S. Borenstein)

Measuring programming progress by lines of code is like measuring aircraft building progress by weight. (Bill Gates)

There are only two kinds of programming languages: those people always bitch about and those nobody uses. (Bjarne Stroustrup)

The C programming language, a language which combines the flexibility of assembly language with the power of assembly language. (unknown)

The last good thing written in C# was Beethoven’s Moonlight Sonata. (unknown)

The problem with using C++ … is that there’s already a strong tendency in the language to require you to know everything before you can do anything. (Larry Wall)

A system composed of 100,000 lines of C++ is not be sneezed at… The real test of OOP will come when systems of 1 to 10 million lines of code are developed. (Ed Yourdon)

Computer language design is just like a stroll in the park. Jurassic Park, that is. (Larry Wall)