Design, Build, Run: Applied Practices and Principles for Production Ready Software Development (Wrox Programmer to Programmer) Paperback – 13 Feb 2009
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Would you like to tell us about a lower price?
If you are a seller for this product, would you like to suggest updates through seller support?
From the Back Cover
Design – Build – Run
Applied Practices and Principles for Production–Ready Software Development
What is the secret to successful software development? Veteran software architect Dave Ingram believes that a true success story is a project that delivers a system with all the required functionality, on time and within budget. In this book, Ingram shares his secrets to building software that must not fail and he explains why everything developers do during the process of software development impacts the overall outcome of a project.
Serving as a guide to designing and building production–ready software from the start, this book examines the entire process and the tools needed to develop and test applications. You′ll look at the environments and circumstances in which a system could be used and how to make certain that it′s fit for these purposes. Most importantly, the book covers the practices and patterns you can leverage during design and development to improve software quality, lower the total cost of ownership, and ensure that it is truly production–ready. With a thorough understanding of what is involved in designing, building, and running large–scale software systems, you′ll enhance your skills for building successful solutions.
What you will learn from this book
What production–readiness means and all the quality characteristics that software needs to meet
Key patterns and practices that ensure systems are designed and built to be production–ready and meet required standards and practices
How to design for resilience, batch, performance, monitoring, incident investigation, reporting, application maintenance, testing, and deployment
The pros and cons of using various tools and technologies and how to use them effectively
Techniques for reviewing and testing a prototype
Ways to plan the logical architecture and model the application
Who this book is for
This book is for software developers of all levels from programmers through to software architects who are interested in learning all aspects related to building production–ready systems. Familiarity with software designs and development practices is essential.
Wrox guides are crafted to make learning programming languages and technologies easier than you think. Written by programmers for programmers, they provide a structured, tutorial format that will guide you through all the techniques involved.
Most helpful customer reviews on Amazon.com
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 your sentiment. In fact, the author addressed this concern in a few places by suggesting that the actual work involved may or need not really be that much. I remain somewhat skeptical.
But there were other things that concerned me as well. Not only is the proposed set of activities large, but the author is a big advocate of doing as many of them as early as possible. This to me sounds like the same problem as a customer telling me every requirement is a top priority.
The author is also a big advocate of "thinking ahead" and thinking of various "what-if" scenarios. The potential pitfall with this is that you may end up spending time on something that may not actually happen or that you may not really need or have to address (the so called YAGNI phenomenon, with YAGNI standing for You Ain't Gonna Need It).
So although the author makes many good suggestions in this book, some of them have pitfalls and not all of them will be applicable to every project.
Finally, I did find the book a tedious read at times. I think the book is too long and the author not only had a tendency to repeat a thought in many places, but when he does, he also tends to use the same exact phrases: fit for purpose, sized and scaled appropriately, meet all the necessary quality characteristics. A shorter and more streamlined book that preserved the very good Patterns and Practices chapters would have been a better book, in my opinion.
This book seems geared toward the ASP/Data Center type architecture. I work in this environment as a coder, and I generally agree with what the author says. But, if you're making standalone or offline apps or games or anything shrink-wrapped, much, if not most, of this isn't going to apply to you.
It has a peculiar range, it can be quite high level and very low level.
page 331 (Guiding Principles) - "Positive user experience - Positively impact the user experience and satisfaction of the system while retaining and satisfying the business goals and requirements..."
On page 204 the author notes about Dual Fiber cards - "This is usually required for the database servers that are connected to the SAN or other fiber channel resources". On page 606 it talks about good code commenting policies - "When commenting code, you could also keep a record of the individual changes at the top of the class". I'm not sure what reader would need both points. As a coder, reading about commenting policy isn't an urgent thing for me, but I understand the value in having a consistent policy on it. The stuff about Dual Fiber cards isn't relevant to me at all.
As the author says, it's not a code book, it's not a patterns book, it's not a testing book, it's not a DBA guide to good practices. It's more like - if you're setting up an ASP business these are key points to address. If that's what you are going for, this is book might have something for you, though in a long winded manner. If not, then it's likely to be way over-broad and unhelpful.
Look for similar items by category
- Books > Computing & Internet > Digital Lifestyle > Online Shopping > Amazon
- Books > Computing & Internet > Programming > Languages & Tools
- Books > Computing & Internet > Programming > Software Design, Testing & Engineering > Functional Programming
- Books > Computing & Internet > Programming > Software Design, Testing & Engineering > Software Architecture
- Books > Computing & Internet > Programming > Software Design, Testing & Engineering > Software Design