Facts and Fallacies of Software Engineering

As the saying "Old hardware becomes obsolete; old software goes into production every night" - here are some of the interesting facts and fallacies of Software Engineering that I cherished over the period of time...!

1. The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves..!
2. Adding people to a late project makes it later..! ( Brooke's law )
3. Learning a new tool or technique actually lowers programmer productivity and product quality initially. The eventual benefit is achieved only after this learning curve is overcome. Therefore, it is worth adopting new tools and techniques, but only a) if their value is seen realistically and b) if patience is used in measuring benefits
4. Software developers talk a lot about tools. They evaluate quite a few, buy a fair number, and use practically none.
5. Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time.
6. Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people..
7. Software estimates are rarely adjusted as the project proceeds. Thus those estimates done at the wrong time by the wrong people are usually not corrected.
8. Since estimates are so faulty, there is little reason to be concerned when software projects do not meet the targets. But everyone is concerned anyway.
9. There are two "rules of three" in reuse: a) It is 3 times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in 3 different applications before it will be sufficiently general to accept into a reuse library..
10. Modification of reused code is particularly error-prone. If more than 20 to 25% of a component is to be revised, it is more efficient and effective to rewrite it from scratch.
11. Design patterns emerge from practice, not from theory.!
12. Missing requirements are the hardest requirements errors to correct.!
13. Design is a complex, iterative process. The initial design solution will likely be wrong and certainly not optimal
14. If the coder is not the same person as the designer, the designer's primitives are unlikely to match the coder's primitives, and trouble will result
15. Roughly 35% of software defects emerge from missing logic paths, and another 40% from the execution of a unique combination of logic paths. They will not be caught by 100% coverage..!        
16. Test automation is rarely what it is. Certain testing processes can and should be automated. But there is a lot of the testing that cannot be automated.
17. Efficiency stems more from good design "than" from good coding..!

Best Practices of API design in C++

We all know that writing large applications in C++ is a complex and tricky business. However, designing reusable C++ interfaces that are robust, stable, easy to use, and durable is even more difficult. Elegant and robust API design is a critical aspect of contemporary software development. Interfaces are the most important code that you write because a problem with your interface is far more costly to fix than a bug in your implementation