Emergent Design : The Evolutionary Nature of Professional Software Development

by Bain, Scott

• ISBN13: 9780321509369
• ISBN10: 0321509366
• Edition: 1st
• Format: Hardcover
• Copyright: 2008-02-27
• Publisher: Addison-Wesley Professional

Summary

Spells out an ultra-contemporary, completely realistic, and thoroughly actionable approach toward the software development lifecycle.

Author Biography

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.

Table of Contents

Series Foreword	p. xvii
Preface	p. xxiii
Acknowledgments	p. xxix
About the Author	p. xxxi
Software as a Profession	p. 1
How Long Have Human Beings Been Making Software?	p. 1
What Sort of Activity Is Software Development?	p. 2
What Is Missing?	p. 6
Who Is Responsible?	p. 8
Uniqueness	p. 9
Out of the Closet, Off to the Moon	p. 11
Patterns and Professionalism in Software Development	p. 11
Andrea s Closet	p. 12
Off to the Moon	p. 18
The Value of Patterns	p. 26
Summary	p. 27
The Nature of Software Development	p. 29
We Fail Too Much	p. 30
Definitions of Success	p. 31
The Standish Group	p. 32
Doing the Wrong Things	p. 34
Doing the Things Wrong	p. 35
Time Goes By, Things Improve	p. 38
One Reason: The Civil Engineering Analogy	p. 38
Giving Up Hope	p. 41
Ignoring Your Mother	p. 42
Bridges Are Hard, Software Is Soft	p. 43
We Swim in an Ocean of Change	p. 43
Accept Change	p. 44
Embrace Change	p. 45
Capitalize on Change	p. 46
A Better Analogy: Evolving Systems	p. 49
Summary	p. 52
Evolution in Code: Stage 1	p. 55
Procedural Logic Replaced with Object Structure	p. 56
The Origins of Object Orientations and Patterns	p. 56
An Example: Simple Conditionals and the Proxy Pattern	p. 58
The Next Step: Either This or That	p. 62
Why Bother?	p. 65
One Among Many66
Summary	p. 67
Using and Discovering Patterns	p. 69
Design from Context: More Carpentry from Scott	p. 70
Patterns Lead to Another Cognitive Perspective	p. 79
Patterns Help Give Us a Language for Discussing Design	p. 79
Patterns in This Book	p. 80
Summary	p. 81
Building a Pyramid	p. 83
Elements of the Profession	p. 83
A Visual Representation	p. 85
Summary	p. 86
Paying Attention to Qualities and Pathologies	p. 89
Encapsulation	p. 91
Cohesion	p. 91
Coupling	p. 99
Redundancy	p. 106
Testability	p. 112
Readability	p. 114
Pathologies	p. 114
Summary	p. 119
Paying Attention to Principles and Wisdom	p. 121
Separating Use from Creation	p. 122
The Open-Closed Principle	p. 129
The De
Table of Contents provided by Publisher. All Rights Reserved.

Excerpts

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 bittoohard. I don't want it to be easy; I'm not asking for that. I just want it to be alittleeasier, 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 estimatesat least most of the time. I'd like to feel like I know what I'm doing. Reallyknow. 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 9we 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 callthe 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 (orprogrammers,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 thenatureof 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.<