CDN$ 37.79
  • List Price: CDN$ 59.99
  • You Save: CDN$ 22.20 (37%)
Usually ships within 3 to 4 weeks.
Ships from and sold by Amazon.ca.
Gift-wrap available.
Quantity:1
Have one to sell?
Flip to back Flip to front
Listen Playing... Paused   You're listening to a sample of the Audible audio edition.
Learn more
See this image

Design - Build - Run: Applied Practices and Principles for Production Ready Software Development Paperback – Feb 24 2009


See all 2 formats and editions Hide other formats and editions
Amazon Price New from Used from
Paperback
"Please retry"
CDN$ 37.79
CDN$ 12.09 CDN$ 5.14

2014 Books Gift Guide
Yes Please, the eagerly anticipated first book from Amy Poehler, the Golden Globe winning star of Parks and Recreation, is featured in our 2014 Books Gift Guide. More gift ideas


Product Details


Product Description

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.


Inside This Book (Learn More)
Browse Sample Pages
Front Cover | Copyright | Table of Contents | Excerpt | Index | Back Cover
Search inside this book:

Customer Reviews

There are no customer reviews yet on Amazon.ca
5 star
4 star
3 star
2 star
1 star

Most Helpful Customer Reviews on Amazon.com (beta)

Amazon.com: 22 reviews
5 of 5 people found the following review helpful
Not terrible but not great Oct. 21 2009
By B.L. - Published on Amazon.com
Format: Paperback Vine Customer Review of Free Product
I'm in agreement with some of the other reviewers on this book that I found it very difficult to get a sense of the purpose of what I was reading. The level of detail, and how much it assumed you already know, varies widely. I don't think one other reviewer was terribly inaccurate when bringing up the idea of this book as a textbook. It's written in a very similar style to what you don't typically see outside of textbooks and technical papers.

The best thing about this book, in my view, is the attitude the author takes toward software development. His consistent message is that quality and being ready for use isn't just about the software itself, but about making sure that the software is appropriate for and will work in the environment that you intend. He does a great job of breaking things down point by point and addresses a huge number of factors.

As I read, however, it was often a little bit difficult to get a real grasp of how to put the material into practice. There are times that he uses actual case studies to talk about what's important and where the focus should be, but much of the time it feels a little bit like I'm being assaulted by bullet points. They're a great tool for breaking up multiple points on a topic in a way that clearly separates them, but they're used so heavily here that it ended up feeling like it was difficult to absorb much of the material.

I think the main problem here is the tension between being a guidebook and being a reference book. It presents itself as a guide book and does provide some useful explanations along those lines, but they then pack information and suggestions in so tightly that it ends up being dragged off in the reference book direction and making the larger themes needlessly difficult to absorb.

I have to say that I also think this book greatly oversells the current potential for creating software that "must not fail". While some companies certainly try, the process of designing flawless software just isn't a solved problem yet if it ever will be. Even with the incredible amount of time and effort put into software for NASA they've still been known to run into problems. In general companies and programming teams are constantly having to weigh decisions on the cost of being certain something will be perfect compared to the risks that it will go wrong if they make a mistake. When talking about "applied practices and principles", I think more attention needs to be spent on how to balance the best possible practices with maintaining a timeline.

I think that this is going to be better as a textbook or reference book for the vast majority of people. I can certainly see someone keeping it on their bookshelf so that it's available to flip to a specific chapter and get some suggestions on how to deal with an issue on a project. For the average person who's interested in improving their understanding of how to go from blank screen to solid software, I think this book is so dense with information that you're more likely to walk away feeling a bit dizzy rather than feeling informed.

Also, for those screen shots and code samples that are included, they tend to focus heavily on Microsoft products. In most cases this makes very little difference, but at times he does make specific reference to Microsoft tools and portions of the interface to the Windows operating system. Your level of familiarity with that environment may affect how easy it is for you to follow the explanations at times. Also, the code samples you get from the book's website is intended to work only with Microsoft Visual Studio 2008. It's always disappointing when a publisher of technology books doesn't make it clear in their descriptions what technologies they expect you to have at hand.

I should also add that while this is part of the "Wrox Programmer to Programmer" series, and they say it's suitable for anyone "from programmers through to software architects", I would really recommend it almost exclusively for the software architect end of the spectrum. Programmers who have a particularly strong interest in the architecture may certainly appreciate it, but for a typical programmer there are better sources on this topic out there.
5 of 5 people found the following review helpful
Smart author, bad book. Oct. 8 2009
By Kelly Sottelbaum - Published on Amazon.com
Format: Paperback Vine Customer Review of Free Product
At first, I was reading this pretty closely, as I've been involved in the designing, development, architecture, testing, deploying, etc. of systems for years, and anything to add to the arsenal of ideas is always welcome.

As chapter after chapter went on, I came to realize that the author, who is obviously smart and well versed in a swath of various ideas, and technologies kept repeating the same mantra over and over without actually bringing something new to the conversation. After that, while still reading the book, it was mostly skimming, and cringing every time I saw the same couple buzzwords of phrases that are repeated ad nauseum throughout.

If you're a software architect, you already know what's in this book.
If you're a software engineer, you do too.
If you're a product manager...this book might help to understand the full cycle and all the intertwined pieces. (However, in all my positions, the product manager has always been fully aware of the reaches and impacts the software to the business - that's really part of their job.)

I really couldn't recommend this book to anyone except maybe somebody right out of college that might want a better understanding of the full cycle and implications of implementations. (It's not about how fast you can slam out code, bug-free or not...) Or maybe some business folks that want a higher-level understanding of the systems, but don't really need to know much of anything in particular.

I've purchased plenty of Wrox books in the past, and this one, I'm sorry to say, just doesn't bring anything useful to the table that a professional in the field (the audience that Wrox publishes for) wouldn't already know.
2 of 2 people found the following review helpful
Decent, If a Bit Jumbled In Delivery Dec 17 2009
By John Nolley II - Published on Amazon.com
Format: Paperback Vine Customer Review of Free Product
Let me disclose that I'm not typically a huge fan of the Wrox to begin with; I tend to prefer the O'Reilly texts on software topics when available. However, given my current role at work--as a Lead Engineer, I'm responsible for both the "dirty" work of actual programming as well as much of the architecture, testing, and evaluation phases of production--I felt I'd give this book a try.

I never could really find the right "pace" with "Design - Build - Run," though, and I blame the book itself for much of that. The level of granularity and detail at which the topics within are addressed varies greatly (even within chapters), and there were many places I found myself wondering exactly why I needed to be told what the author stated. In fact, I'd almost characterize "Design - Build - Run" as an overview of things most of us already know and should be putting into practice; a lot of it read just like the computer-based training "courses" my employer offers us each year on software architecture and engineering (which I don't particularly find engaging or all that useful). It's a far cry, though, from the sort of material I'd expect to be covered in even a bachelor-level program in Software Engineering, and it's not quite a survey of industry best practices and use cases, either.

The author even admits to some of this varying focus in stating the book isn't a project management reference, nor a compendium of technology-specific best practices. He then goes on to state that the book focuses on the technical aspects of production-ready software development (and, let's be honest: given the timeframes and budgets of the vast majority of software development projects, creating "production-ready" code is really the goal of almost every development team). However, I didn't find the book all that technical where I felt it needed to be, and in other places, the level of attention to technical detail was needlessly involved.

Personally, for a more-focused look at best practices, I'd suggest Steve McConnell's fantastic Rapid Development: Taming Wild Software Schedules. Yes, "Design - Build - Run" covers broader ground than McConnell's book... but as both a developer and an architect (and now increasingly a project manager) I found his text much more applicable to my day-to-day job.
2 of 2 people found the following review helpful
Does software construction have to invariably involve working very long hours and attending countless meetings? Sept. 27 2009
By Petunias - Published on Amazon.com
Format: Paperback Vine Customer Review of Free Product
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 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.
2 of 2 people found the following review helpful
One Heavy Read Oct. 15 2009
By T. Anderson - Published on Amazon.com
Format: Paperback Vine Customer Review of Free Product
This book is one heavy read. It covers a ton of information and at times it seems as though there may be too much. The writing style is that of a technical writer and the way the book is laid out it makes it difficult to read sometimes. This is not particularly a ding on the book, it is just that I am not used to such large paragraph's and this type of layout.

The book reminds me of a government development context. It is one of the few books that covers batch designed and implementation. The book has some very good examples of how to do documentation, especially the use case section and the storyboard section in the case study. I think as a whole the book would be a good read for someone who has not had exposure to larger development environments.

The one thing the author does do is present the material in the context of the large development effort. Most books don't try to tackle such a task. They usually stick to small case studies were small examples of implementing module level software.

The author also digs deep into certain subjects, actually very deep. All in all I would recommend this book to someone who has not had the opportunity to be part of a large system design, and would like exposure to the artifacts and processes involved in a larger environment.


Feedback