Read software architecture for developers by SimonBrown Online


The agile and software craftsmanship movements are helping to push up the quality of the software systems that we build, which is excellent. Together they are helping us to write better software that better meets the needs of the business while carefully managing time and budgetary constraints. But there's still more we can do because even a small amount of software architThe agile and software craftsmanship movements are helping to push up the quality of the software systems that we build, which is excellent. Together they are helping us to write better software that better meets the needs of the business while carefully managing time and budgetary constraints. But there's still more we can do because even a small amount of software architecture can help prevent many of the problems that projects face. Successful software projects aren't just about good code and sometimes you need to step away from the IDE for a few moments to see the bigger picture.This book is about that bigger picture and its role in delivering better software. It's a collection of essays that together form a practical and pragmatic guide to software architecture, with the overall goal being to demystify what it means to be a software architect and provide guidance on how to do software architecture effectively.The book is aimed at software developers that want to learn more about software architecture as well as those that are new to the role. It fills the gap between software development and high-level architecture that probably seems a little "enterprisey" for most developers....

Title : software architecture for developers
Author :
Rating :
ISBN : 15734781
Format Type : ebook
Number of Pages : 206 Pages
Status : Available For Download
Last checked : 21 Minutes ago!

software architecture for developers Reviews

  • Sergey Shishkin
    2019-03-26 23:08

    Warning: this review is based on the pre-released leanpub version of the book with some chapters still missing. I'll check out the released version and update my review when it's ready.I'd rather gave the book 5 stars as its subject is indeed relevant and its ideas appeal very much to my agile and lean taste. This book will definitely help you approach software architecture in a lightweight manner avoiding rework in the near future, analysis paralysis and big design upfront. I highly recommend it to anyone working in software development.I gave the book only 3 stars though because I didn't like 2 major points about the way those ideas are delivered.First, the book is a series of essays. Though they are logically ordered, I missed the storyline throughout the book. I know it's a non-fiction, but the book in my opinion is too much about making the case for the method it presents, rather than actually describing and guiding the reader through the method. Essays also contain a lot of repetition, I've encountered some passages like three or four times in the book.Second, I didn't like how the book tries to position itself against Agile. Though the book actually promotes quick feedback loops, iterative and incremental delivery, it in my opinion misrepresents agile as lacking any design activities. I think how the work stream is managed and what activities it contains is completely orthogonal. That's why the book would appeal much better to me if it focused itself on integrating architecture activities in management practices rather fighting them (it equally fights waterfall to be fair).

  • Karl Metivier
    2019-03-31 01:09

    This is a great book about software architecture and how to share its structure and vision. The author, Simon Brown, shown us his pragmatic side in this overview of what is software architecture. I did particularly enjoy the parts about the role and how to design and communicate software. Must read for any developer or software architect!

  • Johnny Graber
    2019-04-10 04:38

    Simon Brown shows in his book “Software Architecture for Developers” how many so-called “agile projects” work: Ignore all documentation, architecture and just write code. If you ever worked in a project where the person in the role of a software architect abused this role to hide his incompetence you can sympathise with the just code approach.However, if you need to build something that can’t be done in a few weeks you need to care for the overall structure. If you do this as a team effort or with a dedicated role for architecture may vary by project. For both ways you find guidance in this book.As Simon Brown explains this doesn’t mean you need to go back to big upfront planning. Architecture and agile projects are not a contradiction and can work together. The big picture is relevant and with timely feedback architectural decisions can be validated as you (hopefully) do it with business requirements on a daily basis.With so many examples from the real world and fitting solutions to the discovered problems I can highly recommend you to read this book.

  • Renan Ivo
    2019-04-06 01:24

    This books takes more effort into explaining why software architecture is important and how you can have "just enough" upfront design and be agile. I was looking for "hands on" architecture practices, which seems to be left for the second volume.

  • Vít Kotačka
    2019-04-24 00:36

    A pretty decent book about the Software Architecture, promoting the concept of the coding architect. The pros of this book are that in one place it gathers strong arguments why SW architecture matters and how to promote these ideas.I would recommend this book either to some aspirant to the architect role, or even to any senior developer who cares about the context of his project, solution and technology. On the other hand, any architect practitioner, who has a few years of experience with the subject, probably won't find many new ideas here.That's also my story - I can't agree more with what is said in the book, but I had found almost everything intuitively by myself before. Therefore, I'm rather looking forward to the next volumeVisualise, document and explore your software architecture, which looks more promising.One negative point, I'm going to mention: it's clear that there was no editor/corrector. In too many places the author just copy-pasted some paragraphs. It's too frequent and it's annoying.

  • Luboš
    2019-04-25 04:22

    A great introduction to the topic: coding architect. Extra points for being short.This book is a practical, pragmatic and lightweight guide to software architecture, specifically aimed at developers, and focussed around the software architecture role and process.

  • Nicolas
    2019-04-15 04:16

    Really interesting for architects and developers.

  • Mike Gunderloy
    2019-04-06 04:33

    A developer-centric view of architecture that spends quite a bit of space exploring the tension between agile and BDUF approaches. Personally I'm a fan of more up-front design than many agile teams, which may just mean I'm getting old. In the end I appreciated the multiple perspectives on the multi-faceted architect's role here. Maybe I still have enough career time left to be an architect when I grow up.

  • Zbyszek Sokolowski
    2019-04-10 23:33

    I liked the book and it is usefull but overall I thought that it would be better. A lot of complaints, most of them are accurate but still. Simon tries to explain why software architecture is important, and how software book which describes a project and its evolution should be prepared in structural way. He describes also his C4 model. some quotes:But, generally speaking, a software architect who codes is a more effective and happier architect. You shouldn’t necessarily rule out coding just because “you’re an architect”.After telling me that he had little or no involvement in the project after he handed over the “solution”, I asked him how he knew that his software architecture would work. Puzzled by this question, he eventually made the statement that this was “an implementation detail”. He confidently viewed his software architecture as correct and it was the development team’s problem if they couldn’t get it to work. In my view, this was an outrageous thing to say and it made him look like an ass during the interview. His approach was also AaaS … “Architecture as a Service”!Despite people’s aspirations to be agile, collective code ownership and a distribution of the architecture role are likely to hinder chaotic teams rather than help them.Software architecture is about the significant design decisions, where significance is measured by cost of change. A high-level understanding of the requirements, constraints and principles is a starting point for those significant decisions that will ultimately shape the resulting software architecture. Understanding them early will help to avoid costly rework in the future.If you don’t understand the trade-offs that you’re making by choosing technology X over Y, you shouldn’t be making those decisions. It’s crucial that the people designing software systems understand technology. This is why software architects should be master builders.Having run architecture katas with thousands of people over a number of years, I can say with complete confidence that visualising the architecture of a software system is a skill that very few people have. People can draw diagrams, but those diagrams often leave much to the imagination.Abandoning UML is all very well but, in the race for agility, many software development teams have lost the ability to communicate visually.Agility requires good communication Why is this important? In today’s world of agile delivery and lean startups, many software teams have lost the ability to communicate what it is they are building and it’s no surprise that these same teams often seem to lack technical leadership, direction and consistency.A better approach is to create a number of diagrams at varying levels of abstraction. A number of simpler diagrams can describe software in a much more effective way than a single complex diagram that tries to describe everything.How the software system fits into the existing system landscape. Why the technologies in use were chosen. The overall structure of the software system. Where the various components are deployed at runtime and how they communicate. How the web-tier “knows” where to find the middle-tier. What approach to logging/configuration/error handling/etc has been adopted and whether it is consistent across the codebase. Whether any common patterns and principles are in use across the codebase. How and where to add new functionality. How security has been implemented across the stack. How scalability is achieved. How the interfaces with other systems work. etc“Working software over comprehensive documentation” is what the Manifesto for Agile Software Development says and it’s incredible to see how many software teams have interpreted those five words as “don’t write any documentation”.The agile manifesto values “responding to change” over “following a plan”, but of course this doesn’t mean you shouldn’t do any planning and it seems that some agile teams are afraid of doing any “analysis” at all. The result is that in trying to avoid big up front design, agile teams often do not design up front and instead use terms like “emergent design” or “evolutionary architecture” to justify their approach.These conflicts, in many cases, lead to chaotic teams that lack an appropriate amount of technical leadership. The result? Software systems that look like big balls of mud and/or don’t satisfy key architectural drivers such as non-functional requirements.Architecture is about the stuff that’s hard or costly to change. It’s about the big or “significant” decisions, the sort of decisions that you can’t easily refactor in an afternoon. This includes, for example, the core technology choices, the overall high-level structure (the big picture) and an understanding of how you’re going to solve any complex/risky/significant problems. Software architecture is important.Agile and architecture aren’t in conflict. Rather than blindly following what others say, software teams need to cut through the hype and understand the technical leadership style and quantity of up front design that they need given their own unique context.Based upon my definition of architecture, you could say that you need to do just enough up front design to give you structure and vision.

  • Vadim
    2019-04-02 02:32

    Too much water - this book could be 2 times shorter with the same amount of useful information. But it is useful nevertheless.

  • Enrique
    2019-04-07 03:28

    A pragmatic approach to software architecture

  • Abdurrahman
    2019-04-27 02:28

    I read this book after it was highly recommended by a senior architect at my company. After reading it, I have some mixed feelings about it!The best part of the book by far is the C4 section. As a developer, I have always struggled with visualizing the architectures systems that I work on, which I tried to do when introducing the system to new members, for instance. The "aha" moment came when realizing that trying to put all the information in one diagram does not make sense! The 4 diagrams that the author introduces felt very natural, and I was able to use them later when visualizing an entire system, or only the designs of new components/modules.As for the other chapters that define architecture and the role of an architect: I found them to be valuable as well. However, it is very obvious when you read them that they are based on a series of articles. The chapters are also full of repetitions. Some ideas - even some paragraphs - have been repeated more than 2-3 times! These ideas are indeed important, but the repetition does not add any value.One final note if you have not read the book yet: this book is not about architectural patterns. You will not find here ideas or patterns in software architecture, but rather a higher level discussion of the role of an architect and what software architecture is all about.Overall, I would still recommend at least skimming this book for any person working in software development and to focus on the C4 chapters

  • Romans Karpelcevs
    2019-04-09 00:24

    The book seems to me like a collection of university essays on different topics related to software architecture. In most cases, it simply conveyed the parts of the role and is a guidebook if you ever find yourself an architect. I didn't find it inspiring, and I'm certainly not going to come back to it in moments of hard architecture decisions, and felt quite unlike Simon's speeches or his general vibe of inspiration.Good parts: * Structured breakdown of the role * Lists of things to consider when starting or consulting a large project * Tips on visualising architecture * Great source if you're writing your thesisNot so good parts: * No drive, inspiration or attention-grasping, all quite dry * Lots of watery chapters which don't really say anything* Not much to help you become a better architect

  • Peter Sellars
    2019-03-27 00:32

    The best concept in this book is what Simon refers to as the 'C4' model - Context, Container, Component, Classes. Using these alone provides architectural value to projects. I tend to agree with Simon that not enough developers value or understand the role of an architect. The 'coding' architect he talks of feels like a rarity - but those I know are like this are far more valued. Simon also provides a good outline for how to lightly document software. My main disappointment was the constant references to Agile 'evangelists' in a somewhat derogatory undertones towards the end of the book. I took a lot from this book and would recommend teams get to grips with the C4 model at least and consider many of Simon's documentation ideas.

  • Andy
    2019-04-20 22:16

    This book provides some really good things to use if you are responsible/concerned about the architecture of a software system. I will definitely consult it when starting the next project (as well as throughout the project as the architecture evolves). If there is one main point I took away from this book is that it is important to get various members involved in architectural decisions. This helps team members have a better sense of ownership for it as well as making better decisions by simply being aware of the architectural vision.

  • Irwan
    2019-03-31 21:34

    This book contains useful tips, some insightful views that challenge my own, and it unveils what it means/takes to be an architect for use developers. I will certainly reread this book in the future.Too bad, I still has not heard that Goodreads has a re-read feature. Locked in its architecture?? :-)

  • سامح السيد
    2019-04-02 02:13

    I read the pre-released leanpub version of the book (it's about 93 pages only)It is a very nice book, I liked the C4 section (although needs more detail), the front end design discussion, and product guidebook for documentation, these are very good topics.I am looking forward for reading the final book

  • Bugzmanov
    2019-04-07 21:14

    I have mixed feelings concerning this one. I'm a big fan of Simon Browns blog and public speakings. And expected the book to be more than composed and slightly modified blog posts. Unfortunately that's the case. But I liked chapters concerning documenting an architecture and last part of the book covering how much architecture is enough was inspiring.

  • Ben
    2019-04-05 04:08

    it's a good introduction to the concepts and views of a solution architect.I felt there could have been more insight and examples to help clarify the book but maybe it's because its a collection of essays rather than a book. it's a short concise book which left me wanting more

  • Douglas
    2019-04-26 23:13

    A nice gentle introduction that makes a lot of sense in the Agile age. Resonates well with my own experience. I particularly like the emphasis on lean requirements, lean "noUML" diagrams and non-functional requirements, which are usually ignored until it's too late.

  • Isaac Asensio
    2019-04-13 03:28

    Good book about why we should have/follow an architecture on Agile Projects.

  • Marco Nieri
    2019-04-07 21:22

    Very pragmatic, full of insights. It goes straight to the point.

  • Mani Sarkar
    2019-04-02 02:15

    Highly recommended, need to read and practise it to internalise the concepts, Simon is a great author.

  • Ahmed Chicktay
    2019-04-12 05:37

    A great introduction to software architecture and the activities that a software architect is required to do.