Design - Build - Run: Applied Practices and Principles for Production-Ready Software Development

by Dave Ingram

This unique and critical book shares no-fail secrets for building software and offers tried-and-true practices and principles for software design, development, and testing for mission-critical systems that must not fail. A veteran software architect walks you through the lifecycle of a project as well as each area of production readiness--functionality, availability, performance and scalability, operability, maintainability, and extensibility, and...

• Format: Paperback
• Language: English
• ISBN: 0470257636
• ISBN13: 9780470257630
• Release Date: February 2009
• Publisher: Wrox Press
• Length: 688 Pages
• Weight: 2.24 lbs.
• Dimensions: 1.5" x 7.4" x 9.1"

Customer Reviews

Nicely Done

"Design - Build - Run" reminds me of a course in Systems Analysis and Design that I had taken: it covers dry, but essential material. It is an easy read, yet there's a lot to digest, and thanks to the author's "just the facts" approach, all of it pertinent to the subject matter. Dave Ingram has had work cut out for him putting this monster together, and he delivered a concisely assembled manual for an effective software developer. The material focuses on proper procedures, and in doing so highlights many of the little caveats and pitfalls one might come across without sufficient planning throughout all stages of the software lifecycle. I really like this book. It is an excellent, thorough reference, both well written and easy to comprehend.

Hard to Believe How Accurate This Book Is

I work for a major website. It is one of the top 100 visited sites in the world. With that in mind, I was amazed at how much of this book applies to my day-today operations at the office. This is not a technical book. It is a conceptual and theoretical book describing best practices in the industry. It covers a variety of topics from coding practices to establishing your datacenter redundancy strategy. Other topics include: Production monitoring, incident investigation, architecture, and application design and maintenance. This book is categorized in the software development section and that is even noted on the back cover (I suppose for shelving purposes). While it would benefit a developer, there is very little code in this book. That is not its purpose. I would say this is an "enterprise architect's" book. If there was ever a book that I would hand a brand-new hire in my department, this would be it. It practically is my job description in 685 pages. I recommend this to anyone wanting to get a head-start in a company's Production environment. I wish I would have had this book a decade ago.

For Serious and Sellable Software, This Is a Must-Have

OK, short and sweet: I'm a MCPD certified software developer on Microsoft Visual Studio 2005 and have written software as my livelyhood for over 11 years. I have a LOT of books, all about "How-To" in programming. However, those how-to books don't really show you in full detail the BEST way to execute all aspects of software development, and they definitely don't show you how to best accomplish your testing phase (that's been a learn-as-you-go thing for most developers). This is where Dave Ingram's effort shines. Sure, you can code a program and store data, but have you really thought of the best way to store it for heavy reporting in the future? Have you planned out the best code structure so future changes or maintenance is easy to perform, especially by another developer? What's the most efficient and secure way to deal with logging into a system? What do you need to know about datacenters and hardware as a developer that will impact your design? What auditing method will you use when working on a secured or military project? And what about deployment of the app? That's just a tip of the iceberg, but that is the direction this book goes. If you want to be a pro developer and not just hack out code to get the job done in a pinch, you need to add this to your library, I'm glad it's now in mine!

Full of truth you should already know

There are zillions of books about dieting on the market. Most of them are full of sound truths and are written in such a way as to motivate the dieter to eat better and exercise more. Dieters can be seen reading these books from time to time in hopes of finding some new gem to help them achieve their goal, but I'm willing to bet that if you asked one who just finished a new book if they learned anything new from the read, they would probably say something to the effect of, "Well, it was good to be reminded of that, but I already knew most of it." I felt like this book was a lot like a dieting book but for software developers. Reading the book reminded me of the things I should be doing and made me feel good about the things I am doing/have done correctly. Did I really learn anything though? Not really, no. This is something you learn by DOING not by READING: if you don't have any experience in the field, then reading up on it may help you get started but ultimately a bit of experience will teach you more than reading all that has ever been written on the subject. If you are looking for some silver bullet, sorry it still doesn't exist. Now, don't get me wrong--the book is full of plenty of truths that, if followed, would have production-ready code as the end product; the content is fine. I just think that if you've been in the field for a while, you may not really get much out of it. This book would be recommended to audiences that: 1) Are new to the field 2) Want to be reminded of all the things they should be doing 3) Want to make a proposal to their team that they change the way their development cycle runs and want to have some authoritative words to back up their suggestions 4) Love software development, love to read and have plenty of time to do so

Does software construction have to invariably involve working very long hours and attending countles

I have to admit I became a little bit wary when I first read the second to fourth sentences in this book's introduction: "... Software construction is a complicated process. It is enjoyable, but it is also very hard work, from start to finish. It invariably involves working very long hours (usually weekends), attending countless meetings and discussions, and rushing to meet the deadlines..." I know from experience that software construction doesn't have to invariably involve working very long hours and attending countless meetings. With good planning, realistic goals, and decisive leadership, software construction doesn't have to involve "heroic" efforts such as working on weekends. At 650+ pages, this is a hefty book on how to navigate the technical challenges involved in producing "production ready" software. It is not a book on project management nor does it deal with development methodologies such as Rational's Unified Process or Agile, etc., but it does propose "recipes" for success. In my opinion, many of the proposed recipes do make a lot of sense but I would be careful with others that have potential pitfalls (more on this later). Experienced at managing and architecting large-scale software solutions, the author's definition of "production readiness" is an all-encompassing one: the code and documentation for the business application that is being developed are not the only things that need to meet quality standards, but the various environments, processes and tools participating in the creation, testing, hosting, monitoring, version-controlling, etc. of the target application also need to meet quality standards as well as work harmoniously together in order for a project to succeed. The author has proposed a long list of qualities that a system in production must have, and his overall message is to strive for these qualities by doing things early and to always think ahead of what a piece of software or an environment needs to be able to do so that potential solutions can be considered and vetted early enough and then continuously improved afterwards. For example, if a business application requires the continual running of batch jobs in the background, the developers coding a batch job might have to understand that operations people often have a need to pause then resume a batch job so such capabilities would have to be incorporated into the design and coding of the batch job. After reading the book, I can say that the author has proposed a comprehensive set of activities that he thinks will drive project success. By comprehensive I mean the author has opinions on almost everything: from load balancing strategies, to testing and defect management, even to branching and merging version-control activities. For many of the proposed activities, the author also has additional proposed checkpoint tasks and documentation/handover standards. If some of you are beginning to think that there is a potential for overkill here, I share yo