Ship It! - 2.6 Track Features

A new feature in your product refers to added functionality.  It’s making your product do something that it didn’t do before.  Keep a unified list of your feature requests. Prioritize them, and keep a basic estimate of the time involved to investigate or add the feature. You may also want to keep a list of the top items on your white board for better visibility.

How Do I Get Started?
Same list as with Issue Tracking.

Am I Doing This Right?

• do you use this system as a first stop when it's time to generate the next release's feature list?
• do you routinely record new product ideas in the system?
• do you reject many of the submitted feature requests?
• can you generate the last product version's "new feature" list by running a report?
• can your stakeholder easily check on a feature's status?

This is an interesting idea and I don't know if it has ever been used on my past projects.  Typically, somebody would send a document that said "build this" and we would, no questions asked.  I'm wondering what the risks are, if any, of letting your customers have access to the feature list?  Do you want to put up your ideas for a super secret project for your customers, and possible competitors, to see?

Ship It! - 2.5 Track Issues

Common questions that an issue tracking system should be able to answer:

• what version of the product has the issue?
• which customer encountered the issue?
• how severe is it?
• has the problem been reproduced in-house and by whom?
• what was the environment?
• what version of the product first exhibited the issue?
• in what version was it fixed?
• who fixed it?
• who verified the fix?

Tip 8: Avoid collective memory loss

How Do I Get Started?

• pick an issue tracking system
• set up a test system for yourself and learn how to use it
• generate a one-page quick-start guide for internal users
• start keeping all new issues in this system
• move pre-existing issues over to the new system as time permits

Am I Doing This Right?

• can you generate a list of top-priority, unaddressed issues? How about second-tier issues?
• can you generate a list of last week's fixes?
• can your system reference the code that fixed the issue?
• do tech leads use the system to generate to-do lists for development?
• does your tech support guys know how to get information out of the system?
• can your system notify interested parties so others can see when an issue is fixed?

The issue tracking systems I've used have been, at best, horrible.  I'm waiting for the project that uses a reasonable set of tools which are integrated, like the stack from Atlassian.  I think you need integrated tools to answer questions about who fixed defect A, what was the fix and what build did it show up in.  If you have to repeat yourself between tools, you are going to get lazy or forget and the information won't be available to those who might need it.

Ship It! - 2.4 Build Automatically

Rebuilding each time code is committed keeps your code base clean by catching compile errors as soon as they occur.

Tip 6: Build continuously

Tip 7: Test continuously

How Do I Get Started?

• select a build system, don't write your own
• obtain a clean machine to run on
• install your automatic build system, configure it for the environment and document every step of the install

Am I Using This Right?

• do you have tests in the system?
• is anyone paying attention to the system?
• does the build get fixed quickly?
• does your build finish in a reasonable time?

My favorite idea from this section is that a build kicks off as soon as somebody commits code.  Most projects I've worked on used scheduled builds but, like the books suggest, that allows many changes to be added which increases the time needed to figure out who broke the build.  One small project, however, did triggered builds and I really liked it.  We had to go in and modify a Subversion script to do it but it worked as advertised.  If you forgot to build everything prior to check in, the CI server told the whole world.

Ship It! - 2.3 Script Your Build

You have a problem if you do anything by hand in your build or packaging process.  Humans forget steps and lose focus - machines don't.

Tip 4: Script builds on day one

Tip 5: Any machine can be a build machine

How Do I Get Started?

• have a team member manually build the system while you take notes
• define the individual steps
• pick a build tool
• incrementally script each step eliminating manual operations one by one
• run the script on another workstation
• have another team member use the script without your help

You should be able to build your entire product:

• with one command
• from SCM
• on any team member's machine
• with no external environmental requirements, such as network drives

In Java, Ant is the defacto build tool but it can get messy pretty quickly.  Crafting if-then-else logic using XML constructs isn't pretty.  I'm glad to see tools like Gradle gaining some traction.

Ship It! - 2.2 Manage Assets

You should have everything you need to build the entire product; if you don’t, then perhaps you aren’t using the tool properly.

Tip 3: If you need it, check it in.

If you can generate it, then don't check it in.

• pick an SCM
• learn how to use it
• generate a single-page quick-start guide that shows how to use the system for common operations
• show the system to your team and make sure everyone is comfortable with it
• import your code and supporting files
• start keeping all your files in SCM

Am I Doing This Right?

• Are you actively using the system?
• How long would it take to get a new machine up and running?
• Can you perform SCM operations quickly?
• Are you backing up the SCM's repository?
• Can you check out the entire project?
• Can you look at the differences between local edits and the code in SCM?
• Can you view the history for a specific file -- who changed this file when did they do it?
• Can you update your local copy with other developer's changes?
• Can you commit your changes to the SCM?
• Can you remove the last changes you pushed into SCM?
• Can you retrieve a copy of the code tree as it existed last Tuesday? 

I agree that an SCM is extremely important to a project and it is probably software suicide not to use one.  One area of tension I've run into regarding the "if you need it, check it in" rule was around libraries.  One project I worked on stored any dependent libraries right next to the source which was great.  The build was easy to reproduce, partly due to this fact.  As the project grew and many releases went out the door, our disks started filling up -- fast.  For each branch you checked out you got a new copy of log4j plus the 800 other libraries.  Developers checking out over slow WANs really complained because it could take hours to move files around.  I suggest thinking about what happens when you start branching your code as you implement the "if you need it, check it in" rule.

Ship It! - 2.1 Develop in a Sandbox

Isolate others from the effect of your work until you are ready. Code is shared via the repository. The build machine is an unattended server that simply gets all of the latest source code from the repository, builds, and tests it, over and over again. The result of this build is the product release.

Tip 2: Stay in the sandbox



Luckily, I've been in environments that used an SCM and some even ran CI servers.  None of them, however, consistently ran tests as part of the build but I can see the benefit of doing so.

Ship It! - Chapter 1

Ship It!: A Practical Guide to Successful Software Projects by Jared Richardson, Will Gwaltney, Jr is a book that presents some ideas on software practices that can help keep developers, managers and customers happy about the software being produced.  The practices are based on real-world experience and are not part of an overall methodology -- you pick and chose the practices that make sense to you and your team.  I plan on summarizing chapters as I read them.  I feel it helps me to better understand the material because I have to take the time to think about the messages the book is trying to convey and pick out the highlights.  Let's get started.

Habitual Excellence
 Extraordinary products are merely side effects of good habits. Purposely seek out good habits, and add them to your daily routine.  I agree with the idea that it is the things you do routinely  that determines how effective you are in your daily situations so it makes sense to try an cultivate "good" habits.

Tip 1: Choose your habits.

A Pragmatic Point of ViewThe book is a collection of good habits and it is never too late to install good habits.  Hopefully, the habits won't be too painful or expensive to implement.

Road Map

• Infrastructure
• Techniques
• Process
• Common Problems and How To Fix Them

Potentially, the last section might be most interesting.  I'm sure I'll have seen some of the practices that will be suggested but haven't been able to implement for one reason or another.  I'll be curious to see what some possible solutions are.

Moving On
Try out the ideas and discard the ones that don't work for you. Make sure you understand the benefits before proposing a technique.  It is nice to see that it isn't an all-or-nothing mentality.  I'm guessing that that the more practices you adopt the more benefit your project will see but every team is different so you've got to see what works for you.