Ship It! - 3.6 Putting It All Together

This chapter is a summary of stuff we've learned so far.

The List

• publicly available
• prioritized
• on an estimated time line
• living

Tech Lead

• manages project's feature list
• tracks developer's current tasks and status
• helps assign priorities to each feature
• insulates the team from external distractions

Daily Meetings

• keep them short
• require specifics
• list problems, but don't solve them

Code Reviews:

• small amount of code reviewed
• one or two reviewers
• happen frequently
• don't publish code without a review

Code change notifications:

• email and publish notifications
• list the reviewer's name
• list purpose of the code change or addition
• include the diff or file itself, size permitting

Ship It! - 3.5 Send Code Change Notifications

When you edit code, an automatic build system can notice the change and rebuild the project. Your next step is to publish that information so that every member of the team knows what changed. A change notification system pushes this information out to your entire shop, not just your immediate co-workers. The preferred way is to have your changes automatically emailed to each team member. Most automatic build systems will send changes for you (and they’ll usually publish your changes to a web page and RSS feeds as well). Change notifications should go out to your team each time code is checked into the source code management system.  Notifications should include:

• Reviewer’s name.
• Purpose of the code change or addition (for instance, which bug you’ve fixed or which feature you’ve added).
• Difference between the new code and old code (Any major source code management system will generate this report for you.) If you’ve completely rewritten a block of code so large that it would make a diff meaningless, just include the new code. The same applies to new files.

How to Get Started:

• A program that watches your SCM generates notices and sends emails.
• Make sure your team knows about the notifications before they start arriving.

You're Doing Right If...

• Notifications must be regular and trustworthy.
• Don’t send out five-megabyte diffs!

To make this work you would need to customize your SCM a bit.  You'll need something to trigger the CI server when a commit occurs.  You'll also need to put something in that verifies that the requisite data is in the check comment.  One question I have is around the volume of information that could be generated.  Changes to one branch of the code might be okay but what if there are multiple branches?

Ship It! - 3.4 Review All Code

Can be painless if:

• Only review a small amount of code.
• There are one or two reviewers at most.
• Review very frequently, often several times a day.

To avoid MAD (Mighty Awful and Dreaded) reviews, separate your work into the smallest possible pieces and get each one reviewed independently and committed into the source code repository. Then if there’s a problem with any one area, it’s easily isolated. A good rule of thumb, however, is to never work for more than two days without getting a code review. Ideally there will be one review for each feature you add (or for each bug you fix).

Tips:

• Code reviews must involve at least one other developer. 
• Do not make code publicly available without a review. Don’t add your changes to the source code from which your product is built until a review has been done. Part of the comments you include with the code’s check-in should list your reviewer’s name. Then, if there are questions about the reason for the code change and you’re not around, there is a second person who should be able to explain it (at least at a basic level).
• Never use this code review rule as an excuse to not check in your code. If your company has a source code system that holds only production code, then put your code into a private area until it’s ready. This private area might be a separate code repository or another installation of the source code management system. Use whatever tools you need to get the code off your machine so that when your machine dies (as machines are prone to do), your code doesn’t die with it.
• Reviewers maintain the right to reject code that they find unacceptable.  
• If your code can’t be explained at a level the reviewer can understand, then the code must be simplified. As a reviewer, don’t sign off on anything you don’t understand and feel comfortable with. After all, your name is associated with this code as the reviewer.
• Any code changes that are made can’t break any existing automated tests. Don’t waste your co-worker’s time asking for a code review if you haven’t yet run the tests. If you require existing tests to be updated, make the changes to those tests a part of the coding before the review. Any new tests that you are adding should be a part of the review as well. As a reviewer, always reject code changes if you think more tests are necessary.
• Rotate the reviewers you use, but don’t be religious about it.
• Keep code reviews informal.
• When you introduce the code review process, you may need to appoint a few senior team members to be the mandatory reviewers; one of the senior team members must participate in every review at first.

Tip 17: It's okay to say "later"

Your management must require code reviews. If there’s no management buy-in, no one in your shop has any official motivation to participate. In other words, if no one has been told to help you, they probably won’t make time to do it, especially when deadlines are tight.

Tip 18: Always review all code

How to Get Started:

• Be sure everyone understands the type of code review you have planned. Review frequently on smaller blocks of code. Don’t wait for weeks, accumulating hundreds or thousands of lines of changes. No MAD reviews for your team!
• Have one of your senior team members sit in on each code review for the first few weeks or months. This is a great way to share knowledge and get the reviews on a solid foundation.
• Make sure your code reviews are lightweight. It’s better to review too little code than too much. Having two overlapping reviews is better than having one larger one.
• Introduce a code change notification system  at this time. It’s a great complement to your code reviews, and it helps to remind team members who forget to ask for reviews.
• Make sure you have management buy-in before requiring all team members to participate. 

You're Doing It Right If...

• Do code reviews get an automatic approval? This shouldn’t happen unless everyone on the team is perfect.
• Does every code review have major rewrites? If so, it indicates a problem somewhere: either with the coder, with the reviewer, or with the tech lead (who gave the directions that the coder and reviewer are using).
• Do code reviews happen frequently? If the time between reviews is measured in weeks, you’re waiting too long.
• Are you rotating reviewers?
• Are you learning from the code reviews? If not, start asking more questions during your code reviews.

Wow.  I'm thinking code reviews is an area where there will be much resistance.  Only one of my past shops did code reviews and I can't even remember if it helped quality.  I do remember, however, people getting pissed because they couldn't check in their code in time for a build due to a failed review.  They got angry because the coder disagreed with the reviewer that the code should not be allowed to go in over a "minor" issue.  I'm wondering if automation can be of any help here?  There are tools that can check for silly code style violations, like where the curly braces go, which might lessen the reviewer's load.  There are also tools like FindBugs that can detect threading issues which, again, might lighten the reviewer's load.

One thing I'm wondering about is how to avoid checking in code without a review, especially when working with remote developers?  Do I keep my own branch that gets merged with the trunk every day?  I could check in my proposed change into the branch, have it reviewed and then merge it into the trunk if it passes inspection.  E-mail the files? Are there other techniques?

Ship It! - 3.3 Coordinate and Communicate Every Day

Each team member briefly shares what they are working on and what problems they’ve run into. A good rule of thumb is to spend no more than one to two minutes per person. Remember that this meeting has the entire team tied up, so be mindful of the burn rate; keep it short and to the point.

Tip 16: Use daily meetings for frequent course corrections

How to Get Started:

• Be sure everyone knows the format (which questions you want answered).
• Everyone must answer the questions. There are no passes, and no exceptions.
• At first, be lenient on the time restriction. A lot of new information is exchanged in the beginning, so you must allow communication to flow freely.
• Hold your meetings at the same time and in the same place, every day. Make daily meetings a habit, not a chore to keep track of.
• Post topics that are discussed during daily meetings on a web page  or plog (project log).
• Pick a person to start the meeting, and then move clockwise (or counterclockwise) through the group. Randomly picking one team member after another is more apt to make them feel ambushed. 

You're Doing It Right If...

• Are the meetings useful? If no one in the group is learning anything, the reports might be too terse. If more details are needed in a particular area, push those topics into a side meeting with a smaller group. However, the two-minute rule is a guideline, not a law. You may find thirty seconds is just fine, or you may need three minutes.
• Are meetings consistently held the same time and place every day, or do they fluctuate? Having daily meetings at the same time and place makes it easy to remember. Meetings can move occasionally, but avoid mixing things up frequently.
• If you stopped holding the meetings, would people complain? They should! The team should come to depend on the daily meeting to stay “in the loop.” If the meetings can be dismissed, then they weren’t providing value. The team should rely on the daily meeting as an invaluable resource.

I've never participated in daily meetings but I have worked in environments where people worked in a vacuum.  I'm thinking short, daily meetings is the way to go.

Ship It! - 3.2 A Tech Leads

Your Tech Lead both oversees and carries the technical responsibility for your software project. Having a Tech Lead frees up your manager to handle bureaucratic matters while delegating the technical aspects to someone who’s better equipped. A tech lead does the following:

• Make sure your team’s work priorities are in line with customer needs
• Ensure that your team’s work is properly represented to management
• Insulate your team from non-technical upper management
• Relay technical issues to nontechnical stakeholders
• Present nontechnical concerns to the development team

Tech Lead's Responsibilities include:

• Set direction for team members
• Orchestrate your project’s feature list
• Prioritize your project’s features
• Insulate your team from external distractions

Priorities Defined:

• P1 - Required. These are the features that you absolutely cannot ship without.
• P2 - Very Important. You could ship the product without completing these items, but you probably won’t.
• P3 - Nice to Have. Given time, you will complete them, but these items never delay a ship date.
• P4 - Polish. These items add a finished feel to your product.
• P5 - Fluff. If you have time to add “fluff” features, then you are ahead of schedule and under budget.

Tip 15: Let a tech lead

If you aspire to be a Tech Lead, you need to prove you’re ready to handle the additional responsibility. Look over the job requirements, and strive to live up to them. Voluntarily perform as many of the tech lead duties as you can. Don’t wait for the job to fall into your lap; demonstrate that you are trying to earn the position and can handle it well.  Use The List  for your personal work but also keep one for your team. Monitor work in progress while keeping an eye on upcoming projects.  Evaluate your team’s process. Locating the weak spots and finding practices or concepts to address problems will give you a new perspective. Don’t give up if you aren’t promoted to tech lead right away. Continue learning and growing for the next assignment. Not everyone has the temperament for a tech lead role, but working toward it gives you a broader picture of the entire project, which makes you a more productive team member. You become a better developer by thinking about and considering how you’d be a tech lead.

If you’ve just become a tech lead, create a rough road map. Chart where the team currently stands and the direction you want them to go. What problems will you address? What work will you encourage? Make a list of all known problems. Then survey the team to see if they know about additional problems. When you think you’ve arrived at a real list, decide which items you can address and which you can’t. Daily meetings are a great way to keep track of your team’s work without smothering them.

You're Doing It Right If...

• Do you know what every member of your team is working on?
• Can you generate a project status summary in less than five minutes?
• What are the next five to ten features for your product?
• Can you readily list the highest-priority defects for your product?
• What was the most recent problem you cleared up for a team member?
• Would a team member come to you if they needed an important issue resolved?

Ship It! - 3.1 Work from The List

The List is how you set your daily and weekly agendas. You order your work with The List, as does the entire team. When you get swamped, overwhelmed, or scattered, you come back to The List and use it to regain your focus. If you get stuck on a tough problem and you need to step away for a while, The List gives you a readily available set of items to use as filler. This ensures that you’re working on the most important item, rather than the proverbial “squeaky wheel.”  Since all developers are at different skill levels, the tech lead makes exceptions as needed, but generally, no second-priority item can be touched until the first-priority items are complete. The List (as a team tool) gives management and customers something concrete to look at and evaluate the product before the time is invested adding the features.

Tip 14: Work to The List

Getting started with your own copy of The List is easy. First, create a list of every task you are working on (or have pending). Then, with your tech lead, assign a priority to each item. Finally, put a time estimate with each item. Don’t worry about getting the time estimates perfect the first time, you’ll improve over time.

For the team:

• Put every feature that you are adding to your project on a white board
• Assign priorities to each feature. Be sure to include the proper stakeholders (management, customers, etc.) in this process.
• Rewrite all of the features, sorted by priority
• Attach time estimates to each item

Until the current top priority items are completed, no one can work on the lower-priority items. This ensures that all the priority-one items are in progress before any of the priority-two tasks are touched.

The List must be:

• Publicly available
• Prioritized
• On a time line
• Living
• Measurable
• Targeted

How to Get Started:

• For an entire day, write down every task as you work on it (this will be your “finished” list).
• Organize whatever daily task list you do have into a formal copy of The List.
• Ask your tech lead to help you prioritize your work and add rough time estimates.
• Start working on the highest-priority item on The List—no cheating! If some crisis forces a lower-priority item higher, record it.
• Add all new work to The List.
• Move items to your finished list as you complete tasks (this makes surviving status reports and “witch-hunts” much easier).
• Review The List every morning. Update it whenever new work pops up. . . especially the last-minute crisis tasks; you’re likely to forget about those when someone asks you what you on earth you did all last week.

You're Doing It Right If...

• Is every one of your current tasks on The List?
• Does The List accurately portray your current task list?
• Did the tech lead or customer help you to prioritize The List?
• Is The List publicly available (electronically or otherwise)?
• Do you use The List to decide what to work on next?
• Can you update (and publish) The List quickly?

I'm a fan of lists but have never used them in this way.  I can see the benefit of getting my manager to help me prioritize things and it should be able to help keep an entire team on track.  My question is this: what is a good tool for making The List?  Is a wiki with RSS publishing good?  Is a white board good?  Project planning software?

Ship It! - 2.8 Choosing Tools

Be sure your tools use an open format like XML or plain text.  It makes integration and reporting easier.

Tip 11: Use the best tool for the job

Tip 12: Use open formats to integrate tools

Never have a vital part of your product cycle (such as the build system) written in a niche or non-core technology, especially if only one developer knows it. Use a technology that anyone in the shop can configure and maintain.

Never let a critical technology (like your build system) be created as a technology experiment. Use a tool designed for builds to create your builds, not the cool new technology that a team member wants to learn. There are plenty of non-critical areas for technology learning to take place. Never create automated tools that run on only one machine. Never hard-code dependencies, such as network drives. Put everything you need in your SCM system, and the network drives become unimportant.

Tip 13: Keep critical path technologies familiar

I must admit I'm a tinkerer and need to be aware of introducing shiny new things at the wrong times.  I've also been on the other end of the stick where I had to use a sub-system written in a technology that I wasn't comfortable with. Only the author knew the technology and we ended up using something that more people understood.