Programming Books C Java PHP Python Learn more Browse Programming Books
Emergent Design: The Evolutionary Nature of Professional... and over one million other books are available for Amazon Kindle. Learn more
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
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

Emergent Design: The Evolutionary Nature of Professional Software Development Hardcover – March 8, 2008

ISBN-13: 978-0321509369 ISBN-10: 0321509366 Edition: 1st

6 New from $91.50 17 Used from $10.17
Amazon Price New from Used from
Kindle
"Please retry"
Hardcover
"Please retry"
$91.50 $10.17
12%20Days%20of%20Deals%20in%20Books
NO_CONTENT_IN_FEATURE

Shop the New Digital Design Bookstore
Check out the Digital Design Bookstore, a new hub for photographers, art directors, illustrators, web developers, and other creative individuals to find highly rated and highly relevant career resources. Shop books on web development and graphic design, or check out blog posts by authors and thought-leaders in the design industry. Shop now

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.0 out of 5 stars  See all reviews (13 customer reviews)
  • Amazon Best Sellers Rank: #1,574,589 in Books (See Top 100 in Books)

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.

Qualities

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.

Principles

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

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.

Disciplines

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

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.

Processes

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.


More About the Author

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

Customer Reviews

Another key note is that automated unit testing is a great thing.
W Boudville
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.
T. Anderson
The most you will have lost is the time it takes you to read a three hundred page book and you have everything to gain.
Max Guernsey III

Most Helpful Customer Reviews

49 of 51 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. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
13 of 15 people found the following review helpful By T. Anderson TOP 1000 REVIEWERVINE 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. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
6 of 6 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. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
Format: Kindle Edition
As suggested by other customer reviews the title 'Emergent Design' might not be truly appropriate.
However this book does give an excellent view on the why we use certain design patterns, where you can use them correctly and what questions to ask yourself before using that pattern. Yes, you have a whole lot of appendix pages. Those may not be necessary if you already know about design patterns or you don't want Scott's personal opinion. But note that the 200+ pages appendix on design patterns have a more 'complete' overview of the discussed design patterns than I've ever seen in a patterns book. Scott will present you with technical examples, pseudocode, procedural analogs and non-software analogs.

This book reads easily and is, in my opinion, a great start if you want to learn about patterns. If you are an experienced OO programmer and know about design patterns, this book is not for you. For seasoned procedural programmers this can help you better understand why Object Orientation and Patterns are so important nowadays.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again

Most Recent Customer Reviews