Practices of an Agile Developer

• p 1 software is like surfing dynamic ever changing environment
• p 7: Start with the hardest. Always tackle the most difficult problems first, and leave the simple one towards the end
• p 12: goal of an agile team is to focus on outcomes
• p 15: pressure and dirty hack, the good programmer will go back and tries to understand the piece of code that wasn’t clear
• p 15: quick hack goes in, the clarity of the code goes down.
• p 19: Negative comments and attitudes kill innovation
• p 32: use brown-bag sessions within your team to share knowledge
• p 38: Why is a great question good for root-cause analysis
• p 42: Small, reachable goals keep everyone moving forward.
• p 42: Regular rhythms make it harder to hide things
• p 45: business analyst had fielded all the questions personally, rather than discussing them with the users.
• p 46: The most important design decision a developer (and a manager) can make is to decide what’s not in their hands and to let business owners make decisions on those issues. You don’t want to have to make decisions that are business critical by yourself. After all, it’s not your business.
• p 50: Until you cross the territory itself, you can’t reliably know what it’s going to be like.
• p 50: “The plan is worthless. The planning is essential.”
• p 60: integrate early, integrate often
• p 62: Deploy your application automatically from the start
• p 64: Requirements are as fluid as ink
• p 66: Your success in software development is based on how close you end up to your customer’s expectations.
• p 69: Show me a detailed long-term plan, and I’ll show you a project that’s doomed
• p 72: An incremental release must be usable and provide value to customers. How do you know what they’ll find valuable? Ask them.
• p 73: A software project is subject to all the simple mistakes plus fundamental changes to the requirement
• p 79: Test your boundary conditi ons.
• p 89: Hardware is cheaper than developer time.
• p 100: When developing code, you should always choose readability over convenience.
• p 121: As the caller, you should not make decisions based on the state of the
• p 124: liskov substituion principle: In other words, code that uses methods in base classes must be able to use objects of derived classes without modification. your derived class services (methods) should require no more, and promise no less, than the corre- sponding methods of the base class; it needs to be freely substitutable. This is an important consideration when designing class inheritance hierarchies.
• p 126: When using inheritance, ask yourself whether your derived class is substitutable in place of the base class. If the answer is no, then ask yourself why you are using inheritance. If the answer is to reuse code in the base class when developing your new class, then you should probably use composition instead. Composition is where an object of your class contains and uses an object of another class, delegating responsibilities to the contained object (this technique is also known as delegation).
• p 128: you can’t timebox debugging a bug
• p 132: warnings are real errors
• p 137: protype to isolate - You wouldn’t try to fix an airplane engine in midair, so why would you diagnose a hard problem in a part or component of your application while it’s working inside the entire application? It’s easier to fix engines when they’re out of the aircraft and on the workbench.
• p 146: Effective collaborative is a cornerstone of agile development
• p 148: What did I achieve yesterday? What am I planning to do today? What’s in my way?
• p 156: too many cooks spoil the broth
• p 160: be a mentor You are helping them learn how to approach the problem. They get to learn more than just the answer. They won’t keep coming to you with similar questions again and again. You are helping them function when you are not available to answer questions. They may come back with solutions or ideas you didn’t consider. This is the fun part—you learn something new as well.
• p 163: Make sure all your unit tests still pass before checking in the code. One easy way for you to make sure the code in the control system is healthy is to use continuous integration.
• p 166: how to do code reviews Can you read and understand the code? Are there any obvious errors? Will the code have any undesirable effect on other parts of the application? Is there any duplication of code (within this section of code itself or with other parts of the system)? Are there any reasonable improvements or refactorings that can improve it?