Ship It! - Summary

I really enjoyed reading this book.  It isn't huge tome and makes you think.  I like the fact that they an a la carte way of looking at process.  I think that the discussion around Tracer Bullet Development to be particularly interesting.  I think this book is worth the time and money so go out and buy yourself a copy.

Ship It! - 5.18 We're Never Done

How do you decide what to do? Use The List to break down the product into individual features. You’ll know your project is finished when all the features on The List are implemented and are working well together (of course, feature integration should be one of the tasks on The List!).

Feature list guidelines:

• Break down any item with a time estimate of more than one week into subtasks. It’s okay to have a top-level task that takes weeks or months, but that estimate is just a guess unless you back it up with estimates for its subtasks.
• Any item that takes less than one day is too small. If an item can be scheduled for a time period shorter than a day, that item is probably too low-level for The List.
• A single customer example (or use case or scenario) can involve multiple features in The List. Don’t try to force an entire example into a low-level item in The List; break it into subtasks.
• Add priorities to the items on The List, then stick with them. Don’t work on a priority-two item while there are priority-one items that are unfinished. But feel free to change those priorities as it becomes necessary.
• Assign specific people to each feature on The List. You can do it on the fly (as one person finishes a task, they “sign up” for another), or you can assign them all up front, and then change them as necessary. It depends on how your team works best.
• Be flexible. Use change to your advantage. Changing The List means that you’re improving and refining it, that you’re getting customer feedback, and that you’re matching The List with the real needs of your customers.

Tip 40: The list is a living document.  Change is life.

Don’t just remove an item from The List after it’s finished. Keep a copy of completed features (along with dates, priority, and assigned developer) to use as your audit trail. When you’re asked, “Why didn’t feature X go in?” or “What features did go in?” The List will give you the answers.

Tip 41: If it's not on The List, it's not part of the project.

Tip 42: Always give feedback fast

Ship It! - 5.17 Features Keep Creeping In

When someone requests a new feature, look at the tasks your team is currently implementing. Is there time to implement the new feature before the next delivery? Will the new feature work with the already-scheduled features? Will it even make sense in the context of the planned product?If the answer to these questions is “yes,” then by all means add the feature to The List. Decide how important it is compared to the other features, and assign it a priority and a developer to implement it.However, if the answer to one or more of these questions is “no,” then don’t add the feature, regardless of the pressure you get from the requester. Instead, gently but firmly use The List to explain why you won’t implement the feature.

Ship It! - 5.16 We're on a "Death March" Project

First, create a new project schedule. Use The List, and put time estimates on each item. Be sure these are realistic time estimates, not Death March estimates. Work with your tech lead to get the priorities correct and in line with management. Second, with the time estimates on The List, put together a time line for the project. Publicize this schedule. Put it on your white board or your web site. Often schedule makers create time lines simply because they don’t understand the work involved. Help them understand. Once you have a better idea of how much work you can reasonably accomplish, show the time line to your manager. Tell them you think the project is in trouble. Management may not be happy with your predictions, but happiness isn’t the goal. Try to show them that if the schedule doesn’t match reality, the schedule can’t be met (although in some situations, it may be decided to keep the bad schedule for other reasons). Now at this point, you’ve got two choices: move the date or drop the features. If you decide to move the date, keep an active copy of The List so that nobody can add features without adjusting the time line again.

Ship It! - 5.15 We're Junior Developers, With No Mentor

First, get your team lead or manager to start holding daily meetings with your team. Second, introduce code reviews, and make sure you or one of the other seniors attend each review.

Ship It! - 5.14 There's No Automated Testing

The biggest complaint that people have about automated tests is that maintaining them is too much trouble. Before you start writing and committing tests, be sure that you have a CI system in place. Set it up to run the tests every time the code changes. If you have test code that you’ve been running manually, port it to the CI system. Write your tests using mock client testing to get the maximum return for each test. It’s too late for you to write a unit test for every method in your code. Mock client tests are more efficient because a single test exercises a lot of code. Identify the tests to write using defect-driven testing This will let you add tests where they can do the most good. Only add a test if there is an active bug there right now. This means that any test you add will address the most current issues in your code, and you’ll get the maximum possible benefit out of every test.

Tip 39: Test where the bugs are

Getting people to use sound engineering practices even for silly old test code is important.  Brittle tests are more likely to get turned off -- which helps nobody.

Ship It! - 5.13 The New Practice Didn't Help

When Not to Introduce a Practice
Don’t try to introduce a new practice or process if there isn’t a problem that needs fixing. Never introduce a change because it’s “the right thing to do.” Instead, identify the actual problems in your shop, and then figure out how to fix them.

Tip 34: Only fix what needs fixing

Tip 35: Disruptive "best practices" aren't!

And of course, make sure the practice or process you’re considering will actually improve things. If it won’t make things run faster and more efficiently, your team won’t (and shouldn’t!) adopt it.

How to Introduce a New Practice
There are two main things you’ve got to do: demonstrate and persuade. You’ve got to get buy-in from several groups of people. First and foremost are the people who will actually be practicing the new practice, namely, your team. If they aren’t excited about it, it won’t matter if anyone else is.

Tip 36: Innovate from the bottom up

Show them the process or tool; don’t just tell them about it. In particular, show them how well it works, especially in comparison with the old way of doing things. The key is to prove that this new-fangled idea is everything you say it is.

Tip 37: Show, don't just tell

Tip 38: Cultivate management buy-in

I've personally done the show-don't-tell tactic and it works.

Ship It! - 5.12 Can't Get "Buy-In" on Essential Points

Sell the new practice or process to the team; don’t just dictate policy. Don’t just preach it; demonstrate it. People respond to a working example more often than to a lecture, no matter how good the concept. Make it easy for your team to change. Give them extra time to come up to speed on the new practice. Get them books or training if they need it. And choose the right time to introduce the new practice or process. Show your team how these practices benefit them personally.

I always had more respect for the lead-by-example type of person.

Ship It! - 5.11 Team Doesn't Work Well Together

• If you don’t already have them, start daily meetings or get your manager to do so.
• Have team members review each other’s code before commits.
• Meet once a week for lunch.

Ship It! - 5.10 Your Manager Is Unhappy

How do you keep your manager happy? It comes down to one word: communication.  Make sure your manager always understands what you are doing and why.

• Use The List and get your manager to review it
• Keep your manager up-to-date with your progress 

Tip 32: Publicize what you're doing and why

Ship It! - 5.9 You've Got a Rogue Developer

This particular problem can be solved only by the manager.

A Manager can:
• Use daily meetings to correct a rogue developer’s course.
• Hold the rogue developer to the tasks on The List.
• Use code reviews and automatic code change notifications to track
  a rogue developer’s work.
• Use CI as a last resort to monitor a rogue developer’s work.

Ship It! - 5.8 Customers Are Unhappy

Get the customer to work alongside you to help define the product while managing their expectations about what’s possible and what’s not. Don’t just get their input at the beginning of the project; keep in touch throughout the development process. So how do you communicate the project status to the customer? One of the best ways is to create a live system that can be used for demonstrations as early as possible, even if the feature set is incomplete. This is true whether the product has a GUI or is a set of application programming interfaces (APIs). Every time your team completes a new feature, add it to the demo program so the customer can see it and give you feedback.

Tip 31: Deliver live demos early and often

How do you communicate with the customer between releases of the demo? Encourage the customer to check The List as often as possible, and keep it up-to-date so they can see it change. Invite the customer into your development world so that they can see your direction and your problems. A customer is more likely to accept a delay if they understand what caused it. Also, encourage them to suggest changes to The List. If they don’t like the way the project is going, they should ask for you to change it. After all, they’re paying the bills. If they frequently communicate their needs and your team continually adjusts the product to meet them, then the end result should make everyone happy.

Ship It! - 5.7 Can't Build the Product Reliably

Solution: understand the build and then script it. Besides increasing reliability, automated builds add a professional finish to your product, ease the transition for new team members, and let you easily use a CI system.

Ship It! - 5.6 It Hurts When I Integrate Code

How do you keep code integration from becoming an ongoing nightmare? The solution is simple: integrate your code more often to reduce collisions and simplify merges. Use a CI system to verify that things still work.
 
Tip 30: Integrate often, and build and test continuously

I used to work with a guy who synced his source area once a month and created headaches for both himself and the whole team.  That is when I learned to do frequent, small integrations.

Ship It! - 5.5 But It Works for Me!

If you can’t reproduce a bug on your own machine, the build machine is your insurance policy. Use it to verify bugs that you can’t reproduce on your workstation. Once you duplicate the bug on the build machine, figure out what’s different on your system. Once you’ve duplicated the bug, craft a test to expose it, and then run the test on the clean box. If you write the test carefully, you can even send it into the field to see if the customer can duplicate your results. Of course, if you can not reproduce the bug on the build machine either, then perhaps the customer has a configuration problem on their own machine. Start asking questions about the environment they’ve set up.

Tip 29: It has to work for everyone

I think it is irresponsible and lazy for developer to give up and say "it works on my machine" but I see it all the time.

Ship It! - 5.4 Tests? We Stopped Using Them

When that happens, it’s time to start again. Perhaps no one was using the tests because they weren’t getting benefit from them. Normally the benefit is immediate and obvious, but there is an upfront cost to get started (or restarted) that you just have to put up with. The other problem you may face comes later in the project’s life. The more tests you add, the more time it takes to run them after a compile. At some point, you may not be able to run all the tests every time. Which tests should you pick to run continuously? Choose those tests that best exercise the code that is being actively developed. When you notice that a test is broken in nightly or weekly builds, move it to the CI test suite so it can be run more frequently.

Tip 28: Continuously test changing code

Until you have a CI environment that builds your product after each code change, you won’t be testing your code often enough. Even a daily build is not sufficient.

I've found that some developers, myself included,  don't use the same care when writing test code that they use when writing production code.  This tends to make the tests brittle and people get pissed when the test code breaks due to some sort of interface change.  It takes some effort but if you can avoid cranking out tests using cut-n-paste then your tests are easier to fix if something changes on you.

Ship It! - 5.3 Features Keep Breaking

What’s the quickest way to fix this problem? Add an automated test suite. A mock client test suite is your best choice to get the product or platform stable as quickly as possible. Mock client tests exercise the most lines of code in the least amount of time.

Tip 27: Mock client tests do the most with the least

Not much to say here other than I know this works, but takes time and effort.

Ship It! - 5.2 Testing Untestable Code

Tell your manager you want to start test driven refactoring. You want to start adding the simple hooks to your application that make it possible (or feasible) to do good automated testing. First, create (or borrow) a test plan for the product. Keep the plan simple at first. Don’t try to make it perfect on your first attempt. Shoot for a simple pass that exercises basic functionality. Second, write an automated test. Make the test go as far as you can. When you get stuck, what’s the least amount you can add to the product’s code to get the test running? Is it just a return code to an existing API or an “id” tag for an HTML field? Don’t try to fix every problem with your first pass. Don’t try to add “id” tags to every page in your product; shoot for the one page you need to get the test passing. If your test plan hits a roadblock, don’t stop. Remove the part of the test plan you can’t test and move on. Remember that you can also add the hard part to your next test plan.

Tip 26: Use test driven refactoring to clean up untestable code

Ship It! - 5.1 Help! I've Inherited Legacy Code

How to tackle this problem:

• build it - First, figure out how to build it, and then script that build process. After that, it should be easy to automate the builds.
• automate it -Your goal is to automatically build and test the entire product on a clean machine with an absolute minimum of manual
  intervention. Document all the build steps and make this documentation publicly available.
• test it - Figure out what the code does, then begin testing by writing mock client tests for it. Once you have the project building cleanly, you’ll want to confirm that it works. In order to write the tests, you’ll have to learn exactly what the product is supposed to do (no surprise there). Mock client tests are a good starting point: they test the broad functionality of a product because they act just as a product user would.
• test it more - Figure out the product’s innards (things such as structure, flow-of-control, performance, and scalability), and write more tests for it. Unless the product is completely unused, there will be bugs you’ll need to fix (or at least document) or enhancements you’ll have to make. Normally these changes are a pretty scary thing to do to legacy code, because you’re never quite sure what you’re going to affect when you make a code change. But you can do this fearlessly because of the mock client tests you wrote as a safety net; they’ll keep you from breaking things too badly. Write a new test for every bug you fix and for every enhancement you add to the product. The type of test you write will depend on what you’re changing (e.g., a unit test for a low-level internal change, or a mock client test for a new feature). At this point you’re treating the legacy product in the same way you would any other product you support.

Tip 25: Don't change legacy code until you can test it

I find that testing a new code base forces me to understand the system.  I suppose the added benefit of writing tests for known bugs forces me to understand the defect tracking system as well.

Ship It! - 4.8 Selling Tracer Bullets

The primary benefits of TBD are:

• teams can work in parallel
• can see a working system earlier
• momentum, people like to make progress
• testing can begin just after the interfaces are defined
• easier to move people between layers because they have a basic understanding of what each layer is supposed to do

TBD Sequence:

• propose system objects (layers)
• propose interfaces
• connect interfaces
• add functions
• refactor, refine, repeat

Tip 24: You can't steer a boat unless it is moving

The main idea behind Tip 24 is that if your development progress is slow, you won't get timely feedback making it difficult to correct course.

How to Get Started:

• try it out
• discuss the concepts with the team first
• define system objects
• define interfaces between them
• write the interface stubs
• make the stubs talk with each other
• fill in the stubs with functional code

You Are Doing It Right If...

• the entire system is always up and running
• team members understand the system objects as well as "their" objects
• team members feel comfortable helping out wiht other system objects
• you can rewrite large portions of your code base and nothing breaks

I really like the idea of TBD.  I've operated in a similar manner on small projects just to see how stuff would "hang together" and enjoyed the process.  You run across stumbling blocks sooner and it feels good to have a working system that you can demo at a moments notice.  I'm curious to see how it functions on a larger scale.