Raju Gandhi

Wonderful! Congratulations to all the winners. We (the authors) hope that you enjoy it. We are open to feedback, and O'Reilly offers an Errata page (https://www.oreilly.com/catalog/errata.csp?isbn=0636920734123) that you can use to send it our way.

Again, congratulations. And to the members of Code Ranch—thank you for the promotion, and for the questions.

Regards,
Raju

Great question!

If you'll let me, I'd like to emphasize the point you made—Head First series has a very different approach to teaching. Not only are they are fun to read, they, like you said, are interactive, with tons of exercises to help cement your newly acquired knowledge. That is a key distinguishing factor between Head First and other books, and notably in this case, between Head First Software Architecture and Fundamentals of Software Architecture.

The two books do share some commonalities—particularly in some of the architectural styles that we cover. That said, this book goes a lot deeper into other ideas, like the distinction between design and architecture, as well as fully dedicated chapters to the four dimensions of architecture.

You are right that NOT all the material you find in Fundamentals of Software Architecture is here—but that was intentional. This book is an on-ramp to Mark and Neal's other books, and other books about software architecture in general. I wouldn't quite phrase it as "cutting corners"—the material in book was particularly crafted to be as beginner friendly as possible.

You might have surmised that these are different books, and in that regards, I wouldn't think of it as "loosing out". However, if you are looking for a progression, I'd start with Head First Software Architecture, and then move to Fundamentals of Software Architecture.

Hope this helps.

Raju

Hello Simon,

Thank you for the question. This book is meant to be an on-ramp for software developers who are interested in software architecture, "accidental architects", namely those folks who don't have the title but still end up making architectural decisions for their teams, as well as architects who'd like to look at some modern approaches to architecture.

I'd like to add that we think of this book as the first in a series of three book—the other two being https://www.amazon.com/Fundamentals-Software-Architecture-Comprehensive-Characteristics/dp/1492043451/ and https://www.amazon.com/Software-Architecture-Trade-Off-Distributed-Architectures/dp/1492086894/.

Hope this helps.

Raju

Hello Claude,

Thanks for the question. Adding to @Mark's response, one of the intended audience for the book are "accidental architects"—those who don't officially have the title but still make a lot of architectural decisions for their teams. This book offers an easy on-ramp for everyone from senior software developers to accidental architects to just those who are curious about what software architecture is all about—there's something for everyone in this book.

I mentioned this in another thread, but while a lot of developers reach for "practice" when learning a new language, framework or toolkit, what's their approach to architecture? We believe that you can "practice" architecture, and this book, with topic specific quizzes, all the way to our "DIY" chapters where you build out the complete architecture for a set of requirements gives you a lot of place to do so. And we provide our solutions to go with them—so you can compare yours with ours!

Hope this helps!
Raju

Hello Paul,

Thank you for the question. We firmly believe in the idea of an "hands-on" architect, in that, an architect can and should not shy away from writing code. It is, after all, to your point, paramount to being able to designing a good system. Thus, it behooves architects to not only stay active in the development process, but also keep up with latest trends in technology, and be able to articulate the pros/cons of technical choices.

Architecture is and should be iterative. Starting with a particular architecture in mind, you are going to hit technical constraints and impediments, which need to evaluated and the architecture adjusted. And this requires strong technical skills.

Hope this helps.

Regards,
Raju

Hey Chintan,

Thanks for the question. I'd point you to an answer I posted to a similar question in another thread. Please see https://coderanch.com/t/782445/engineering/Head-Software-Architecture-Head-Java#3571250

And to that, I'd add that good architects are about breadth, not depth. You can't know "almost all technologies"—but good architects find ways to keep their hands dirty (do code reviews, dabble in new tech) without being a bottleneck to their teams. And remember, success is in the agency of others. Good collaboration and communication skills, understanding company politics are just as important as the technology.

Good luck! Hope this helps.

Raju

Hello Geff,

We cover this topic (very briefly) in our last chapter, but to give you some insight:

- Software architects are about breadth, not depth. You need to know a little about a lot of things, so you can (see next point)
- Do effective trade-off analysis. EVERY decision you make in software architecture will involve trade-offs and it's your job to align those trade-offs against the business drivers (see next point) and technical constraints
- Understanding the business domain is critical, without which, you are not going to be able to design an effective architecture. And it gives you a lot of leverage when selling your solution to both technical and business stakeholders. Speaking of selling (see next point)
- A large part of an architect's role is to collaborate and communicate—this involves honing interpersonal, communication, writing skills and being able to navigate office politics
- Finally, you need to be able find a balance to be hands-on without being a bottleneck. This allows you to keep your technical skills sharp, stay up with the latest technical trends, all while not blocking your teams cadence.

Hope this helps,
Raju

Brilliant!

We are excited to be here, and happy to answer any questions you have about the book or software architecture in general.

Wishing you all luck in the book drawing.

Cheers,
Mark, Neal & Raju

Hello Rishi,

Thanks for the question. I see Mark already gave his insight, so let me add to that. This book starts with distinguishing design from architecture, then proceeds to detail how one should describe their architecture (there are four dimensions), and then dives deep into a handful of architectural styles (like layered and microservices.)

We've taken up an extraordinary amount of real estate in the book to give you a chance to practice architecture. Think about the last programming language or framework you learned—how did you gain expertise? You practiced, right? But how often had you had a chance to practice architecture? Well, here's your chance. In this book, there are two full chapters that we've called DIY chapters, where you are presented with a set of requirements, and you have to build out the full architecture for that problem domain. And the best part—we give you our solution, so you can compare it with yours.

If you are a software developer looking to up their skills, then we believe this is the book is the perfect on-ramp.

Regards,
Raju

Hello Vidhya,

Thank you for your post and question. I am sure Mark and Neal can provide their thoughts here as well, but let me start by saying that I, like you, am a huge fan of the Head First series. So much so, this is my second Head First book (the first being Head First Git).

Here are some of the factors that differentiate Head First Software Architecture from other architecture books:

- It's Head First! We've aimed to make the book extremely accessible to developers to up their skills to think about architecture, and even help what we call "accidental architects" get a more formal introduction to software architecture. As you know, Head First not only teaches ideas but gives you ample opportunities to exercise those skills. In fact, in this book, not only do you spend a lot of time thinking about architecture, there are two full chapters that we've called DIY chapters, where you are presented with a set of requirements, and you have to build out the full architecture for that problem domain. And the best part—we give you our solution, so you can compare it with yours
- Mark and Neal have not only written two of O'Reilly's best selling books on architecture (https://www.amazon.com/Fundamentals-Software-Architecture-Comprehensive-Characteristics/dp/1492043451/ and https://www.amazon.com/Software-Architecture-Trade-Off-Distributed-Architectures/dp/1492086894/, they are very experienced architects, and have been teaching this material to audiences around the world for close to a decade. One couldn't ask for better teachers.
- Finally, this book has a modern approach to software architecture, shedding some legacy ideas and embracing what is truly relevant in the world of software that we live in. If you've ever read a book on software architecture and felt it was too academic, well, you are in for a pleasant surprise.

As for personal experience, I believe books are extremely personal. Our experiences influence what we believe is important for the reader to know and how to teach it. All three of us have been writing software for a long time, and we know where things went right, and more importantly, when things went awry. All the lessons in this book come from the distilled knowledge we've managed to acquire over our careers.

Hope this helps.

Warm regards,
Raju

It seems to me you want to create a new file, but have Git treat it like the "parent" (in that it maintains the Git history). The only (easy) way I can think of this is to create a branch, use `git mv` to rename the "parent" (Git now knows you've renamed the file and you can trace it's history), and make your modification. However, this means that you'll lose the "parent" in that branch.

If you simply want to compare performance, then look into `git worktree` that allows you to have two branches checked out at the same time—then you can run one branch, measure performance, and repeat with the other branch.

Now if you want to keep _both_ later on, that might be a tad tricky—b/c Git knows that the "parent" was renamed to "child" so when you merge Git will attempt to rename "parent" to "child". Not sure how you'd get around that.

Reference: See https://stackoverflow.com/questions/2314652/is-it-possible-to-move-rename-files-in-git-and-maintain-their-history

Hope this helps. Feel free to reach out if you have any other questions.

Raju

...so following a policy of "squash everything that goes to master" blindly is just nonsense.

If I'm working on or overseeing a larger feature, I perform an interactive rebase before I make a pull request to the main branch. During the rebase, I will squash strongly related commits together, and I will give all resulting commits descriptive names for the changes that they introduce. Finally, the feature branch containing the squashed and rebased commits is merged to main.

Great points. FWIW, when I say I disagree with "squashing", I should have been explicit—which is the use of the "squash" button that GitLab and GitHub offer. I am completely on-board with doing interactive rebases, and if need be, squashing commits to make atomic commits.

The bottom line is—make your history clean, explicit and decipherable. And interactive rebasing buys you the best of all worlds—you can make ad-hoc, WIP commits as you are working, thereby not forcing you to break flow just to organize commits, while at the same time, making sure you have good reset points in case things go awry or a branch point if you want to try something different.

Now, if I've read Raju's answers in this topic correctly, his point is that you don't need branches for this, you just branch off of a tagged commit.

Thank you for the credit, and that is usually my stance. My reasoning is simple—if you put a bug fix on a "stable" branch, you have to bring that back everywhere else—you choose cherry-picking to get that. I prefer to branch off the tag, make the hotfix, tag again, deploy, then merge that branch back into the mainline and throw the branch away.

I have said this before, and I'll say it again—I am not one to dismiss a workflow b/c if you've conceived it, you did so b/c you had good reasons. If your environment forces you to manage multiple versions simultaneously, perhaps having long running branches pointing to "stable versions" in production makes sense.

My biggest fear with long-lived branches is that it's super easy to switch to it, and accidentally commit. And usually, I've observed that with most long running branches, there is always something that is in one those branches that isn't in the integration branch—in other words, diffing a "stable" branch with the main development pipeline shows differences on both sides, when technically, it should be so that only the development pipeline has "more", or is "ahead" of the stable branches. However, if you can keep up the discipline, then so be it.

Appreciate the thoughts @Stephan, and the shout out.

@Biswajit

@Junilu brings up some very valuable points—workflows vary because how teams communicate, integrate and test their work vary. Leaving aside the vagaries of each individual team, I'd say that multiple team members should never work on the same branch. The confusion starts because we think of master, main etc as "special integration" branches—but to me, ANY branch that "integrates" the work of multiple developers is an integration branch.

Suppose you and I are working on a big feature—we create a branch off master—call it feat-a You and I then create our own feature branches off feat-a—we work, we create PRs, and merge. Occasionally we merge (or rebase) the master branch into feat-a (our "integration" branch) so we don't fall too behind, and when we are done with our feat, we issue a PR from feat-a into master. Done.

At the end of the day, both need to check-in their respective codes and preferably do a sqaush commit in 'master branch'. We then cherrypick individual  squash commits for each feature into a shortlived release branch for a releases.
The problem we face is , when we have multiple MRs (from multiple feature branches ) for same feature, sometimes it gets complicated to do cherry-pick into release branch. It seems easier if all work on same feature branch and submit just one MR when the work is ready to be merged into the master branch.

I wrote a book on Git, and I am confused about your workflow . Not to get on a soapbox, but I really don't understand this fascination that developers have grown for squashing, and cherry-picking. To me, those are the two smells in any workflow. In my book, I mentioned cherry-picking—b/c I feel the minute developers find out about it, there we are—looking at cherry-picking as a viable alternative to a reasonable flow involving merging branches.

Your problem, at least from the way you describe it, does not arise from how you are integrating work into feature (or integration) branches. Your problem arises from your choosing cherry-picking as a way to merge code. Any change you make to a reasonable integration workflow will most likely fail b/c cherry-picking is, IMO, a hack, not a solution.

I have said this in this thread, and I have said it in other threads—the point of an integration branch is much more than "bring work together". Its a way to verify if the work that just came together works together (via testing). Its a way to produce an an artifact that goes from DEV to PROD.

And to further highlight how much I feel thinking through a good workflow is, I am going to quote myself from this thread

The thing to really understand is this—how you branch, integration, tag, and build code in Git affects your entire release engineering process. This is far too often overlooked in many teams. Get the Git workflow right and suddenly the release engineering process comes into sharp focus.

If I were you, I'd ask myself, and the team—what can we do to not using cherry-picking as a way to get code in the release branch? B/c in essence—that's your problem—multiple folks issuing multiple MRs against master, and you aren't sure if you are getting ALL the ones you really want to the release branch. Ergo, your question.

Hope this helps. Feel free to reach out if you have any other questions.

Update: Edited for formatting

Ah! Damn! @Liutauras posted their response, so feel free to ignore mine as well. Apologies to all!

Regards,