Practical Crap Detection for Software Projects

This is a book for anyone who participates in the acquisition, development, administration, or support of software. It is most particularly for executives and managers experiencing late projects, out-of-control costs, insufficient software functionality, never-ending software defects, poor system performance, continuing surprises in the process and its results, and terminally overworked employees. The book was written out of frustration. We are often referred into a client to help unscrew a screwed-up project. After a brief evaluation, weve told some of them to throw away tens of millions of dollars in wasted software development effort. What theyve built cannot be fixed. While technology is driven by the continuing exponential price/performance curve of Moores Law, human understanding of how to use it is stuck on a linear track. Universities dont help, producing excellent individual contributors but poor managers and team players. Managers new to software projects, in their own defense, need to know the questions to ask, and what constitutes good answers. They need just enough understanding of the software development process to understand when theyre getting the truth and when theyre getting the run-around. The book is prescriptive in nature, and generally refers to large projects. Small, new projects can get away with less discipline. Much less. If you are creating a new application with a new architecture, in a market you know backwards and forwards, and time to market is your first concern, then you dont need all the formality to do a really great job. If you have only five people working on a project in a garage, go for it, with just enough formality to desribe the requirements, architecture and design to newcomers. Finally, the book describes development practices at the end of a long evolutionary path followed by companies with a history of repeated software success. And even they are not immune to a new, faddish development methodology that leads them astray. Do not try to implement these practices all at once if your company falls short. Implement them incrementally. Take a little. Let it settle. Take a little more. Start with requirements and metrics. Work both ends towards the middle. Make them your own. Use the best for your company in this place, time, and project context. The point of this book is primarily to provide you with an effective crap detector: to identify the pitfalls, ask the right questions, analyze the answers, and forecast (and improve) outcomes. Without surprises. Open this book anywhere and take away one good idea. Use what you can. Dont force it. Do well.