I Suck At Agile Development (Part 3)

yep, i still suck at agile development as i am still not done with the book.
so, here are some more pointers (about agile feedback, agile coding, and agile debugging):

19. put angels on your shoulders. use automated unit tests. good unit tests warn you about problems immediately. don't make any design or code changes without solid unit tests in place. unit testing provides instant feedback. unit testing makes your code robust. unit testing can be a helpful design tool. unit testing is a confidence booster. unit test can act as probes when solving problems. unit tests are reliable documentation. unit tests are a learning aid.

20. use it before you build it. write tests before writing code. use test driven development (tdd) as a design tool. it will lead you to a more pragmatic and simpler design. (in tdd, you write code only after writing a failing unit test for that code. the test always comes first. usually, the test case fails either because the code under test doesn't yet exist or because it doesn't yet contain the necessary logic to all the test to pass.)

21. different makes a difference. automate to save time. run unit tests on each supported platform and environment combination, using continuous integration tools. actively find problems before they find you.

22. automate acceptance testing. create tests for core business logic. have your customers verify these tests in isolation, and exercise them automatically as part of your general test runs.

23. measure real progress. focus on where you're going. measure how much work is left. don't kid yourself- or your team- with irrelevant metrics. measure the backlog of work to do.

24. listen to users. it's a bug. every complain holds a truth. find the truth, and fix the real problem.

25. program intently and expressively. write code to be clear, not clever. express your intentions clearly to the reader of the code. unreadable code isn't clever.

26. communicate in code. don't comment to cover up. comment to communicate. document code using well-chosen, meaningful names. use comments to describe its purpose and constraints. don't use commenting as a substitute for good code.

27. actively evaluate trade-offs. no best solution. consider performance, convenience, productivity, cost, and time to market. if performance is adequate, then focus on improving the other factors. don't complicate the design for the sake of perceived performance or elegance.

28. code in increments. write code in short edit/build/test cycles. it's better than coding for an extended period of time. you'll create code that's clearer, simpler, and easier to maintain.

29. keep it simple. simple is not simplistic. develop the simplest solution that works. incorporate patterns, principles, and technology only if you have a compelling reason to use them.

30. write cohesive code. keep classes focused and components small. avoid the temptation to build large classes or components or miscellaneous catchall classes.

31. tell, don't ask. keep commands separate from queries. don't take on another object's or component's job. tell it what to do, and stick to your own job.

32. substitute by contract. use inheritance for is-a; use delegation for has-a or uses-a. extend systems by substituting code. add and enhance features by substituting classes that honor the interface contract. delegation is almost always preferable to inheritance.

33. keep a solutions log. don't get burned twice. maintain a log of problems and their solutions. part of fixing a problem is retaining details of the solution so you can find and apply it later.

34. warnings are really errors. treat warnings as errors. checking in code with warnings is just as bad as checking in code with errors or code that fails its tests. no checked-in code should produce any warnings from the build tools.

35. attack problems in isolation. prototype to isolate. separate a problem area from its surroundings when working on it, especially in a large application.

36. report all exceptions. handle or propagate all exceptions. don't suppress them, even temporarily. write your code with the expectation that things will fail.

37. provide useful error messages. provide an easy way to find the details of errors. present as much supporting detail as you can about a problem when it occurs, but don't bury the user with it.

i'm hoping the finish the rest of the book shortly...