Some main points from both of these posts:
- Keep it simple. Using advanced, usually more complicated, tools and designs (e.g. COM, multithreading, C++, templates) only when absolutely necessary. Be careful of over using a tool and of over engineering the solution.
- Good (smart) software developers know when the aforementioned tools are needed and when to avoid them, and are not afraid to make the decision to use or not use them, or assert there views on the matter.
- Be pragmatic: "A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has" [Joel].
- One of the most important, perhaps the most important, feature of a (software) product is to ship the product as soon as possible. "It's great to rewrite your code and make it cleaner and by the third time it'll actually be pretty. But that's not the point --- you're not here to write code; you're here to ship products" [Jamie Zawinski, from Joel]. Nevertheless, don't ship garbage: "The programmer who spends weeks building the perfect structure does just as much harm to the project as the programmer who hacks a bunch of crap together. Neither have struck the balance that's required" [Bob]
Here are some follow-ups by Bob:
Echoes from the Stone Age
TDD Derangement Syndrome
