engineering dogmas

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.

There have been extensive criticisms on various OOP models and OOP implementations (Java, C#, C++, MFC, Objective C, glib…) The AntiPatterns wiki and many other authors provide good anti-examples on the uses of patterns!

Linus Torvalds, being criticised: “the kernel has no obvious design”, had replied: “Linux is evolution, not intelligent designs”! The same applied for similarly complex projects!

Document is for understanding, but is not the understanding itself.

Software project management is the domain of vast diversity! No simple rules applied to a software process!

basic algorithms

The book is my primary source of interest while being a freshman, which presents a wide range of algorithms in a very coherent and systematic way. I remember “rescuing” this hard-copy from a Fahasa‘s junk pile for about 4 USD, which from that time on became a student’s most precious thing! You can read the soft-copy here.
I started with with C/C++ at school, then continue with C/C++, Java, Design Patterns… on various projects. Later I abandoned Design Patterns (and Java), then I abandoned C++. To me there’s no Design Patterns, there’s only data structures and algorithms! Would write another post on the bloating and non-sense usages of Design Patterns later on!
It seems that most software engineers today lack fundamental knowledges and skills. It’s quite apparent that you could not rely on a guy talking about architecture, GoF’s design patterns… all the time but can not state the algorithmic differences between a DFS (depth first search) and a BFS (breadth first search).

his is among the subjects I was very fascinated the early years at university: algorithms, graph theory, geometry, image processing… I was not quite good at “symbolic” math (like algebra), but “visual” math offered me much inspiration. The thing I would remember most is Robert Sedgewick‘s Algorithms, a book that I’ve read through over and over again many many times. It is indeed the most important Computer Science textbook that beginners MUST read until today.

The Java applet below is “refurbished” from the code I wrote the first year at college, which visualizes the nature of different sorting algorithms (original code was written in Borland C++ 3.1 with BGI – Borland Graphics Interface). This is among my various attempts to visualize the knowledge collected from the book, which had taught me that even a simple thing like “bubble sort” is not that “very simple”! Let select an algorithm in the dropdown list and click ‘Start’ and see the differences!


My visualizations above are very early (1997), much prior to those demonstrations on wiki. Later on, I’d learned that the author R.Sedgewick put a great emphasis on algorithms’ visualizing himself, his work used PostScript. Many new ways of visualization are really impressive and easy to understand, such as this (using JavaScript).