Stuffing My Brain, Part 03

Scott Meyers. A standing room only crowd. Scott Meyers. Eight hours of Scott Meyers. Fun!

Scott's all-day tutorial was titled "Better Software -- No Matter What". To summarize in a single sentence: quality is important. No surprise, right? The reason this was an all-day talk is the many specifics of what this means to Scott. Key points for me:

  • All defects are worth addressing. If correction of a defect is not feasible, consider whether you can prevent it outright or at least prevent customers from running into it.
  • Following quality practices does not have to cost you time. In fact, it's likely to save you time by eliminating rework and debugging.
  • Useful specifications are of utmost importance. This does not necessarily mean you need reams of pages of documentation. It does mean that you should ensure that when you sit down to implement a feature you have some form of spec that is complete and detailed enough to answer questions during design and implementation, unambiguous enough that everybody is likely to interpret it in the same way, and taken seriously by everyone involved. If your spec doesn't meet these criteria, you have a professional responsibility to speak up and suggest ways to make things right.
  • Interfaces should be easy to use correctly and hard to use incorrectly. Scott calls this the most important general software design guideline. He suggests that you adhere to the principle of least astonishment and work to maximize the likelihood that user expectations about the interface are correct. Good names, consistency, and custom types are your friends in this arena.
  • Static analysis (the process of inspecting source code for errors) is a Good Thing. Compiler warnings, lint and similar utilities (e.g. FxCop for managed code), and code reviews are all excellent tools you have to be crazy to not use.
  • Don't impose limits when you don't have to. You know those websites that don't let you put spaces in your credit card number or assume your last name is shorter than some number of characters? Scott calls these keyholes, because they force a certain view of the world on you (as does a keyhole when you peer through it). Keyholes are Bad.
  • Don't duplicate. Need I say more?
  • Consider test-driven development and develop iteratively. These are especial favorites of mine as I've found them to have a huge positive impact on the quality of my code.

Scott finished up by reminding us that while yes, each of us is special, none of us is so special that these guidelines don't apply. Yes, even you. <g/>


*** Comments, questions, feedback? Want a fun job on a great team? I need a tester! Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. Great coding skills required.

Comments (0)

Skip to main content