How to use this Book: Intro
Note
In this section we answer the burning question: “So why DID they put that in a software architecture book?”
Who is this book for?
If you can answer “yes” to both of these:
Do you want to learn what software architecture is all about?
Do you prefer stimulating dinner-party conversation to dry, dull academic lectures?
This book is for you.
Who should probably back away from this book?
If you can answer “yes” to any of these:
Are you completely new to the tech industry?(While we firmly believe that software developers should understand the basics of software architecture, you might want to get a bit of experience developing software before diving into this book.)
Are you a seasoned software architect looking for a reference book?
Are you afraid to try something new? Would you rather sit in a corner licking 9-volt batteries than advance your career? Do you believe that a technical book can’t be serious if it uses zoo animals to explain architectural characteristics like scalability and fault tolerance?This book is not for you.
Note
[Note from marketing: This book is for anyone with a credit card.]
We know what you’re thinking
“How can this be a serious book on software architecture?”
“What’s with all the graphics?”
“Can I actually learn it this way?”
We know what your brain is thinking
Your brain craves novelty. It’s always searching, scanning, waiting for something unusual. It was built that way, and it helps you stay alive.
So what does your brain do with all the routine, ordinary, normal things you encounter? Everything it can to stop them from interfering with the brain’s real job—recording things that matter. It doesn’t bother saving the boring things; they never make it past the “this is obviously not important” filter.
How does your brain know what’s important? Suppose you’re out for a day hike and a tiger jumps in front of you. What happens inside your head and body?
Neurons fire. Emotions crank up. Chemicals surge.
And that’s how your brain knows...
This must be important! Don’t forget it!
But imagine you’re at home, or in a library. It’s a safe, warm, tiger-free zone. You’re studying. Getting ready for an exam. Or trying to learn some tough technical topic your boss thinks will take a week, 10 days at the most.
Just one problem. Your brain’s trying to do you a big favor. It’s trying to make sure that this obviously unimportant content doesn’t clutter up scarce resources. Resources that are better spent storing the really big things. Like tigers. Like the danger of fire. Like how you should never have posted those “party” photos on your Facebook page. And there’s no simple way to tell your brain, “Hey brain, thank you very much, but no matter how dull this book is and how little I’m registering on the emotional Richter scale right now, I really do want you to keep this stuff around.”
Metacognition: Thinking about thinking
If you really want to learn, and you want to learn more quickly and more deeply, pay attention to how you pay attention. Think about how you think. Learn how you learn.
Most of us did not take courses on metacognition or learning theory when we were growing up. We were expected to learn, but rarely taught to learn.
But we assume that if you’re holding this book, you really want to learn what software architecture is all about. And you probably don’t want to spend a lot of time on it. If you want to use what you read in this book, you need to remember what you read. And for that, you’ve got to understand it. To get the most from this book, or any book or learning experience, take responsibility for your brain. Your brain on this content.
The trick is to get your brain to see the new material you’re learning as Really Important. Crucial to your well-being. As important as a tiger. Otherwise, you’re in for a constant battle, with your brain doing its best to keep the new content from sticking.
So just how DO you get your brain to treat software architecture like it’s a hungry tiger?
There’s the slow, tedious way, or the faster, more effective way. The slow way is about sheer repetition. You obviously know that you are able to learn and remember even the dullest of topics if you keep pounding the same thing into your brain. With enough repetition, your brain says, “This doesn’t feel important, but they keep looking at the same thing over and over and over, so I suppose it must be.”
The faster way is to do anything that increases brain activity, especially different types of brain activity. The things on the previous page are a big part of the solution, and they’re all things that have been proven to help your brain work in your favor. For example, studies show that putting words within the pictures they describe (as opposed to somewhere else on the page, like a caption or in the body text) causes your brain to try to make sense of how the words and picture relate, and this causes more neurons to fire. More neurons firing = more chances for your brain to get that this is something worth paying attention to, and possibly recording.
A conversational style helps because people tend to pay more attention when they perceive that they’re in a conversation, since they’re expected to follow along and hold up their end. The amazing thing is, your brain doesn’t necessarily care that the “conversation” is between you and a book! On the other hand, if the writing style is formal and dry, your brain perceives it the same way you experience being lectured to while sitting in a roomful of passive attendees. No need to stay awake.
But pictures and conversational style are just the beginning…
Here’s what WE did
We used visuals, because your brain is tuned for visuals, not text. As far as your brain’s concerned, a visual really is worth a thousand words. And when text and visuals work together, we embedded the text in the visuals because your brain works more effectively when the text is within the thing the text refers to, as opposed to in a caption or buried in a paragraph somewhere.
We used redundancy, saying the same thing in different ways and with different media types, and multiple senses, to increase the chance that the content gets coded into more than one area of your brain.
We used concepts and visuals in unexpected ways because your brain is tuned for novelty, and we used visuals and ideas with at least some emotional content, because your brain is tuned to pay attention to the biochemistry of emotions. That which causes you to feel something is more likely to be remembered, even if that feeling is nothing more than a little humor, surprise, or interest.
We used a personalized, conversational style, because your brain is tuned to pay more attention when it believes you’re in a conversation than if it thinks you’re passively listening to a presentation. Your brain does this even when you’re reading.
We included dozens of activities, because your brain is tuned to learn and remember more when you do things than when you read about things. And we made the exercises challenging yet doable, because that’s what most people prefer.
We used multiple learning styles, because you might prefer step-by-step procedures, while someone else wants to understand the big picture first, and someone else just wants to see an example. But regardless of your own learning preference, everyone benefits from seeing the same content represented in multiple ways.
We included content for both sides of your brain, because the more of your brain you engage, the more likely you are to learn and remember, and the longer you can stay focused. Since working one side of the brain often means giving the other side a chance to rest, you can be more productive at learning for a longer period of time.
And we included stories and exercises that present more than one point of view, because your brain is tuned to learn more deeply when it’s forced to make evaluations and judgments.
We included challenges, with exercises, and we asked questions that don’t always have a straight answer, because your brain is tuned to learn and remember when it has to work at something. Think about it—you can’t get your body in shape just by watching people at the gym. But we did our best to make sure that when you’re working hard, it’s on the right things. That you’re not spending one extra dendrite processing a hard-to-understand example or parsing difficult, jargon-laden, or overly terse text.
We used people. In stories, examples, visuals, etc., because, well, because you’re a person. And your brain pays more attention to people than it does to things.
Here’s what YOU can do to bend your brain into submission
So, we did our part. The rest is up to you. These tips are a starting point; listen to your brain and figure out what works for you and what doesn’t. Try new things.
Note
Cut this out and stick it on your refrigerator.
Slow down. The more you understand, the less you have to memorize.Don’t just read. Stop and think. When the book asks you a question, don’t just skip to the answer. Imagine that someone really is asking the question. The more deeply you force your brain to think, the better chance you have of learning and remembering.
Do the exercises. Write your own notes.We put them in, but if we did them for you, that would be like having someone else do your workouts for you. And don’t just look at the exercises. Use a pencil. There’s plenty of evidence that physical activity while learning can increase the learning.
Read the “There Are No Dumb Questions.”That means all of them. They’re not optional sidebars, they’re part of the core content! Don’t skip them.
Make this the last thing you read before bed. Or at least the last challenging thing.Part of learning (especially the transfer to long-term memory) happens after you put the book down. Your brain needs time on its own, to do more processing. If you put in something new during that processing time, some of what you just learned will be lost.
Talk about it. Out loud.Speaking activates a different part of the brain. If you’re trying to understand something, or increase your chance of remembering it later, say it out loud. Better still, try to explain it out loud to someone else. You’ll learn more quickly, and you might uncover ideas you hadn’t known were there when you were reading about it.
Drink water. Lots of it.Your brain works best in a nice bath of fluid. Dehydration (which can happen before you ever feel thirsty) decreases cognitive function.
Listen to your brain.Pay attention to whether your brain is getting overloaded. If you find yourself starting to skim the surface or forget what you just read, it’s time for a break. Once you go past a certain point, you won’t learn faster by trying to shove more in, and you might even hurt the process.
Feel something.Your brain needs to know that this matters. Get involved with the stories. Make up your own captions for the photos. Groaning over a bad joke is still better than feeling nothing at all.
Apply it every day!There’s only one way to learn how to really understand software architecture: apply it every day. You are going to be doing software architecture a lot in this book, and like with any other skill, the only way to get good at it is to practice. We’re going to give you a lot of practice: every chapter has exercises that pose problems for you to solve. Don’t just skip over them—a lot of the learning happens when you solve the exercises. We included a solution to each exercise—don’t be afraid to peek at the solution if you get stuck! (It’s easy to get snagged on something small.) But try to solve the problem before you look at the solution. And definitely get it working before you move on to the next part of the book.
Read me
This is a learning experience, not a reference book. We deliberately stripped out everything that might get in the way of learning whatever it is we’re working on at that point in the book. And the first time through, you need to begin at the beginning, because the book makes assumptions about what you’ve already seen and learned.
We break things down, then build them back again.
We are fans of teasing things apart. This gives us the chance to focus on one aspect of software architecture at a time. We use a lot of visuals to explain various aspects of software architecture. We make sure you have a deep understanding of each aspect, and have the confidence to know when and how to use them. Only then do we start to bring things together, to explain the more complex ideas in software architecture.
We don’t exhaustively cover everything.
We use the 80/20 approach. We assume that if you are going for a PhD in software architecture, this isn’t going to be your only book. So, we don’t talk about everything—just the stuff that you’ll actually use, and that you need to hit the ground running. We want to hit the ground running.
The activities are NOT optional.
The exercises and activities are not add-ons; they’re part of the core content of the book. Some of them are to help with memory, some are for understanding, and some will help you apply what you’ve learned. Don’t skip the exercises. The crossword puzzles are the only thing you don’t have to do, but they’re good for giving your brain a chance to think about the words and terms you’ve been learning in a different context.
The redundancy is intentional and important.
One distinct difference in a Head First book is that we want you to really get it. And we want you to finish the book remembering what you’ve learned. Most reference books don’t have retention and recall as a goal, but this book is about learning, so you’ll see some of the same concepts come up more than once.
The examples are as generic as possible.
To teach you software architecture, we have to use business problems—otherwise, the concepts we introduce in this book would be too abstract and hard to follow. We’ve deliberately made the examples in this book generic, yet also interesting, fascinating, and downright fun. No matter your background, we are certain you will be able to relate to them when practicing software architecture, whatever kind of work you do.
The Brain Power exercises don’t always have answers.
For some of them, there is no right answer, and for others, part of the learning experience is for you to decide if and when your answers are right. In some of the Brain Power exercises, you will find hints to point you in the right direction.
O’Reilly online learning
For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed.
Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit http://oreilly.com.
Do it yourself chapters
A unique aspect of this particular Head First book is what we call “do it yourself” chapters. These chapters (there are two of them) are entirely exercise-based and give you a chance to create an architecture from beginning to end, applying all the concepts you’ve learned up to that point.
In these chapters, you’re the software architect. You’ll determine architectural characteristics, build a logical architecture, and make architectural decisions, including what kind of architectural style to use. Doing the exercises in these chapters gives you an end-to-end view of what a software architect does and shows you how much you’ve learned.
In Chapter 9, the first “do it yourself” chapter, you’ll create an architecture for a trip-management system called TripEZ (pronounced like “trapeze”) that aims to make travel easier, especially for road warriors. This new online trip-management dashboard app will allow travelers to see and manage all of their travel reservations, organized by trip, through a browser or on their mobile devices.
In Chapter 12, the second “do it yourself” chapter, you’ll create an architecture for a standardized-testing system called Make the Grade. All Dataville Public School students in specific grade levels take the same test to determine how well students, teachers, and the school are doing. This chapter will be a great way for you to test your knowledge (so to speak).
The technical review team
Meet our review team!
We were lucky enough to round up a powerhouse team of people to review this book, including senior developers, software architects, renowned public speakers, and prolific book authors.
These experts read every chapter, did the exercises, corrected our mistakes, and provided detailed commentary on every single page of this book. They also acted as our sounding board, letting us work through ideas, analogies, and narratives. They even helped us think through how this book should be organized.
Every single reviewer here made huge contributions to this book and vastly improved its quality. We deeply appreciate the countless hours they spent poring over the manuscript. We remain indebted to them.
Note
Special thanks also to Moataz Sanad for finding lots of our typos!
Note
Despite our (and our reviewers’) best efforts, any and all errors and omissions are ours and ours alone.
Thank you!
Joint acknowledgments
This book would not have been possible without the help, guidance, and support from a number of great individuals. We have a lot of people to thank, so let’s get started!
Our editor:
Our first and foremost acknowledgment goes, along with our utmost thanks, to our brilliant editor Sarah Grey. Writing a book like Head First Software Architecture presented a number of unique challenges for us, and Sarah was there to guide us the entire time. She helped keep us on track when we deviated from the Head First style of writing (which was quite often) and made constant suggestions about every page’s layout (really, we mean every page). Sarah took on the role of crossword expert and helped us out quite a bit with the Make It Stick poetry. We frequently referred to Sarah as our “fourth author,” and in reality, she deserves much of the credit for the outcome of this book.
The O’Reilly team:
A big thanks to the entire O’Reilly Media team, including Kristen Brown and Chris Faucher for making sure that our book was production-worthy, and to Rachel Head for her keen and astute copyediting eye. And if, like us, you routinely use book indexes, you have Tom Dinse to thank for this one.
We’d also like to thank Melissa Duffield for her continued support and patience throughout this process, and for considering us for this long project.
Much appreciation to the O’Reilly online training team, especially Yasmina Greco, Lindsay Ventimiglia, and all the producers, for giving us a platform to teach software architecture to thousands of developers and architects around the world.
A shoutout to the Early Release team, who put out raw and unedited chapters as they were written for the audience on the O’Reilly platform to review. This gave many of our readers a chance to submit errata and feedback that made this book just that much better.
Finally, we would be remiss if we did not mention series editors Elisabeth Robson and Eric Freeman, who took the time to review our work and ensure that it aligned with the vision that is the Head First series—not to mention giving us some really useful InDesign tips. Thank you!
Individual acknowledgments
From Raju Gandhi:
It’s hard for me to express how much of a privilege it has been to work on this project, and to be able to work with Mark and Neal—two of the smartest and most wonderful human beings, who not only were kind enough to consider me as a coauthor, but who since have spent countless hours teaching me the nuances of software architecture. Someday I hope I can repay that debt. For now, they have my deepest appreciation. A shoutout to so many friends, colleagues, unwitting mentors and teachers, and fellow speakers who’ve been a source of inspiration for me—you all know you who are. And finally, to my wife Michelle. We had baby Delphine while I was working on this project, and Michelle has certainly taken on more than her share as I spent many an hour working on this book. Thank you. I love you both.
From Mark Richards:
In addition to the joint acknowledgments, I would like to thank my friends and coauthors Raju and Neal. Raju brought prior Head First experience to the table from his great book Head First Git, and helped teach us the Head First style of writing and the ins and outs of InDesign. This is my third book with Neal, and as usual, working and collaborating with him was a very rewarding and enjoyable experience. I would also like to thank my lovely wife Rebecca for her patience and understanding while I was hidden away in my office for so many evenings writing this book instead of enjoying her company.
From Neal Ford:
I would like to thank first and foremost my coauthors, Mark and Raju, both of whom were a delight to work with and made this book possible. Mark is as always a fantastic collaborative juggernaut with a good sense of humor, both vital when writing is not our day job. I’d also like to thank our editor Sarah, who has an outsized role in this book series, for helping keep us in check. Thanks also to my extended families, both genetic and chosen, for their support and respite. That includes our weekly neighborhood cocktail club that moved to the parking lot during the pandemic and stayed there; it’s great to catch up with what is happening nearby. And finally and primarily, I’d like to thank my wonderful wife Candy, who endures many long hours with me away from her and our cats, working on stuff like what you hold in your hand.
Note
Good thing we only had three authors, or these acknowledgments would go on and on and on...
And finally, you, the readers. Your attention is a scarce resource, and we deeply appreciate the time you’ll spend with this book. Happy learning.
Get Head First Software Architecture now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
