The fundamentals

I've been working on an idea that a software manager's job is to promote the fundamentals of software design, but I realized it was difficult to discuss the fundamentals with out stating some of them, so I started a list of some of concepts I find important.

In retrospect, I should have noted these a long time ago, as it would have helped focus my work as a full time developer.

So here's the list:

  • Respect your profession. Creation is a noble pursuit.
  • Impress your users, not other developers. Developers are impossible to impress, so it is futile.
  • Most software projects fail: Don't underestimate the 'easy' stuff.
  • Use the standard library for your language.
  • KISS: Don't make the 'easy' stuff harder than it has to be.
  • Likewise, don't solve problems you don't have or create problems needlessly.
  • Consider boundary conditions.
  • Step through your code in the debugger before you check it in.
  • Don't repeat yourself.
  • Know your collections. Many languages use non-standard names, so read the docs.
  • "Premature optimization is the root of all evil", Donald Knuth, 'nuff said
  • Shorter functions are better than long ones.
  • Less code is better than more code.
  • But don't reduce code at the cost of readability (especially Perl programmers :))
  • Use Inversion of Control to reduce dependencies and coupling.
  • Class inheritance (not interface inheritance) increases coupling (aka subclass coupling). Prefer aggregation and IOC which decrease coupling.
  • Beware of code that doesn't contain actual application or system logic.
  • Long variable names are ok.
  • Narrow variable scope is preferable to broad variable scope.
  • Do not use exceptions to implement application logic. The application should not throw and catch exceptions when it is behaving correctly or as expected.
  • Concurrency is almost impossible to get correct. See: When to use threads
  • Unless your product is for developers, reduce meta programming.
  • Likewise: your language is a tool. It is a means to an end and not an end in and of itself. Nor is it a religion.
  • If your tools are your religion, practice at home. Be a professional agnostic.
  • In production code, prefer proven (known to be used in production systems over a reasonable amount of time) technology over experimental.
  • Maintain a side project for experimentation.
Show Comments