97 Things

Making time to read one article everyday from 97 Things Every Programmer Should Know (book format or online) and write about it the following day or soon after.  Advice I've read so far:

• "Act with Prudence" - one way (not perfect) to keep track of technical debt is to use TODOs in the code.  The text associated with a TODO should be specific enough so that someone else reading it in the context of the code understands what still needs to be done.  
• "Apply Functional Programming Principles" - (a) indeed, as the author Edward Garson states, mis-use of object-oriented programming creates bad designs.  In particular, IMO, the difference between using setters versus parameters to a method is not entirely clear.  The advent of Spring also has popularized the use of setters although Spring can just as easily work with constructors so that when an object is instantiated, its state is correct and it is ready to be used.  My rule of thumb is when in doubt, use parameters to a method to pass arguments, not with setters.  (b) As the author also states, test-driven design also helps to promote better design.  IMO it is because as you write automated test cases, you become a user of your API ("Eating your own dog food" principle), and you begin to understand what makes an API easier/cleaner to program against.