Over 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.