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.
