Ship It!: A Practical Guide to Successful Software Projects
Ship It! is a collection of tips that show the tools andtechniques a successful project team has to use, and how to use themwell. You'll get quick, easy-to-follow advice on modernpractices: which to use, and when they should be applied. This bookavoids current fashion trends and marketing hype; instead, readersfind page after page of solid advice, all tried and tested in thereal world.
Aimed at beginning to intermediate programmers, Ship It! will show you:
Few of the ideas presented here are controversial or extreme; most experiencedprogrammers will agree that this stuff works. Yet 50 to 70 percent of allproject teams in the U.S. aren't able to use even these simple, well-acceptedpractices effectively. This book will help you get started.
Ship It! begins by introducing the common technicalinfrastructure that every project needs to get the job done. Readerscan choose from a variety of recommended technologies according totheir skills and budgets. The next sections outline the necessarysteps 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 commonproblems that teams face, then offers real-world advice on how tosolve them.
6 pages matching CruiseControl in this book
Results 1-3 of 6
What people are saying - Write a review
"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.
Tools and Infrastructure
Pragmatic Project Techniques
Tracer Bullet Development
27 other sections not shown