Whenever you’re reading books or watching presentations on management, two names are bound to show up.
Sep 032009
Like revision control, fresh graduates are introduced to the foreign concept of code conventions (or “coding standards”) once they enter professional software teams. As implied by the term, “code conventions” are a set of standards and guidelines that developers have to follow when coding in their software project.
Contrary to what many people think, code conventions are not there simply to make code style consistent throughout large projects with hundreds of thousands of lines of code. Nor is it simply an unnecessary tool used by senior developers to assert their control over the project that only complicates coding.
In fact, properly defined code conventions help manage complexity.
Sep 032009
In the next few posts, I’ll be posting about other fundamentals that I have missed so that we could move on to better stuff (i.e. stuff that not everyone knows) by the time I reach the 100 post mark.
–
The Pareto Principle (also known by many names e.g. Law of the Vital Few, 80/20 Principle, etc.) is a widely observed phenomenon wherein 80% of the effects come from only 20% of the causes.
Aug 192009
No Silver Bullet tells us to be skeptical about claims of tools that can provide drastic improvements in productivity. What we can instead hope for from productivity tools are minor, yet still significant, improvements.
However, both lowering our expectations and going with proven technologies aren’t enough to receive productivity benefits when introducing a new tool. Many companies still fail because of a certain classic mistake: Lack of Training.
Aug 182009
Aside from Brooks’s Law, Fred Brooks is also famous for another so-called “law” in software engineering: the No Silver Bullet argument.
There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity.
Aug 102009
It ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new.
- Niccolò Machiavelli, “The Prince”
Anyone who has tried to institute change in an organization would eventually have to deal with the scenario mentioned in the above quote. It does, however, get worse than that.
Aug 102009
- Encapsulate what varies.
- Favor composition over inheritance.
- Program to interfaces, not implementations.
- Strive for loosely couple designs between objects that interact.
- Classes should be open for extension but closed for modification.
- Depend on abstractions. Do not depend on concrete classes.
- Only talk to your friends.
- Don’t call us, we’ll call you.
- A class should only have one reason to change.
Continuing from the basics of OO, we now move on to its principles. The list above is taken from the wonderful book Head First Design Patterns and it enumerates some of the most important principles in OO. I’ll explain briefly what each principle means below the cut.
Aug 092009
Agile: In A Flash is a great source of software engineering tips regardless if you’re planning to go agile or not.
Out of the many flash cards in that site, I find the two cards above to be the most important to a novice software developer. It should make them feel less surprised when Brook’s Law or Hofstadter’s Law hits them from out of nowhere.
Recent Comments