Automotive Holiday Deals Books Gift Guide Books Gift Guide Shop Men's Athletic Shoes Learn more nav_sap_SWP_6M_fly_beacon Adele egg_2015 All-New Amazon Fire TV Subscribe & Save Gifts Under $50 Amazon Gift Card Offer bf15 bf15 bf15 $30 Off Amazon Echo Starting at $49.99 Kindle Black Friday Deals Outdoors Gift Guide on Tikes
Emergent Design: The Evolutionary Nature of Professional... and over one million other books are available for Amazon Kindle. Learn more

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.

  • Apple
  • Android
  • Windows Phone
  • Android

To get the free app, enter your email address or mobile phone number.

Emergent Design: The Evolutionary Nature of Professional Software Development 1st Edition

14 customer reviews
ISBN-13: 978-0321509369
ISBN-10: 0321509366
Why is ISBN important?
This bar-code number lets you verify that you're getting exactly the right version or edition of a book. The 13-digit and 10-digit formats both work.
Scan an ISBN with your phone
Use the Amazon App to scan ISBNs and compare prices.
Sell yours for a Gift Card
We'll buy it for $2.00
Learn More
Trade in now
Have one to sell? Sell on Amazon
Buy used
Condition: Used - Good
In Stock. Sold by HPB-Dallas
Condition: Used: Good
Comment: Item may show signs of shelf wear. Pages may include limited notes and highlighting. Includes supplemental or companion materials if applicable. Access codes may or may not work. Connecting readers since 1972. Customer service is our top priority.
Access codes and supplements are not guaranteed with used items.
21 Used from $17.73
+ $3.99 shipping
More Buying Choices
8 New from $63.84 21 Used from $17.73
Free Two-Day Shipping for College Students with Amazon Student Free%20Two-Day%20Shipping%20for%20College%20Students%20with%20Amazon%20Student

Get Up to 80% Back Rent Textbooks

Special Offers and Product Promotions

  • Take an Extra 30% Off Any Book: Use promo code HOLIDAY30 at checkout to get an extra 30% off any book for a limited time. Excludes Kindle eBooks and Audible Audiobooks. Restrictions apply. Learn more

Editorial Reviews

About the Author

Scott L. Bain is a thirty-year veteran in computer technology, with a background in development, engineering, and design. He has also designed, delivered, and managed training programs for certification and end-user skills, both in traditional classrooms and via distance learning. For the past eight years, Scott has been working for Net Objectives in Puget Sound, teaching courses and consulting on design patterns, refactoring, unit testing, and test-driven development. Along with Net Objectives CEO Alan Shalloway, he has contributed significantly to the integration of design patterns in Agile environments. Scott is a frequent speaker at developer conferences such as JavaOne and SDWest.

Excerpt. © Reprinted by permission. All rights reserved.

Designing and creating software is hard.

I like that it’s hard. I like a challenge. I like solving puzzles. That’s probably what attracted me to computers and programming in the first place.

It’s just that it’s a little bit too hard. I don’t want it to be easy; I’m not asking for that. I just want it to be a little easier, a little more predictable, and a little less chaotic.

I’d like to be able to tell someone, at the beginning of a project, what my software will generally be able to do when it’s done, and feel confident that I’m right in what I’m saying. I’d like to be able to tell how long it will take to get the project done, and how much, generally, it will cost. And, I would like to be successful in these predictions and estimates—at least most of the time.

I’d like to feel like I know what I’m doing. Really know.

Anyone who has developed any complex software has surely had this experience: at about month 9 of a 12-month project, we’re fine; we’re on-track. At month 10, we’re 4 months behind. How is that possible? Obviously, we were not fine at month 9—we just thought we were. Why didn’t we know?

Or, perhaps we have a working system, one that seems just fine, and then the end users want some new function or capability. It is a reasonable request. Things change; we know that. The pace and scope of change in our world is on the rise.

But when we try to make the change the customer wants, things seem to fall apart in unpredictable ways. It makes us hesitant, knowing this can happen. It makes us resistant, even hostile at the prospect of accommodating such changes. The longer a person has been in development, the more likely he is to feel such resistance.

This is not our fault.

Software development has not been around for very long, in the grand scheme of things. Other, similarly complex endeavors (medicine, the law, architecture, and so on) have been around for hundreds, even thousands, of years, and in that time a whole set of standards, practices, and general wisdom has been captured and handed down from generation to generation. This has helped to increase the rate of predictable success for each new batch of doctors, lawyers, and builders, and in each case has led to the formation of an organism we call the profession.

Professions have their own lives, their own existence. For example, the profession of carpentry has been around for thousands of years, though no carpenter is that old. Professions provide a sort of safety net for those individuals in their practice.

The purpose of this book is to examine what we need, as software developers (or programmers, if you like), to get that kind of value from what we do, from each other, and from the practice itself. I’d like to take a step back, look at the nature of what we’re doing, and derive a set of best practices, general wisdom, and specific patterns of activity that will elevate our business into a true profession, or something akin to that, with all the benefits that such a thing provides.

However, it’s not my intention to stay purely theoretical, as interesting as that might be. I want to talk about real things, about the aspects of software development that are too hard, that are too limiting, and to suggest better ways of going about this job. I want to focus on things that are truly valuable.

My contract with you is this: Everything I will investigate, suggest, present, demonstrate, and so on, will have as its core intent the goal of improving our lot as creators of software. No matter how interesting or compelling a thing might be, if there’s nothing “in it for us,” then I’m going to leave it out.

One thesis I’m going to start off with right now is this: Software development, by its very nature, is a process of evolution. We do not analyze, design, and build; we create something that works, is of high quality, and is valuable as it stands, and then we evolve it in stages toward the product that the world needs. I’ve got a long way to go to demonstrate this, and in order to get there I’m going to need a set of supportive concepts and techniques.

Here are the things I’ll start off examining.


How do we know when software is good? Because it works? We all know plenty of software that works but is not good. When presented with two or three ways of doing something, how do we determine which one is best? What does best mean? Following the general tenet of this book, best should have something to do with value to the developer, and a resulting increase in success, which yields value to the customer. The qualities we will focus on provide this kind of in-the-moment guidance that can help us make better decisions, more reliably: coupling, cohesion, eliminating redundancy, making things testable, and the granddaddy of them all: encapsulation. Included in this discussion will be those negative indicators (pathologies) that can help us to see when one or more of these qualities is not being adhered to.


What are the fundamental theories that define good software? In other words, what are the points of view we can take on a system that give us a better chance at achieving the qualities, after we know what those are? Principles say “this is better than that” or “this is more important than that.” Principles promise better results in terms of the qualities we will emphasize, given that software needs to be able to change in order to meet the needs of a changing world.


Practices are things that you can do as part of your day-to-day coding activities, which will help you in significant ways. The practices I am most interested in are those that help you in multiple ways, and yet are not a burden. Lots of bang, little bucks. Also, since practices are truly valuable when they are shared and promoted to all the developers on a team (or in an organization or even, perhaps, to the profession), they should be things that are easy to teach others to do.


Similar to practices, disciplines are things you should do, but they are larger scale, take longer to learn, and are not without cost. However, the value they offer is so fundamental and profound as to make them worth the effort and time they require. Unit testing and refactoring are examples of disciplines, as is the notion of test-driven development. I’ll cover them all.


Patterns represent what we’ve done before that has worked. But I don’t mean just a cookbook or a set of templates; software is more complicated than that. By a pattern I mean the set of interrelated points of wisdom that reflect what we, as a group, know about certain situations, those that we find ourselves in again and again. We’ve been there as a profession, even if some of us have not as individuals. Patterns are a way of sharing the wealth of experience, as a community of colleagues, and supporting one another toward greater success. Patterns are different from principles in that they are contextual. Principles apply generally; patterns apply differently in different situations. We’ll examine these concepts in terms of each pattern’s forces, and see how this view of patterns makes them much more useful to us than simply canned designs would be. There are lots of patterns, and lots of patterns books, so I provide an appendix that contains an overview of the patterns I use in the book to illustrate their role in an emergent design.


In general, how does software development work? How do we find out what we need to build? How do we know when we’re done? How do we know when we’re on track? And more importantly, how do we know when we’re not on track? When we are off track, what do we do? I’ve tipped my hand already a bit in suggesting that creating software is an evolutionary process, but that’s obviously just the seed of the idea.

I’m not alone in this pursuit, of course. In this book, I definitely draw upon the work of others including Alan Shalloway, Martin Fowler, Ward Cunningham, Kent Beck, Ron Jeffries, and Robert Martin, just to name a few. I’ve learned a great deal from these people and others like them, and I acknowledge their efforts in the Bibliography and point you to the resources they have provided our profession.

I’ve been accused of being developer-centric, as have some of the colleagues I just mentioned. In my case, this is true. I focus on the developer not just because I am one myself, but also because I believe if we want better software, we need to do a better job supporting development. To me this means a focus on the developer (e.g., an important part of quality health care is making good doctors). It does not mean that I value software if it does not get used: Unused software is worthless, in my opinion. Therefore, while I certainly focus on those things that help developers succeed, the goal is better software and the right software, which certainly will benefit all concerned.

There is other work to be done, certainly. I do not pretend to have solved the problem by bringing valuable ideas and practices to my fellow developers; but this is my part along the way.

I believe strongly that software development is on the brink of becoming a profession—in the true sense of the word—and that going that last mile, filling in the missing pieces, is one of the most important activities of our current era. In years to come, I think we will look back at this time and realize that this was the era when software development matured to the degree that it could reliably meet the needs of the modern world, and I’m very excited to be a part of it.

So, let’s begin.


Hero Quick Promo
Holiday Deals in Kindle Books
Save up to 85% on more than 1,000 Kindle Books. These deals are valid until November 30, 2015. Learn more

Product Details

  • Hardcover: 448 pages
  • Publisher: Addison-Wesley Professional; 1 edition (March 8, 2008)
  • Language: English
  • ISBN-10: 0321509366
  • ISBN-13: 978-0321509369
  • Product Dimensions: 7.2 x 1 x 9.3 inches
  • Shipping Weight: 1.8 pounds
  • Average Customer Review: 4.1 out of 5 stars  See all reviews (14 customer reviews)
  • Amazon Best Sellers Rank: #1,933,178 in Books (See Top 100 in Books)

More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

Most Helpful Customer Reviews

52 of 54 people found the following review helpful By Bas Vodde on July 16, 2008
Format: Hardcover
Emergent Design by Scott Bain is a interesting book. The title is very promising, when I first heard about it, I got very excited! Finally a book about how designs emerge, how designs emerge from multiple people and how designs evolve over time compared to specifying. After reading the book, I felt the book was good, but disappointing. It did not cover the topics I would like to have seen.

The general idea of the book is that software should grow better over time instead of decay over time and that the optimal design will emerge. An idea I strongly agree with. The author links this to software development needing to change to become a profession. If SW development is a profession, then people will use proper practices and design will emerge. The practices (in a broad sense) are principles of design, patterns and disciplines. After the first couple of chapters the book was having a good start, though I started wondering if the author didn't bite of more than he could chew. Those are huge topics by themselves!

From chapter 7 to chapter 14 the author just describes good practices. He starts with qualities of code and qualities of designs. He moves to unit-testing, refactoring and then Test-Driven-Development. He ends with the pattern chapter. The last chapter puts all things together in a case study. Scott does a reasonable job in describing all practices. There are a couple of weird things, like the recommendation that every class has exactly one test class. The TDD chapter also seems to have very little TDD in it :)

As a catalog of best practices, this book perhaps does the best of all the current agile related books. Great job by the author.

However, there are some things that personally bothered me. The book seems to be very pattern focused.
Read more ›
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
8 of 8 people found the following review helpful By D. Raymer on April 27, 2009
Format: Hardcover
I've just completed reading "Emergent Design: The Evolutionary Nature of Professional Software Development" by Scott L. Bain; I found the author's writing style to be engaging which made for an easy read. However, from my perspective (someone who has been in the trenches of software development for the past 20 years) I found nothing new in this book for the seasoned professional.

If you are just starting out, I would recommend this book; if you call yourself a programmer, I would recommend this book. However, if you are a trained software professional, and already understand that the phrase "software as an engineering discipline" is an oxymoron, then I would recommend you spend your time elsewhere. This book simply puts into written words what we already know -- waterfall development doesn't work for systems where the requirements aren't well understood or are subject to change during the development effort. The author adequately discusses the importance of patterns and their importance to modern software systems, the importance of paying attention to the details not found in the software, and the fact that you need to get over fear of change. In my opinion, the author does not offer any new insights.

Again, if you are just starting out, or have no exposure to object-oriented theory/practice, patterns and iterative-and-incremental development, this book is a good introductory text. If you are looking for advanced knowledge, in my opinion, its not here.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
14 of 16 people found the following review helpful By Tad Anderson VINE VOICE on April 1, 2008
Format: Hardcover Verified Purchase
This book is a gold mine of wisdom.

This book contains a ton of wisdom that has come out of the software engineering field over the years. It brings together a lot of software development best practices that can be found in other resources and puts them together under the umbrella of Emergent Design.

He covers patterns, principles, processes, and practices by presenting the best of each that has been proven to work again and again. The common sense communicated out of this book is priceless.

The author has a presentation that touches on a lot of the content found in the book. It can be viewed by Googling for "EmergentDesign_12_11_2007".

Forward thinking is something that I find lacking in a lot of the environments I am exposed too, especially development environments. This book nails how to do forward thinking when it comes to software design and development. You will end up making your solutions more valuable with each change, instead of degrading them with each change if you follow the advice in this book.

If you do development, this is a must read. I would advise all team leads to get rid of anyone who has not read this book by the end of the year.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
Format: Paperback
For those who've complained about the title being misleading, what did you expect? As the author clarifies in the chapter on refactoring, emergent design is all about continuously changing code to improve it, to make it easier to add new features and to make it easier to find bugs. The author appropriately makes a reference to Kerievsky's Refactoring to Patterns book, considering that Bain's book also makes extensive use of patterns and Java design idioms to improve code.

My favorite part of this book is actually at the end where the author provides brief overviews of the patterns used in the book. Most helpful are the non-software examples that the author uses to drive home the goal of the pattern.

Four stars rather than five, though, because five stars ought to be reserved for seminal works like the GOF book or books from Martin Fowler's Signature Series, which I relish. Also, the book does venture into at least one contentious area. Bain's colleague, Shalloway, has suggested in his book that a Proxy can also be used to encapsulate a special function or pre-processing required to be carried out prior to calling the underlying object. Bain takes it one step further, suggesting that Proxy is like a Decorator that adds a single responsibility to the underlying class and often graduates to Decorator if multiple additional responsibilities need to dynamically be added to the base class. However, GOF and POSA clarify that although the Proxy implementation resembles that of Decorator, the two have distinctly different purposes.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse

Most Recent Customer Reviews