I feel like I had misaligned expectations of this book, but I'm not sure if it's because I didn't know enough about the to**spoiler alert** Review
I feel like I had misaligned expectations of this book, but I'm not sure if it's because I didn't know enough about the topic to understand what to expect or I just went to the theater to watch a thriller but got a romantic comedy instead, where the title and movie trailer guided me to make the wrong assumptions. In any case, this review might feel harsher than it actually is since there were parts I did actually enjoyed. Following are the bad parts, for the ones I found good are in the notes section.
Too much detail on high level concepts like port and connectors types between components.
Some diagrams feel too technical and unnecessarily detailed, like several relationship types between components, i.e. if two components are connected, I'm not sure it makes sense in many occasions to highlight the fact that the connection is sync or async, directly to the local file system or to a remote location, client or server port; by having a different dotted line to represent each one.
Most of the book feels somewhat academic and not matching the type of language you'd typically encounter in meeting rooms at work.
Very brief focus on the code model, not meaning I would've liked to see actual code, but, for instance, more concrete examples of how to apply the different strategies of dominant decomposition (folder structure). Same goes for the architectural styles.
The same concepts are repeated over and over again on most chapters from slightly different perspectives: quality attributes, module viewtype, runtime viewtype, components, ports, connectors. It feels like every chapter has a piece of the puzzle of each topic, rather than being covered in full in a continuous segment. Which innevitably leads to repetition.
Notes
Legend, vignette levels:
- 1st * 2nd ^ 3rd
2)
- Risk-driven: design as much architecture to mitigate the biggest risks. * If you need to process data in under 50ms, add that into the architecture. - Apart from the features you're working on, always know what risk failures are you solving. - There are problems to find and problems to prove. * "Is there a number that when squared equals 4?", is a problem to find since you can test a solution pretty easy. * "Is the sequence of all prime numbers infinite?", is a problem to prove. * Finding is easier than proving since you need to demonstrate something is true for all posible cases.
4)
- Design intent will always be lost between design and code. * We debated design decisions, discovered tradeoffs, imposed constraints; yet none of these is expressed in code. - Code makes a good job communicating the code model, poor job communicating the runtime and allocation models (where and how is it deployed). * Runtime model: what components and connectors exist at runtime. ^ How to represent it: Components and Responsibilities table, component assembly diagram, functionality scenario. - Functionality scenario includes: Name, Initial state, Participants (components), Steps. - Quality Attributes: describe here the tradeoffs, architecture drivers and design decisions. - When integrating third-party components, make a list of failure risks. * Make a diagram and write a functionality scenario of the risks mitigation strategies. - After laying out a domain model, test it with a concrete example to detect potential problems. * i.e. if you write a relationships model for Artist -> Song -> Album, the generic model might not highlight the potential shortcoming of handling bands or ex-band members going solo or artists changing names. - Make rational architecture choices: when 2 ideas seem as good, figure out which quality attribute they help achieve, e.g. usability and testability, then pick the one you value higher.
7)
- Models help you solve problems and mitigate risks, but some problems are better solved directly, not through models. - Every project should document its architecture: false. * You should plan before going on a road trip, but you don't plan your commute every morning. - "Your point of view is worth 80 IQ points", Alan Kay. - Domain model: expresses enduring truths about the world relevant to the system, if something is 'just true', belongs in the domain. - Design model: the system to be built makes appearance here, set of boundaries and commitments.
8)
- Domain models express details of the domain not related to the system's implementation. - Stop domain modelling when it provides less value than other activity, such as prototyping. - The most valuable part of this model is a list of types and definitions. - Invariants: things in the model that must always be true. - Functionality scenarios here include actors (real people or real world objects) not computer records or hardware as in the design model versions.
9)
- Module viewtype: things that exist only at compile time. * Modules, layers, dependencies, db schemas, interfaces, classes, component types. * Source code itself (code model) is this viewtype. - Runtime viewtype: object and component instances, functionality scenarios, component assemblies. * Hard to envision by reading the source code since you have to mentally animate the runtime instances.
11)
- Create levels of abstraction by hierarchically nesting elements, limit the number at any level, maintain encapsulation by not revealing unnecessary detail. * Create a story at many levels. - Dominant decomposition: the problem is that a single organisation system must be chosen. * Like books in a library organised by size, helps finding the largest books, not so much finding by author. * Decomposing the system into modules and components imposes an organisation on it. - Encapsulation: rather than just grouping together related code, hide details likely to change inside the module. * If you're unsure about design alternatives A and B, have the module's public interface support both, in case you need to swap.
14)
- Pipe-and-filter style: continually and incrementally processing data, (e.g. Node). - Batch-sequential: complete all processing before moving to the next state. - Client-server: is asymmetric, only clients can request the server to do work. - Peer-to-peer: any node can be client or server, no hierarchy....more
Concise and easy to read book on how to tackle the complexity of building working software into a simple process.
Notes**spoiler alert** Review
Concise and easy to read book on how to tackle the complexity of building working software into a simple process.
Notes
- We can build a walking path among the lava floor of software development, in order to keep focused, simplify the intention even if the implementation is complex and be able to get back to a known state if we ever get lost. - Sometimes delivering something small makes sense, and then pivoting if it didn’t deliver value or iterating if it did. - We must see and understand all the pieces in order to not deliver non-value features and delivering the ones we should. - Feature value is the height and cost if the width, we strive for the right ratio. - Don’t always discard a high cost feature for several low cost ones, sometimes a 5 carat diamonds is not worth the same as five one carat ones. - Value is the main goal, if switching products is more valuable than continue adding to the existing, assess how a product switch impacts the people involved, or if we can add to a portfolio instead of a complete new product.
�
- Handoffs require scheduling and cause delays. - “Plans are useless, but planning is indispensable�. - A too detailed plan wastes time and create confusion, still, planning is important. - Software people are bad at estimating cause humans are bad at estimating. - Time and budget for the first features cause we often deliver the bulk of the work (which is the most important part) ahead of schedule. - Yesterday’s weather: when planning, expect to do In the next iteration as much as your did in the last one (Martin Fowler and Kent Beck). - The goal is not to get good estimates but to do good work at a consistent pace. - Break down stories as small as possible, even down to a single test, then, estimating can be a matter of looking at things done. - Planning with “stretch goals� is destructive, cause the team will unconsciously hurry up and try to squeeze in that extra feature by half-baking the previous one, it’s devastatingly destructive. - Maybe instead of trying to estimate better, try to get better at breaking down stories into smaller ones. - Estimation tends to focus on cost, not value.
�
- There's a difference between apparent progress and real progress, features are done when they're really done, not cause some report apparently shows progress. - Eliminate test-fix finish: the end of each feature cannot be a case of testing and fixing bug after bug until we get it right, features must be nearly bug free. - A good design foundation means less defects, techniques to improve the design are easy to learn, also easy to forget as we move along. - Build foundation and features in parallel. - Building a complete design first reduces the shippable features by the deadline, we don't know how fast we'll move, reduces management guidance ability since you cannot guide until you've working features. - Building each feature to its full design first also means fewer deliveries. - Strive for MVF (minimum viable features) and refine in multiple iterations. - Small, incremental and refining iterations mean we're always making the product a bit better and always have the best possible product at any given time, so if we wanted, could even go to market before due date.
�
- We cannot work effectively in a world of defects, they reduce the line of apparent progress. - Takes longer to find a problem and fix it than to prevent it, it's why TDD is so effective. - Testing and refactoring (improving the design) work together to deliver features. - Value is what you want. - More often than not, what you value is not measurable, if it is, and you don't agree with the numbers, throw out the numbers and prioritise features you feel create more value. - For almost every product, we don't really know the numbers beforehand.
�
- Our job isn't to follow a plan but to steer the course for the best result. - Autonomous teams that manage themselves, priorities being set by Product Owners, team and stakeholder; doesn't mean that managers will go out of a job, means more work for them cause they can create other teams. - Management still handles staffing, budget decisions, vision. Kind of like a coach on a sports team. * Providing general organisation, allocating people and money to work, selecting the PO and possibly some team members. * Ideally, the PO selects the core team members, and the whole team selects the rest. - Hiring decisions come from management, suggestions and who to hire come from the team. - Rather than asking teams to increase velocity, check what's slowing the team down and could be improved. - We usually stop refactoring when there's too much pressure.
�
- If we have one team delivering features at Agile speed, often times we don't need to scale Agile into more teams since customers may not be able to concurrently absorb more features than that. - Agile teams communicate by writing automated tests, it helps preventing getting in each other's way. - Try to divide large efforts into feature teams....more
Rather than a technical discussion on how to build your tests, the main topic is about how to create your user stories, structure specification througRather than a technical discussion on how to build your tests, the main topic is about how to create your user stories, structure specification through acceptance criteria and leverage team collaboration in order to better test a complete system.
Tips are based on real world experiences from the authors, which is good.
Authors advocate that tests should focus on value added rather than functional correctness.
It's a quick read and description images make it fun.
My problems with it are that it feels bloated and the title misleading, it seems like a book written for training your manual QA team on how to test-run a system. From my experience, a dedicated manual QA team in Agile can create problems like a disconnect from development and testing when collaboration is not great between both teams, information loosing due to handoffs, or lack of automated testing from development due to developers delegating all testing tasks to manual testers. There doesn't seem to be ideas around how to mitigate these type of issues in the book....more
Great book, some of the concepts feel dated but even though, most of the books topics can still be applied to today's software development projects, lGreat book, some of the concepts feel dated but even though, most of the books topics can still be applied to today's software development projects, like adding personnel to an already late project won't speed it up and can actually make it later and the main take away in my opinion: men and months are not interchangeable when it comes to any type of work where communication is key....more
Loading...
