What do you think?
Rate this book
Ship it! A Practical Guide to Successful Software Projects
Ship It! is a collection of tips that show the tools and techniques a successful project team has to use, and how to use them well. You'll get quick, easy-to-follow advice on modern which to use, and when they should be applied. This book avoids current fashion trends and marketing hype; instead, readers find page after page of solid advice, all tried and tested in the real world. Aimed at beginning to intermediate programmers, Ship It! will show Few of the ideas presented here are controversial or extreme; most experienced programmers will agree that this stuff works. Yet 50 to 70 percent of all project teams in the U.S. aren't able to use even these simple, well-accepted practices effectively. This book will help you get started. Ship It! begins by introducing the common technical infrastructure that every project needs to get the job done. Readers can choose from a variety of recommended technologies according to their skills and budgets. The next sections outline the necessary steps to get software out the door reliably, using well-accepted, easy-to-adopt, best-of-breed practices that really work. Finally, and most importantly, Ship It! presents common problems that teams face, then offers real-world advice on how to solve them.
208 pages, Paperback
First published June 1, 2005
19 people are currently reading
901 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 39 reviews
May 5, 2014
Asinine, unambitious, narrow, incomplete. Some of the groundbreaking advice contained herein:
- Sort your work by priority and do the highest priority ones first.
- Do a high-level class design before you write object-oriented code.
- Adhere to standard object-oriented encapsulation.
- Talk to other developers about how your code needs to fit into theirs.
- You should test your code changes before you go live.
- Have you about this new "source control" thing?
Here's a direct quote:
"Don’t have much money in the budget for training? Then point your team at the Internet, and turn them loose. These days there’s more information about anything on the Internet than anywhere else, and most of it is free. (Of course, you can’t believe everything you find there; take what you find with a grain of salt.) So don’t limit your team’s access to the Internet. Sure, they might surf some non-work-related sites, but the good stuff they find will more than make up for it."
I'm not just being a jerk, right? Doesn't it feel a little weird to be advised to look things up on the Internet? Who needs to be told this? What do they mean "these days"? The Internet has been full of free advice on programming LITERALLY since it began.
It's hard to believe that a developer at a high enough level to apply this kind of advice would even need it. I know the book's from 2005, but come on. This is written for an audience who somehow knows how to program but knows nothing about completing projects with more than one step involving more than one person, who now somehow landed a development job at a company full of people equally as clueless and with no desire to collaborate. That has literally never happened.
I'm setting aside the fact that "software projects" of the book's subtitle often involve things like "maintenance" and "administration", which involves tasks that fall almost completely outside of the rubrics suggested in the book.
Sorry, I just don't get it.
- Sort your work by priority and do the highest priority ones first.
- Do a high-level class design before you write object-oriented code.
- Adhere to standard object-oriented encapsulation.
- Talk to other developers about how your code needs to fit into theirs.
- You should test your code changes before you go live.
- Have you about this new "source control" thing?
Here's a direct quote:
"Don’t have much money in the budget for training? Then point your team at the Internet, and turn them loose. These days there’s more information about anything on the Internet than anywhere else, and most of it is free. (Of course, you can’t believe everything you find there; take what you find with a grain of salt.) So don’t limit your team’s access to the Internet. Sure, they might surf some non-work-related sites, but the good stuff they find will more than make up for it."
I'm not just being a jerk, right? Doesn't it feel a little weird to be advised to look things up on the Internet? Who needs to be told this? What do they mean "these days"? The Internet has been full of free advice on programming LITERALLY since it began.
It's hard to believe that a developer at a high enough level to apply this kind of advice would even need it. I know the book's from 2005, but come on. This is written for an audience who somehow knows how to program but knows nothing about completing projects with more than one step involving more than one person, who now somehow landed a development job at a company full of people equally as clueless and with no desire to collaborate. That has literally never happened.
I'm setting aside the fact that "software projects" of the book's subtitle often involve things like "maintenance" and "administration", which involves tasks that fall almost completely outside of the rubrics suggested in the book.
Sorry, I just don't get it.
June 19, 2010
"Ship It! A Practical Guide to Successful Software Projects" by Jared Richardson and William Gwaltney Jr. is a bit of mixed bag. There is good stuff in there, but the book tries to be too much and as a consequence it is at times too sketchy and incomplete. In addition the authors prescribe techiques that are not always appropriate.
The book covers three software engineering topics: tools, project techniques and a methodology. The chapter on tools and infrastructure is solid. They recommend that you implement developer sandboxes, software configuration management, scripted builds, continuous integration, issue and feature tracking systems and automated testing on your projects and I agree. In any project of more than a trivial duration where there are no huge technical barriers due to the products you are working with you should implement all of them.
The chapter on project techniques is less convincing. Some of the techniques are unproblematic. Having a short meeting every morning to make sure that everyone is on the same page and sending code change notifications for instance. Others seem to prescribe a way of working that might not be the best in your case.
For instance they have a simple scope management technique the call "The List", which is essentially just that, a list of all the work that needs to be completed. On small projects this probably works okay, but when projects get big you might be better off with a work breakdown structure and a schedule with dependencies all that.
Another example is their recommendation for frequent, short and informal code reviews. Collaborative development techniques such as code reviews is a good idea. Research has shown that this is the most cost effective way to increase software quality. However, research also shows that formal inspections are even more effective. In cases where high quality is important, it would probably be a better option.
The chapter also seems a bit incomplete. It seems like an embryonic agile method. Another reviewer noted that when the book was written methods such as Scrum were not yet established. In my opinion, you are probably better off with Scrum if you decide that agile is appropriate for your project.
Their project method on the other hand is interesting. Unfortunately the chapter describing it is a bit too sketchy for my taste. Also, it is more of a software integration strategy than a full-blown software engineeering methodology. They call the method "tracer bullet development", named after the bullets that allow you to see where you are firing your machine gun in the dark.
Essentially you start by dividing your system into layers, e.g. the GUI layer, the business logic layer and the data access layer. Then, you identify you system objects in each layer and the interaction between them. These objects and their interfaces are then implemented as stubs and integrated into a "working" system. Then you start filling in the blanks and elaborating the interfaces, keeping the system integrated all of the way. This strategy has several benefits. Having done the integration up front, you avoid the nerve-wracking tying together of components at the end of the implementation. The interface-orientation promotes cohesion and loose coupling, making the software more robust and scalable.
All in all, there is good stuff in there, but one has to wonder whether the book was the victim of time-boxed development and premature shipping.
The book covers three software engineering topics: tools, project techniques and a methodology. The chapter on tools and infrastructure is solid. They recommend that you implement developer sandboxes, software configuration management, scripted builds, continuous integration, issue and feature tracking systems and automated testing on your projects and I agree. In any project of more than a trivial duration where there are no huge technical barriers due to the products you are working with you should implement all of them.
The chapter on project techniques is less convincing. Some of the techniques are unproblematic. Having a short meeting every morning to make sure that everyone is on the same page and sending code change notifications for instance. Others seem to prescribe a way of working that might not be the best in your case.
For instance they have a simple scope management technique the call "The List", which is essentially just that, a list of all the work that needs to be completed. On small projects this probably works okay, but when projects get big you might be better off with a work breakdown structure and a schedule with dependencies all that.
Another example is their recommendation for frequent, short and informal code reviews. Collaborative development techniques such as code reviews is a good idea. Research has shown that this is the most cost effective way to increase software quality. However, research also shows that formal inspections are even more effective. In cases where high quality is important, it would probably be a better option.
The chapter also seems a bit incomplete. It seems like an embryonic agile method. Another reviewer noted that when the book was written methods such as Scrum were not yet established. In my opinion, you are probably better off with Scrum if you decide that agile is appropriate for your project.
Their project method on the other hand is interesting. Unfortunately the chapter describing it is a bit too sketchy for my taste. Also, it is more of a software integration strategy than a full-blown software engineeering methodology. They call the method "tracer bullet development", named after the bullets that allow you to see where you are firing your machine gun in the dark.
Essentially you start by dividing your system into layers, e.g. the GUI layer, the business logic layer and the data access layer. Then, you identify you system objects in each layer and the interaction between them. These objects and their interfaces are then implemented as stubs and integrated into a "working" system. Then you start filling in the blanks and elaborating the interfaces, keeping the system integrated all of the way. This strategy has several benefits. Having done the integration up front, you avoid the nerve-wracking tying together of components at the end of the implementation. The interface-orientation promotes cohesion and loose coupling, making the software more robust and scalable.
All in all, there is good stuff in there, but one has to wonder whether the book was the victim of time-boxed development and premature shipping.
February 16, 2020
I like "Am I doing this right?" parts the most. They help us to check some questions if we're on the right path.
- The cost of adding a feature isn't just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion ... the trick is to pick the features that don't fight each other
- Tools and Infrastructure:
1. Develop in a Sandbox:
Every dev has their own sandbox to play in without disturbing other devs. It applies to all resources: source code, database instances, web services on which you depand, and so on
Dev PCs <--> Repository <--> Build Machine <--> Released Product
2. Manage Assets
Source code management system or version control. With a properly set up SCM system, you can
+ Rolled back
+ Handle conflicts
+ Track multiple versions of your software
+ Record which files are changed
+ Retrieve a snapshot
3. Script your build
At a minimum, use a batch file or shell script to perform the build.
If you're using your manual build system properly, you will be able to build your entire product:
+ With one command
+ From your Source Code Management system (SCM)
+ On any team member's workstation
+ With no external environmental requirements (such as specific network drives)
4. Build automatically
Continuous Integration. You need to have tests in the system. After all, no one cares if it compiles if it doesn't run.
You also need to turn on the notifications, it make attention to the system when it is broken.
5. Track Issues
You need to know the following:
+ What version of the product has the issue?
+ Which customer encountered the issue?
+ How severe is it?
+ Was the problem reproduced in-house (and by whom, so they can help you if you're unable to reproduce the problem)?
+ What was the customer's environment (operating system, database, ...)
+ In what version of your product did the issue first occur?
+ In what version of your product was it fixed?
+ Who fixed it?
+ Who verified the fix?
6. Track Features
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.
7. Use a testing harness
A testing harness is the tool or software toolkit you use to create and run your tests. If your tests aren't automated, then you can't run them with a script.
Unless you want everyone on your team solving the same problems over and over, constantly reinventing the wheel, you should have a common framework everyone can use.
8. On Choosing Tools
Use the best tool for the job. Use open formats to integrate tools
9. When not to Experiment
Only experience can tell you about a given technology's shortcomings
- Pragmatic project techniques:
+ The List: must adhere to a number of rules:
Publicly available
Prioritized
On a time line
Living
Measurable
Targeted
+ The tech lead: a person to be the interface between the development team and management. The responsibilities of the Teach Lead:
Set direction for team members
Manage the project's feature list
Assign priorities to each feature
Insulate the team from external distractions
+ Daily meetings: meet more frequently with your entire team, and let everyone share what they are doing. 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
Pick a person to start the meeting, and then move clockwise through the group
** Our daily meetings last too long. What do we do? Draw team members away from the details of the fix, and try to just get the summary. For example, instead of presenting a low-level, detailed analysis of the problem, the debugging cycle, and the final solytion, just say, "We had an issue with the cache not getting updating with the altered data. It is now fixed and checked in"
You can also ask team members to write down what they intend to share. It will help them organize their thoughts before the meeting, thus avoiding the "rambling report" that lasts for five minutes.
Another potential problem is having too many people in the group. In this scenario, find a way to split the daily meetings into smaller groups when possible. Put team members working in the same areas into the same meetings. Be sure to have at least one or two people overlap so that relevant information can be passed along
+ Code reviews: iif a week goes by without a code review, you've allowed a lot of time for serious problems to creep into your code.
Small amount of code reviewed
One or two reviewers (Firstly, 1 senior + 1 junior. Don't need senior after 1 month)
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
- Burn rate: a term that describes how much money it costs to operate the company, including salaries, rent, electricity, benefits, ... Assume that each dev costs $100 an hour. That means if you have 10 people on your team, the ballpark burn rate is $1000 an hour, $8000 a day and $40000 a week. The next time you have a meeting that starts 10 minutes late or everyone hears about Fred's vacation for thirty minutes, calculate the cost. Rememer that this example ignores the cost of lost opportunities during the wasted time.
- Bus number: is the number of developers you'd have to lose to disable your project (key people)
Tracer Bullet Development (TBD) automatically raises your bus number. When team members from adjacent layers work together to define their shared interfaces, they are sharing knowledge about each layer's operations.
- How to get started with TBD?
Define your system objects.
Define the interfaces between them.
Write the interface stubs.
Make the stubs talk with each other.
Fill in the stubs with functional code.
- The cost of adding a feature isn't just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion ... the trick is to pick the features that don't fight each other
- Tools and Infrastructure:
1. Develop in a Sandbox:
Every dev has their own sandbox to play in without disturbing other devs. It applies to all resources: source code, database instances, web services on which you depand, and so on
Dev PCs <--> Repository <--> Build Machine <--> Released Product
2. Manage Assets
Source code management system or version control. With a properly set up SCM system, you can
+ Rolled back
+ Handle conflicts
+ Track multiple versions of your software
+ Record which files are changed
+ Retrieve a snapshot
3. Script your build
At a minimum, use a batch file or shell script to perform the build.
If you're using your manual build system properly, you will be able to build your entire product:
+ With one command
+ From your Source Code Management system (SCM)
+ On any team member's workstation
+ With no external environmental requirements (such as specific network drives)
4. Build automatically
Continuous Integration. You need to have tests in the system. After all, no one cares if it compiles if it doesn't run.
You also need to turn on the notifications, it make attention to the system when it is broken.
5. Track Issues
You need to know the following:
+ What version of the product has the issue?
+ Which customer encountered the issue?
+ How severe is it?
+ Was the problem reproduced in-house (and by whom, so they can help you if you're unable to reproduce the problem)?
+ What was the customer's environment (operating system, database, ...)
+ In what version of your product did the issue first occur?
+ In what version of your product was it fixed?
+ Who fixed it?
+ Who verified the fix?
6. Track Features
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.
7. Use a testing harness
A testing harness is the tool or software toolkit you use to create and run your tests. If your tests aren't automated, then you can't run them with a script.
Unless you want everyone on your team solving the same problems over and over, constantly reinventing the wheel, you should have a common framework everyone can use.
8. On Choosing Tools
Use the best tool for the job. Use open formats to integrate tools
9. When not to Experiment
Only experience can tell you about a given technology's shortcomings
- Pragmatic project techniques:
+ The List: must adhere to a number of rules:
Publicly available
Prioritized
On a time line
Living
Measurable
Targeted
+ The tech lead: a person to be the interface between the development team and management. The responsibilities of the Teach Lead:
Set direction for team members
Manage the project's feature list
Assign priorities to each feature
Insulate the team from external distractions
+ Daily meetings: meet more frequently with your entire team, and let everyone share what they are doing. 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
Pick a person to start the meeting, and then move clockwise through the group
** Our daily meetings last too long. What do we do? Draw team members away from the details of the fix, and try to just get the summary. For example, instead of presenting a low-level, detailed analysis of the problem, the debugging cycle, and the final solytion, just say, "We had an issue with the cache not getting updating with the altered data. It is now fixed and checked in"
You can also ask team members to write down what they intend to share. It will help them organize their thoughts before the meeting, thus avoiding the "rambling report" that lasts for five minutes.
Another potential problem is having too many people in the group. In this scenario, find a way to split the daily meetings into smaller groups when possible. Put team members working in the same areas into the same meetings. Be sure to have at least one or two people overlap so that relevant information can be passed along
+ Code reviews: iif a week goes by without a code review, you've allowed a lot of time for serious problems to creep into your code.
Small amount of code reviewed
One or two reviewers (Firstly, 1 senior + 1 junior. Don't need senior after 1 month)
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
- Burn rate: a term that describes how much money it costs to operate the company, including salaries, rent, electricity, benefits, ... Assume that each dev costs $100 an hour. That means if you have 10 people on your team, the ballpark burn rate is $1000 an hour, $8000 a day and $40000 a week. The next time you have a meeting that starts 10 minutes late or everyone hears about Fred's vacation for thirty minutes, calculate the cost. Rememer that this example ignores the cost of lost opportunities during the wasted time.
- Bus number: is the number of developers you'd have to lose to disable your project (key people)
Tracer Bullet Development (TBD) automatically raises your bus number. When team members from adjacent layers work together to define their shared interfaces, they are sharing knowledge about each layer's operations.
- How to get started with TBD?
Define your system objects.
Define the interfaces between them.
Write the interface stubs.
Make the stubs talk with each other.
Fill in the stubs with functional code.
This entire review has been hidden because of spoilers.
October 14, 2008
I saw Jared Richardson speak. He's a great speaker but he seemed to indicate that scrum wasn't really such a solid winner in the agile methodology space when the book was written. This is apparent as he seems to take some ideas from scrum when I would personally prefer to just do scrum.
He does a good job of tying together scrum, XP, agile and all around good practices.
He does a good job of tying together scrum, XP, agile and all around good practices.
September 5, 2023
I liked it a lot. Instead of prescribing some huge complex framework and a unified philosophy, it describes several simple methods and tries to suggest remedies to common problems. I particularly liked the idea of tracer bullet development.
December 11, 2015
Ship It!
A collection of lessons learned by various developers in the trenches. The book starts off with a quote of Aristotle "We are what we repeatedly do. Excellence, then, is not an act, but a habit.". The book strengthens this argument by stating "Extraordinary products are merely side effects of good habits.". So the first tip of the book is "Choose your habits". Do not follow something just because it is popular or well known or is practised by others around you.
The author says that there are three aspects that one needs to pay attention to:
1. Techniques: How the project is developed? I.e. Daily meetings, Code Reviews, Maintaining a To Do List etc.
2. Infrastructure: Tools used to develop the project. I.e. Version Control, Build Scripts, Running Tests, Continuous Build etc.
3. Process: The process followed in developing the applications. Propose Objects, Propose Interfaces, Connection Interfaces, Add Functions, Refactor Refine Repeat.
Tools and Infrastructure
The author highlights the need for a proper tool for Source Control Management. The author also issues a warning that the right tool should be chosen. A tool should not be chosen because it is backed by a big ticket organization. Vendors would push for "supertools", but one needs to exercise discretion when choosing between the tools.
Good Development Practices
1. Develop in a Sandbox, i.e. changes of one developer should not impact the other until the changes are ready.
2. Each developer should have a copy of everything they need for development, this includes web server, application server, database server, most importantly source code and anything else.
3. Once all the changes by the developer are finished they should check it in to the Source Control so that the others can pick up and integrate it with their code and make any changes they need to make to integrate.
4. The checked in changes should be fine grained.
Tools Required for ensuring Good Development Practices
1. SCM
2. Build Scripts
3. Track Issues
What to keep in SCM?
1. While it can be debated whether runtimes like Java need to be kept in the SCM, it is important that all the third party libraries (jars, dlls) and configuration templates be available in the SCM. Note that configuration templates need to be available as the contents itself can change from environment to environment.
2. Anything that is generated as part of the build process (jars, dlls, exes, war) should not be stored in the SCM.
What a Good SCM should offer
1. Ensure that the usage of SCM is painless to the developers. The interactions with the SCM should be fast enough to ensure that the developers do not hesitate to use it.
2. A minimal set of activities that should be supported by the SCM are
• Check out the entire project.
• Look at the differences between your edits and the latest code in the SCM.
• View the history for a specific file—who changed this file and when did they do it?
• Update your local copy with other developers’ changes.
• Push (or commit) your changes to the SCM.
• Remove (or back out) the last changes you pushed into the SCM.
• Retrieve a copy of the code tree as it existed last Tuesday.
Script the Build
Once the required artefacts are checked out from the SCM it should be possible for any developer to run a script and have a working system (sandbox) of her own to work on. For this one needs a Build Script. This should be a completely automated build requiring no manual intervention or steps. This build script should be outside of the IDE so that it can be used irrespective of the IDE being used. The IDE could use the same script for local builds.
Once the one step/command build script is ready, automate the build. Ideally everytime a code is checked in the following should be done.
1. Checkout the latest code and build
2. Run a set of smoke tests to ensure that the basic functionality is not broken.
3. Configure the build system to notify the stakeholders of new code checked, the build and the test results.
This is called Continuous Integration.
Tracking the Issues
It is important to track the issues that are reported for the application so that they can be tracked and fixed.
At a bare minimum one needs to know the following about an issue:
• What version of the product has the issue?
• Which customer encountered the issue?
• How severe is it?
• Was the problem reproduced in-house (and by whom, so they can help you if you’re unable to reproduce the problem)?
• What was the customer’s environment (operating system, database, etc.)?
• In what version of your product did the issue first occur?
• In what version of your product was it fixed?
• Who fixed it?
• Who verified the fix?
Some more that will help in the long term
• During what phase of the project was the bug introduced?
• The root cause of the bug
• The sources that were changed to fix the problem. If the checkin policy demands that the checkin comment indicate the reason for the fixes, then it should be possible to correlate the checkin with the issue that they fixed or requirement that they addressed.
• How long did it take to fix the error? (Time to analyze, Fix, Test)
Some warning signs that things are not OK with the issue system
• The system isn't being used.
• Too many small issues have been logged in the system
• Issue-related metrics are used to evaluate team member performance.
Tracking Features
Just as it is important to track the issues, it is important to track the features that have been planned for the application.
The system used to track issues may also be used to track the features as long as it provides the ability to identify them separately.
Testing
Have a good Test Harness which can be used to run automated tests on the system.
1. Use a standard Test Harness which can generate all the required reports.
2. Ensure that every team member uses the same tool.
3. Ensure that the tool can be run from the command line. This will enable driving it from an external script or a tool.
4. Ensure that the tool is flexible to test multiple types of applications and not specific to a particular type.
Different types of testing needs to be planned for
1) Unit Testing - Testing small pieces of code. This forces the developers to break up the code into smaller pieces. This makes is easier to maintain and understand, reduces copy paste, ensures that overall functionality is, if at all, minimally impacted by refactoring.
2) Functional Testing - Testing all the functions of the application.
3) Performance Testing - Testing the application to ensure that the application is performing within acceptable limits and meets the SLAs.
4) Load Testing - This is similar to the Performance Testing. The goal of this is to ensure that the application does not collapse under load.
5) Smoke Testing - This is a light-weight testing which will test the key functionality of the application. This should be included as part of Continuous Integration so that any breakage in key functionality comes to light very quickly.
6) Integration Testing - This ensures that the integration of the modules within the application and the integration of the application with the external systems is functioning correctly.
7) Mock Client Testing - This mocks the client requests and ensures that the client get the right response and within the expected time period.
Pragmatic Project Techniques
----------------------------
Some of the good practices to follow when working in projects are as follows:
1. Maintaining a list of activities to do. This should be visible and accessible to everybody on the project. Even the client should have visibility to the list so that they are check the speed and prioritize the items in the list. Each item should have a target time. The list should reflect the current status and should not be out of date.
2. Having Tech Leads in the project is important. The Tech lead should guide the team in the selection and utilization of the technology. Tech lead should be responsible to ensure that the deadlines are realistic. The Tech lead should act as the bridge between the developers and the management. It is an important role to be played by a person with the right temperament.
3. Coordinating and Communicating on daily basis is very important. Meetings need to be setup on a daily basis. These meetings should be short and to the point, with everybody sharing details of what they are doing and what they plan to do. Team should highlight any problem they are facing. The solutions for these problems should not be part of this meeting, but should happen separately.
4. Code review is a very crucial part of the project and every piece of code should be reviewed. Some good practices of code review are
a) Review only a small amount of code at any time
b) A code should not be reviewed by more than two people
c) Code should be reviewed frequently, possibly several times a day
d) Consider pair programming as a continuous code review process.
Tracer Bullet Development
-------------------------
Just like it is possible to fire a Tracer Bullet in the night to track the path before aiming the real bullet, it should be possible to predict the path of the project using the process opted for.
Have a process to follow.
The process followed should not claim exclusivity in success of projects. If it does so, then suspect it.
Follow a process that embraces periodic reevaluation and inclusion of whatever practices work well for the projects.
Define the layers that will exist in the application.
Define the interfaces between the layers.
Let each layer be developed by a separate team, relying on the interface promised by the adjacent layers.
Keep it flexible so that the interface can be changed as it is hard to get the interfaces perfect the first time around.
First create the large classes like the Database Connection Manager, Log Manager etc required for each layer, then write the fine grained classes.
Collaboration between the teams developing the different layers is key to the success. These collaborations will Trace the Path that the project will take.
Do not let an architect sitting in an ivory tower dictate the architecture.
It is dangerous to have one person driving the whole project. If this person leaves, the project will come to a standstill.
Create stubs, or mock the interfaces of the adjacent layers so that it becomes easy to test.
Code the tough and key pieces first and test them before addressing the simpler ones. It may take time to show progress, but when the progress happens it will be very quick.
Common Problems and How to fix Them
-----------------------------------
What to do when legacy code is inherited?
1. Build it - Learn to build it and script the build.
2. Automated it - Automate the build.
3. Test it - Test to understand what the system does and write automated test cases.
Don't change legacy code unless you can test it.
1. If a code is found unsuitable for automated test, then refactor the code slowly so that it becomes amenable to automated testing.
2. If a project keeps breaking repeatedly, automated test cases, emulating the user actions will help reduce the incidents.
3. Ensure that the automated tests are updated with change in code/logic whenever required, otherwise these would become useless.
4. It is important to have a Continuous Intergration so that the automated tests can be run regularly.
5. Early checkins (in fact daily or more than once a day) and quick updates by the developers is important so that the integration problems are detected as early as possible.
6. It is important to communicating with the customers and getting regular feedback.
7. Best way to show the customer the progress of the project is to show them a working demo of the application.
8. Introduce a process change when the team is not under pressure. Point out the benefit the stakeholders will have with the new process. Show them the benefit of the process/practice rather than talk and preach about it.
A wonderful quote from the book
"I love deadlines. I especially love the swooshing sound they make as they go flying by." — Scott Adams
A collection of lessons learned by various developers in the trenches. The book starts off with a quote of Aristotle "We are what we repeatedly do. Excellence, then, is not an act, but a habit.". The book strengthens this argument by stating "Extraordinary products are merely side effects of good habits.". So the first tip of the book is "Choose your habits". Do not follow something just because it is popular or well known or is practised by others around you.
The author says that there are three aspects that one needs to pay attention to:
1. Techniques: How the project is developed? I.e. Daily meetings, Code Reviews, Maintaining a To Do List etc.
2. Infrastructure: Tools used to develop the project. I.e. Version Control, Build Scripts, Running Tests, Continuous Build etc.
3. Process: The process followed in developing the applications. Propose Objects, Propose Interfaces, Connection Interfaces, Add Functions, Refactor Refine Repeat.
Tools and Infrastructure
The author highlights the need for a proper tool for Source Control Management. The author also issues a warning that the right tool should be chosen. A tool should not be chosen because it is backed by a big ticket organization. Vendors would push for "supertools", but one needs to exercise discretion when choosing between the tools.
Good Development Practices
1. Develop in a Sandbox, i.e. changes of one developer should not impact the other until the changes are ready.
2. Each developer should have a copy of everything they need for development, this includes web server, application server, database server, most importantly source code and anything else.
3. Once all the changes by the developer are finished they should check it in to the Source Control so that the others can pick up and integrate it with their code and make any changes they need to make to integrate.
4. The checked in changes should be fine grained.
Tools Required for ensuring Good Development Practices
1. SCM
2. Build Scripts
3. Track Issues
What to keep in SCM?
1. While it can be debated whether runtimes like Java need to be kept in the SCM, it is important that all the third party libraries (jars, dlls) and configuration templates be available in the SCM. Note that configuration templates need to be available as the contents itself can change from environment to environment.
2. Anything that is generated as part of the build process (jars, dlls, exes, war) should not be stored in the SCM.
What a Good SCM should offer
1. Ensure that the usage of SCM is painless to the developers. The interactions with the SCM should be fast enough to ensure that the developers do not hesitate to use it.
2. A minimal set of activities that should be supported by the SCM are
• Check out the entire project.
• Look at the differences between your edits and the latest code in the SCM.
• View the history for a specific file—who changed this file and when did they do it?
• Update your local copy with other developers’ changes.
• Push (or commit) your changes to the SCM.
• Remove (or back out) the last changes you pushed into the SCM.
• Retrieve a copy of the code tree as it existed last Tuesday.
Script the Build
Once the required artefacts are checked out from the SCM it should be possible for any developer to run a script and have a working system (sandbox) of her own to work on. For this one needs a Build Script. This should be a completely automated build requiring no manual intervention or steps. This build script should be outside of the IDE so that it can be used irrespective of the IDE being used. The IDE could use the same script for local builds.
Once the one step/command build script is ready, automate the build. Ideally everytime a code is checked in the following should be done.
1. Checkout the latest code and build
2. Run a set of smoke tests to ensure that the basic functionality is not broken.
3. Configure the build system to notify the stakeholders of new code checked, the build and the test results.
This is called Continuous Integration.
Tracking the Issues
It is important to track the issues that are reported for the application so that they can be tracked and fixed.
At a bare minimum one needs to know the following about an issue:
• What version of the product has the issue?
• Which customer encountered the issue?
• How severe is it?
• Was the problem reproduced in-house (and by whom, so they can help you if you’re unable to reproduce the problem)?
• What was the customer’s environment (operating system, database, etc.)?
• In what version of your product did the issue first occur?
• In what version of your product was it fixed?
• Who fixed it?
• Who verified the fix?
Some more that will help in the long term
• During what phase of the project was the bug introduced?
• The root cause of the bug
• The sources that were changed to fix the problem. If the checkin policy demands that the checkin comment indicate the reason for the fixes, then it should be possible to correlate the checkin with the issue that they fixed or requirement that they addressed.
• How long did it take to fix the error? (Time to analyze, Fix, Test)
Some warning signs that things are not OK with the issue system
• The system isn't being used.
• Too many small issues have been logged in the system
• Issue-related metrics are used to evaluate team member performance.
Tracking Features
Just as it is important to track the issues, it is important to track the features that have been planned for the application.
The system used to track issues may also be used to track the features as long as it provides the ability to identify them separately.
Testing
Have a good Test Harness which can be used to run automated tests on the system.
1. Use a standard Test Harness which can generate all the required reports.
2. Ensure that every team member uses the same tool.
3. Ensure that the tool can be run from the command line. This will enable driving it from an external script or a tool.
4. Ensure that the tool is flexible to test multiple types of applications and not specific to a particular type.
Different types of testing needs to be planned for
1) Unit Testing - Testing small pieces of code. This forces the developers to break up the code into smaller pieces. This makes is easier to maintain and understand, reduces copy paste, ensures that overall functionality is, if at all, minimally impacted by refactoring.
2) Functional Testing - Testing all the functions of the application.
3) Performance Testing - Testing the application to ensure that the application is performing within acceptable limits and meets the SLAs.
4) Load Testing - This is similar to the Performance Testing. The goal of this is to ensure that the application does not collapse under load.
5) Smoke Testing - This is a light-weight testing which will test the key functionality of the application. This should be included as part of Continuous Integration so that any breakage in key functionality comes to light very quickly.
6) Integration Testing - This ensures that the integration of the modules within the application and the integration of the application with the external systems is functioning correctly.
7) Mock Client Testing - This mocks the client requests and ensures that the client get the right response and within the expected time period.
Pragmatic Project Techniques
----------------------------
Some of the good practices to follow when working in projects are as follows:
1. Maintaining a list of activities to do. This should be visible and accessible to everybody on the project. Even the client should have visibility to the list so that they are check the speed and prioritize the items in the list. Each item should have a target time. The list should reflect the current status and should not be out of date.
2. Having Tech Leads in the project is important. The Tech lead should guide the team in the selection and utilization of the technology. Tech lead should be responsible to ensure that the deadlines are realistic. The Tech lead should act as the bridge between the developers and the management. It is an important role to be played by a person with the right temperament.
3. Coordinating and Communicating on daily basis is very important. Meetings need to be setup on a daily basis. These meetings should be short and to the point, with everybody sharing details of what they are doing and what they plan to do. Team should highlight any problem they are facing. The solutions for these problems should not be part of this meeting, but should happen separately.
4. Code review is a very crucial part of the project and every piece of code should be reviewed. Some good practices of code review are
a) Review only a small amount of code at any time
b) A code should not be reviewed by more than two people
c) Code should be reviewed frequently, possibly several times a day
d) Consider pair programming as a continuous code review process.
Tracer Bullet Development
-------------------------
Just like it is possible to fire a Tracer Bullet in the night to track the path before aiming the real bullet, it should be possible to predict the path of the project using the process opted for.
Have a process to follow.
The process followed should not claim exclusivity in success of projects. If it does so, then suspect it.
Follow a process that embraces periodic reevaluation and inclusion of whatever practices work well for the projects.
Define the layers that will exist in the application.
Define the interfaces between the layers.
Let each layer be developed by a separate team, relying on the interface promised by the adjacent layers.
Keep it flexible so that the interface can be changed as it is hard to get the interfaces perfect the first time around.
First create the large classes like the Database Connection Manager, Log Manager etc required for each layer, then write the fine grained classes.
Collaboration between the teams developing the different layers is key to the success. These collaborations will Trace the Path that the project will take.
Do not let an architect sitting in an ivory tower dictate the architecture.
It is dangerous to have one person driving the whole project. If this person leaves, the project will come to a standstill.
Create stubs, or mock the interfaces of the adjacent layers so that it becomes easy to test.
Code the tough and key pieces first and test them before addressing the simpler ones. It may take time to show progress, but when the progress happens it will be very quick.
Common Problems and How to fix Them
-----------------------------------
What to do when legacy code is inherited?
1. Build it - Learn to build it and script the build.
2. Automated it - Automate the build.
3. Test it - Test to understand what the system does and write automated test cases.
Don't change legacy code unless you can test it.
1. If a code is found unsuitable for automated test, then refactor the code slowly so that it becomes amenable to automated testing.
2. If a project keeps breaking repeatedly, automated test cases, emulating the user actions will help reduce the incidents.
3. Ensure that the automated tests are updated with change in code/logic whenever required, otherwise these would become useless.
4. It is important to have a Continuous Intergration so that the automated tests can be run regularly.
5. Early checkins (in fact daily or more than once a day) and quick updates by the developers is important so that the integration problems are detected as early as possible.
6. It is important to communicating with the customers and getting regular feedback.
7. Best way to show the customer the progress of the project is to show them a working demo of the application.
8. Introduce a process change when the team is not under pressure. Point out the benefit the stakeholders will have with the new process. Show them the benefit of the process/practice rather than talk and preach about it.
A wonderful quote from the book
"I love deadlines. I especially love the swooshing sound they make as they go flying by." — Scott Adams
August 21, 2025
This book might have been alright if you read it as a fresh C.S. graduate in the year it came out, but reading it today is worthless at best, probably counterproductive. Every good bit of advice (there are many) has been absorbed so thoroughly into programming culture, they seem absurdly banal and obvious (e.g. "use a version control system", "use a list to track units of work over time"). Nearly every point made in the book which doesn't come across this way turns out to be bad advice which clearly has already lost in the marketplace of ideas (e.g. "tracer bullet development"). Don't waste your time.
December 5, 2022
Easy to read with really helpful advices like the Tracer Bullet Development methodology and the last section of the book, for me the best part (chapter 5).
Though it has some chapters not relevant to current trends in software development (e.g. automate builds), at least if you’re working beyond 2020; and it even suggests some tools way too old like Subversion or Cruise Control, yet not their fault: software development evolved very quickly in 20 years.
This is a good complement to the book “Release it!” because of the chapter 5
Though it has some chapters not relevant to current trends in software development (e.g. automate builds), at least if you’re working beyond 2020; and it even suggests some tools way too old like Subversion or Cruise Control, yet not their fault: software development evolved very quickly in 20 years.
This is a good complement to the book “Release it!” because of the chapter 5
May 12, 2019
Though some pieces of advice in this book do look obvious in 2019, you'll most likely find a couple of good and simple ideas that can make you more focused and productive (I found "The List" particularly useful for my environment).
A very good help for newly converted team/tech leads. Even teams working for the most successful tech giants and enjoying using state-of-the-art infrastructure can benefit from adopting some of the practices presented in this book. My team definitely can.
A very good help for newly converted team/tech leads. Even teams working for the most successful tech giants and enjoying using state-of-the-art infrastructure can benefit from adopting some of the practices presented in this book. My team definitely can.
September 4, 2018
This book contains short guide and many extremely practical advises. I do think that some of them should be substituted with newer list of CI systems and etc., BUT advises themselves not outdated at all. I highly recommend to read this book for people who has legacy code to work with or projects that are in the stale state.
July 25, 2025
I was very unfair to this book. I read it 2025 while it was written in 2011. It hasn't aged well. Practices that the authors think are elite and uncommon are bread and butter these days. No one needs to read this book now. I read it out of compulsion. I keep but wondering whether I'd find this book ground-breaking 15 years ago, but probably not; there were better books out there on the topic.
June 20, 2018
It is a good book but very old and most of the suggestions have already become de facto standard in the industry. Thus 4 stars.
January 13, 2021
This book is only really helpful if you work in a very small company. Anything larger than that should have all of the recommendations in place and are pretty obvious.
August 21, 2021
A collection of great techniques, but also old school control based management.
February 5, 2022
it is very dated in so many ways
March 31, 2013
Ship It!
By: Jared Richardson and William Gwaltney Jr.
Copyright 2007
Reviewed January 2008 by Anthony DeLuca
I originally perceived Ship It! to be different than it turned out. I expected the book to be geared towards how to ship complex software suites that contained multiple products. Perhaps it is because that was the information I was looking for at the time! It turns out Ship It! is a very basic book that gives a broad overview of modern “grass roots based” software development practices. I describe the practices as grass roots practices as many of them were born from developer-level, open-source, collaborative efforts, rather than from a large for-profit organization seeking more to make a profit with the content of the solutions as a mere means to this end.
Surprisingly my organization’s teams practices many of the items in this book. The book gives an excellent overview of each item and includes references to further information. The book is broken down into tools and infrastructure, pragmatic project techniques, a single chapter on tracer bullet development, and a great wrap-up chapter about common problems and how to fix them. In the end the appendix wraps the entire book into a very high-level summary, perfect as a reference, with pointers to other places to go to get more information or supporting tools.
‘Tools and Infrastructure’ touches on the many areas that developers talk about, but only some practice. Some items in this chapter would seem that no-brainer common sense to modern developers, yet a huge wake up call to developers who may not be as in touch with the industry. The most compelling items in this section, in my opinion, are scripting builds and setting up an automated build. The end of the section talks about tools and when NOT to experiment.
‘Pragmatic Programming Techniques’ talks about no-brainer concepts that anyone who is in the agile world would certainly be aware. The concepts in this section are light weight techniques that can be implemented with free or even no tools at all other than a white board and a desk calendar for each team member so they can know when they need to be in a meeting. (brief meeting… to the point!) I feel that a large organization with multiple teams will need more than this section offers, but the information here is still an excellent baseline, and a great foundation from which to build.
The ‘Tracer Bullet Development’ section I found to be very enlightening since I had not known much about this in the past other than the name of the concept. Tracer Bullet Development is the concept of building the entire system as templates of integrated pieces, making that work, then filling in the details of each piece of the system. It is important as the pieces are build that the total system integration never break.
Finally the last section answers the burning questions most people will have after reading the book. “How to I get over this roadblock?” “How do I handle a situation where people are not on board”, etc..
In summary, I recommend this book to be read cover to cover by any novice developer or any developer who looks at the table of contents and fins many of the topics foreign to them. For the rest of the folks, skimming this book would be a great review and having it as a reference on your shelf could prove to be useful, especially the last section and the appendix.
By: Jared Richardson and William Gwaltney Jr.
Copyright 2007
Reviewed January 2008 by Anthony DeLuca
I originally perceived Ship It! to be different than it turned out. I expected the book to be geared towards how to ship complex software suites that contained multiple products. Perhaps it is because that was the information I was looking for at the time! It turns out Ship It! is a very basic book that gives a broad overview of modern “grass roots based” software development practices. I describe the practices as grass roots practices as many of them were born from developer-level, open-source, collaborative efforts, rather than from a large for-profit organization seeking more to make a profit with the content of the solutions as a mere means to this end.
Surprisingly my organization’s teams practices many of the items in this book. The book gives an excellent overview of each item and includes references to further information. The book is broken down into tools and infrastructure, pragmatic project techniques, a single chapter on tracer bullet development, and a great wrap-up chapter about common problems and how to fix them. In the end the appendix wraps the entire book into a very high-level summary, perfect as a reference, with pointers to other places to go to get more information or supporting tools.
‘Tools and Infrastructure’ touches on the many areas that developers talk about, but only some practice. Some items in this chapter would seem that no-brainer common sense to modern developers, yet a huge wake up call to developers who may not be as in touch with the industry. The most compelling items in this section, in my opinion, are scripting builds and setting up an automated build. The end of the section talks about tools and when NOT to experiment.
‘Pragmatic Programming Techniques’ talks about no-brainer concepts that anyone who is in the agile world would certainly be aware. The concepts in this section are light weight techniques that can be implemented with free or even no tools at all other than a white board and a desk calendar for each team member so they can know when they need to be in a meeting. (brief meeting… to the point!) I feel that a large organization with multiple teams will need more than this section offers, but the information here is still an excellent baseline, and a great foundation from which to build.
The ‘Tracer Bullet Development’ section I found to be very enlightening since I had not known much about this in the past other than the name of the concept. Tracer Bullet Development is the concept of building the entire system as templates of integrated pieces, making that work, then filling in the details of each piece of the system. It is important as the pieces are build that the total system integration never break.
Finally the last section answers the burning questions most people will have after reading the book. “How to I get over this roadblock?” “How do I handle a situation where people are not on board”, etc..
In summary, I recommend this book to be read cover to cover by any novice developer or any developer who looks at the table of contents and fins many of the topics foreign to them. For the rest of the folks, skimming this book would be a great review and having it as a reference on your shelf could prove to be useful, especially the last section and the appendix.
September 17, 2010
A very pleasant read, presenting a lot of simple but powerful ideas on how to make the software development process run more smoothly. With no unnecessary complexity in both the writing style and the concepts being described, it becomes easy to see how and why the ideas fit together, how they would help improve the quality of the product and of the overall process, and because every tool or technique remain "simple" many actually feel implementable (because they are!). The book includes strategies on how to bring about a change depending on your position (dev, tech lead, management, customer...), and with everything neatly cut into small parts, none is overwhelming and you can plot how best to bring them to your shop.
Although it doesn't match exactly the chapter structure I'd say there are 3 main parts to this book: tools, project management, and a list of common problems with their solutions. Feel free to skim to that last part when getting the book if you feel the need for a little bit of hope but I would advise reading the book in order, because many of the suggested solutions won't make a lot of sense otherwise.
Overall excellent, the writing style makes this book a pleasure to read and doesn't distract from the content. I came away with a ton of ideas on how to improve things and remove some of the difficulties of the software development process that really don't belong.
Although it doesn't match exactly the chapter structure I'd say there are 3 main parts to this book: tools, project management, and a list of common problems with their solutions. Feel free to skim to that last part when getting the book if you feel the need for a little bit of hope but I would advise reading the book in order, because many of the suggested solutions won't make a lot of sense otherwise.
Overall excellent, the writing style makes this book a pleasure to read and doesn't distract from the content. I came away with a ton of ideas on how to improve things and remove some of the difficulties of the software development process that really don't belong.
April 27, 2015
This book is a great reminder of all the things one should do to get high quality software out of the door. It is however not really a book for novice and junior programmers. For them it will let too much questions unanswered. And those developers who are delivering software for a few years may know it already. If you fall in the spot between and want to grow then this book is a great help.
Especially the chapters on automating your build from day one or how to get to a realistic project schedule are known to everyone, but it’s so often ignored. Having a reminder could save so many project that you should read it even if you are not position your knowledge in-between junior and senior developer.
Especially the chapters on automating your build from day one or how to get to a realistic project schedule are known to everyone, but it’s so often ignored. Having a reminder could save so many project that you should read it even if you are not position your knowledge in-between junior and senior developer.
February 14, 2009
It's a relatively solid primer to software development process, tools and techniques. It would be most useful if you were either inexperienced or came through a background of teams without much in the way of formal process, training and experience.
An experienced software developer with a good grasp of current processes and tools isn't likely to learn a lot. I found myself somewhat bored even skimming it, although I mostly agreed with what I read, there just wasn't enough new to really grab me.
That said, I've met lots of organizations that would benefit directly from something like this, and most of them know it. They should read this book.
An experienced software developer with a good grasp of current processes and tools isn't likely to learn a lot. I found myself somewhat bored even skimming it, although I mostly agreed with what I read, there just wasn't enough new to really grab me.
That said, I've met lots of organizations that would benefit directly from something like this, and most of them know it. They should read this book.
March 10, 2016
Ship it! Is a highly accessible quick read with a warm tone. The last 10 years however have aged it tremendously. While the sections on how to communicate with managers still hold up well, a majority of the book is about practices for managing software development in the general sense, and the reader in 2016 would better be served by picking up a specific book on their preferred methodology. Other sections talking about the merits of version control no longer need convincing in the professional world.
I feel bad for giving a low rating, but this book is simply out-dated, though well written for its time.
I feel bad for giving a low rating, but this book is simply out-dated, though well written for its time.
May 15, 2011
A bit redundant for me to read this after reading Practices of an Agile Developer: Working in the Real World. This was a lot less technical and probably better suited to non-developers. It does a good job of explaining the tools and processes of a successful development team, with a very in depth look at Tracer Buller Development. The Tip Summary and the Reading List are also both useful.
August 27, 2013
This was a sort of text book for a tech training we did in house. There's lots of good tips and reminders in here, and the discussion of Trace Bullet Development offers some valuable insights. The tool talk gets a bit dated these days, but he didn't waste much time on it before getting back to the generic considerations of choosing your tools. I also greatly appreciated the talk of the "personalities" in a team.
December 19, 2008
Great book about the tools that make software development easier and more successful as well as how to use them. I recommend this book to any serious software devs out there and and dev shops looking to boost their productivity.
October 30, 2012
This book has very practical advice and is an extremely quick read. It details several types of tools and techniques to get things done. The overall philosophy of the authors to make things automatic, minimize risk, and correctly order priorities.
March 30, 2013
I found this book to be a bit simple. A lot of the advice, while good, seems to be aimed at teams who are not already using good practices such as build machines and automation. I found very little of it interesting or useful.
January 7, 2014
Very nice read, which although it seems very dated sometimes, provides a holistic approach to a very pragmatic software development process. I especially liked, that the process is so simple but even more effective because of that.
Wish I had read it sooner.
Wish I had read it sooner.
December 17, 2014
Sound and reasonable advice. These are the basics pretty much every developer should be aware of. Nothing new though, if you're familiar with agile practices. I don't really like their Tracer Bullet Development (neither the term nor the process) but that's probably just a matter of taste.
February 17, 2009
Good, but very "lite".
July 10, 2008
Very good book. Guides a software developer through the agile process. Provides plenty of examples to convince the practitioner to deliver software in a timely, proper, & correct manner.
Displaying 1 - 30 of 39 reviews