I don’t use recipes to ensure the quality of my software. Most of those development tasks to make the software a reliable tool are techniques learned along the time, without considering the methodology behind the software development. I can’t stand for any methodology as the better methodology that you can use. I just follow few commandments or rules on software development, and all of them bring me good results.

"…premature optimization is the root of all evil".
— Donald Knuth

I agree with the fact that we must do our source code level optimizations when we have finshed the construction stage or it is almost complete. I was searching articles and papers about optimizing C source code to be applied on my programs and libraries. I’ve collected some of those optimizations. But you must not confuse algorithm optimization, source code optimization and compiler optimization, since the first one refers to algorithm design and the second one just refers to the algorithm implementation, and both are sharing just few common approaches to formal reductions.

Java synchronization is usually made through the synchronized keyword. Synchronized allow users to create a mutex around certain variable, class or method, where a mutex allows concurrent access to it. By concurrent access we should understand access from multiple threads. If an operation is atomic, there one and only one process or thread executing it. Then, mutex based operations are atomic.

My experience with Functional Programming Languages is small. I’ve been writing small hacks for emacs lisp, such as hooks for certain modes and actions for a while, and sometimes building small tools in SBCL. Someone on Internet has recommended me an interesting book about Haskell called "Real World Haskell", that may be read on-line. I’ve been reading the book in my free time, and playing with the Haskell syntax, building small functions and playing with data type. So the result of those games is a small program that I want to share with you.

There is a fact that some companies are overselling their services. The behavior is simple to describe, they take more projects than they can handle. Q: Why they can not handle those projects? A: Efficiency. As consequence, you have a heavy work load on developers, project managers and the rest of the hierarchy tree. Then you have project managers overtaking commitments, losing them, and sometimes losing a client.

According to my criteria, most of those steps back to certain milestone or time schedules have common origins:

If you are updated, you will notice that there are a lot of people doing computer programming that are not capable to do this task. The cause comes from different reasons, such as not enough concentration to create code and follow the program flow. You will find that there are a small group of people doing a good job, this means that you will not find people capable to understand the code, extend it or understand at least how works the technology that they are using. Someone to be qualified must understand what is doing, and really must leave the philosophy of "it’s easy, the environment that I’m using is doing all for me".