Best Quotes from Righting Software by Juval Lowy with Page Numbers

For the beginner architect, there are many options. For the Master architect, there are but a few.

The essence of the architecture of any system is the breakdown of the concept of the system as a whole into its comprising components.

It is critical to get the architecture right. Once the system is built, if the architecture is defective, wrong, or just inadequate for your needs, it is extremely expensive to maintain or extend the system.

Good architectures allow use in different contexts.

Even communicating with yourself this way is very valuable as it helps to clarify your own thoughts.

Requirements should capture the required behavior rather than the required functionality.

A use case is an expression of required behavior, i.e., how the system is required to go about accomplishing some work and adding value to the business.

The more layers, the better the encapsulation.

Using services provides distinct advantages.

Scalability. Services can be instantiated in a variety of ways including per-call.

All Clients (be they end user applications or other systems) use the same entry points to the system.

The client layer also encapsulates the potential volatility in Clients.

Atomic business verbs are practically immutable because they relate strongly to the nature of the business which... hardly ever changes.

If two Managers or two Engines cannot use the same ResourceAccess service... you may not have encapsulated some access volatility.

A well-designed ResourceAccess component exposes in its contract the atomic business verbs around a resource.

The four questions loosely correspond to the layers because volatility trumps everything.

Once you complete your design, take a step back and examine the design.

The Manager services in the system execute some sequence of business activities.

When the ResourceAccess service changes, only the internals of the access component change, not the whole system atop.

The various Client applications will use different technologies, be deployed differently, have their own versions and life cycles.

Deviating from these observations may indicate a lingering functional decomposition or at least an unripe decomposition in which you have encapsulated few of the glaring volatilities but have missed others.

In a well-designed system, volatility should decrease top-down across the layers.

A design in which the volatility decreases down the layers is extremely valuable.

Reuse, unlike volatility, should increase going down the layers.

Almost-expendable Managers are a sign of a well-designed system.

Design Iteratively, Build Incrementally.

A well-designed Manager service should be almost expendable.

The ability to reuse existing Resources in a new design is often a key factor in business approval of a new system’s implementation.

If you have designed correctly for extensibility, you mostly leave existing things alone and extend the system as a whole.

The design of a Method-based system is geared toward extensibility: just add more of these slices or subsystems.

In general, in software engineering trading encapsulation for flexibility is a bad trade.

Closed architecture promotes decoupling by trading flexibility for encapsulation.

Most systems do not have the level of performance required to justify such designs.

Always opt for a closed architecture.

Any violation of these rules is a red flag and indicates what you are missing.

Relaxing the rules of closed architecture can reduce complexity without compromising encapsulation.

A strong indication that more Managers would need to respond is the need to have multiple Managers receiving a queued call.

The discovery of a transgression indicates some underlying need that made developers violate the guidelines.

Symmetry in software systems manifests in repeated call patterns across use cases.

Your software system’s reason for being is to service the business by addressing its customers’ requirements and needs.

As an architect you add value when you devise the correct design for the system at hand.

Design should not be time-consuming.

Every system is different, having its own constraints and requiring its own design considerations and tradeoffs.

Focus on the rationale for the design decisions.

This system aims to find the best rate for the tradesmen and the most availability for the contractors.

It is important that you do not use this example dogmatically as a template.

With practice and critical thinking, you can produce a valid design even with uncertainty.

The goal of this design chapter is to show the thought process and the deductions used to produce the design.

Users are required to employ up to five different applications to accomplish their tasks.

The company views itself as a tradesman broker, not as a software organization.

Serving the business is the guiding light for any design effort.

You must ensure that the architecture is aligned with the vision the business has for the future.

You must be able to easily point out how each objective is supported in some way by the architecture.

The integration of the components is what supports the required behaviors and realizes the business objectives.

Seldom will everyone in any environment share the same vision as to what the system should do.

The first order of business is to get all stakeholders to agree on a common vision.

Everything that you do later has to serve that vision and be justified by it.

The essence of the system is not to add a tradesman or contractor, but to match tradesmen to contractors and projects.

Recognizing the areas of volatility and encapsulating these areas in system components is crucial.

A good design effort transforms, clarifies, and consolidates the raw data presented by customers.

A good vision should be terse and explicit.

If something does not serve the vision, then it often has to do with politics and other secondary or tertiary concerns.

You must not allow the engineering or marketing people to own the conversation.

The architecture serves the business.

Identifying tradesman as an area of volatility signals decomposition along domain lines.

It is a lot easier to drive the correct architecture through the business by aligning the architecture with the business’ vision.

You should specify the mission statement (how you will do it).

Once you have them agree on the vision, the objectives, and then the mission statement, you have them on your side.

A project context may not be necessary; a MarketManager may be better.

Misunderstanding and confusion are endemic with software development and often lead to conflict or unmet expectations.

The system is a loose collection of services that post and receive messages to each other.

Extensibility is essential; you can extend the system by adding message processing services, avoiding modification of existing services.

The required behavior of the application is the aggregate of those transformations.

The objective of forward-looking design is to have nothing that ties the system to present requirements.

You should always build systems incrementally, not iteratively.

Adopting the TradeMe architecture today prepared the company for the future without compromising on the present.

A workflow Manager enables you to create, store, retrieve, and execute workflows.

Changing the program means changing the network of actors, not the actors themselves.

With the right safeguards, end users can edit the required behavior, drastically reducing the cycle time to delivering features.

It is a lot easier to morph the architecture than it is to bend the organization.

You must know before work commences whether the design can support the required behaviors.

If you cannot validate your architecture, or the validation is too ambiguous, you need to go back to the drawing board.

It is important to demonstrate that your design is valid, not just to yourself but also to others.

The architecture of TradeMe was modular and decoupled from all the use cases.

The execution of the use case requires interaction between a Client application and the membership subsystem.

Once the workflow has finished executing the request, the Membership Manager posts a message back into the Message Bus.

Clients can monitor the Message Bus too and update the users about their requests.

Verifying the tradesman or contractor is a key step in supporting the overall workflow.

The Match Tradesman core use case involves multiple areas of interest that are essential for a successful operation.

Understanding the relationship between the regulations and the market elements is crucial for effective system design.

The important thing to note is the composability of this design.

You have an open-ended design that can be extended to implement any of these future scenarios.

This is what the Message Is the Application design pattern is all about.

The logical 'assignment' message weaving its way between the services, triggering local behaviors as it goes.

The use case is independent of who triggered it.

A true composable design.

This is atestimony to the versatility of the design.

TradeMe for some business intelligence to answer questions like "could we have done things better?"

It allows for clear mapping to the design.

Each managing their respective subsystem.

"Combine system design and project design to drastically improve the likelihood of success for the project."

"You must design the project to build the system, accurately calculating planned durations and costs."

"Engineering is all about trade-offs and accommodating reality."

"Adding to the challenge of project design is that there is no single correct solution for the same set of constraints."

"Your task is to narrow the spectrum of near-countless possibilities to several good project design options."

"If you do not provide project design options, you will have no one to blame but yourself for conflicts with management."

"Project design allows you to shed light on dark corners, providing visibility on the true scope of the project."

"Once project design is in place, you eliminate the commonplace gambling with costs and wishful thinking about project success."

"A well-designed project lays the foundation for decision makers to evaluate and understand the effect of a change."

"Just as you would not assemble IKEA furniture without instructions, do not assume developers can build software without a project design."

"For a project to thrive, it must first meet its physical needs, much like a person needs air, food, and shelter."

"Once the physical needs are satisfied, ensuring safety through adequate funding and time is crucial for project success."

"Repeatability assures that if you plan and commit for a certain schedule and cost, you will deliver on those commitments."

"In a successful software project, the engineering efforts can only be focused on once the foundation of repeatability is secured."

"The technology serves the engineering needs, just as engineering seeks to provide safety in project design."

"An inverted pyramid of needs often leads to project failure, as teams focus excessively on technology while neglecting fundamental issues like time and cost."

"Investing in the safety level of the pyramid stabilizes the upper levels and drives the project to success."

"Project design must be prioritized as a foundational element in the hierarchy of needs for software projects."

"The primary purpose of the network diagram is communication; a model that no one understands defeats its very purpose."

"Floats are the project’s safety margins, allowing teams to compensate for unforeseen delays without derailing overall progress."

An activity’s total float is by how much time you can delay the completion of that activity without delaying the project as a whole.

Free float is by how much time you can delay the completion of that activity without disturbing any other activity in the project.

Capturing the information of the floats on the network diagram is not ideal; human beings process alpha-numeric data slowly.

The primary reason well-managed projects slip is because non-critical activities become critical.

The project manager should proactively track the total float of all non-critical activity chains.

The safest and most efficient way to assign resources to activities is based on float.

By addressing riskier activities first, you maximize the percent of time the resources are utilized.

When you trade resources for float, you reduce the cost and the float, but increase the risk.

Visualizing floats through color coding can greatly enhance the understanding of project risk areas.

Tracking total floats regularly allows project managers to see at what point activities become critical.

"Most people recognize the risk axis but tend to ignore its since they cannot measure or quantify it."

"Risk is the best criteria for choosing between options."

"Given a measurable identical loss or gain, most people disproportionally suffer more for the loss than they would enjoy the same gain."

"The only safe way of doing any project is not doing it."

"Risk values are always relative."

"A risk value of 0 does not mean that the project is risk-free. A risk value of 0 means that you have minimized the risk of the project."

"You should therefore talk about safer project rather than a safe project."

"The likelihood of something bad happening in a single day is open for debate, but it is a near certainty with 10 years."

"Design risk therefore quantifies the fragility of the project or the degree to which the project resembles a house of cards."

"To automate the algebra and avoid error-prone manual calculations."

"Anything worth doing requires risk."

"Risk should never be zero; it is the essence of all meaningful projects."

"Choosing weights wisely is essential for accurately assessing project risk."

"The Fibonacci series illustrates the beauty of inherent order amidst complexity."

"In the realm of software, the ability to compress a project can paradoxically increase execution risk."

"Decompressing a project by introducing float can significantly reduce its fragility."

"Effective project management involves recognizing the sensitivity of activities to risk and delay."

"Even the most sophisticated models require sensible judgment and adaptation to be truly effective."

"The true measure of success is not just in completing a project on time, but in managing its risks wisely."

"An understanding of criticality and activity risk can empower teams to navigate complex project landscapes effectively."

Excessive decompression will have diminishing returns when all activities have high float.

Decompression pushes the project a bit into the uneconomical zone, increasing the project’s time and cost.

Do not be tempted to consume the additional decompression float and reduce the staff because that defeats the purpose of risk decompression.

The steepest point of the risk curve is at minimum direct cost, which therefore coincides with the decompression target.

The ideal decompression target is a risk of 0.5 as it targets the tipping point in the risk curve.

Constantly measure the risk to see where you are and where you are heading.

Your project should never have extreme risk values. Obviously risk values of 0 or 1.0 are nonsensical.

Don't over decompress. Decompression beyond the decompression target has diminishing returns.

Treat god activities as mini projects and compress them.

A violation of the metrics is a red flag, and you should always investigate the cause.

"At 9.03 months, the risk is 0.81 and at 12.31 months, the risk is 0.28."

"Project design solutions left of the 9.03-month risk crossover point are too risky."

"In between the two risk crossover points, the risk is 'just right'.”

"The ideal risk curve and its first two derivatives provide a framework into which we can fit our practical design questions."

"The steepest point in the risk curve offers the best return; for the least amount of decompression, you get the most reduction in risk."

"This technique provides an objective and repeatable criterion, especially important when there is no immediately obvious visual risk tipping point."

"The geometric mean handles an uneven distribution of values better than the arithmetic mean, providing a more satisfactory result for risk calculations."

"Using the geometric mean calculation, extreme outliers have much less effect on the result."

"Solving the equation yields the acceptable range for t—an expression of managing risk intelligently in project design."

"Risk curves and their derivatives reveal the true dynamics of balancing efficiency with safety in project management."

Execution complexity refers to how convoluted and challenging the project network is.

The more internal dependencies the project has, the riskier and more challenging it is to execute.

Execution complexity is also positively correlated to the likelihood of failure.

The larger the project becomes, the more challenging the design and the more imperative it is to design the project.

Almost without exception, all megaprojects are also mega failures.

The larger the project, the larger the deviation from its commitments with higher costs relative to the initial budgets and schedule.

Understanding complexity is key to successfully navigating large projects.

The sharp rise in complexity corresponds to parallel work and compressing the project.

Design by layers and networks of networks can help manage execution complexity.

Projects are often created under the pressure of aggressive schedules, leading to both design and execution challenges.

"Complex software systems used to be limited to mission-critical systems like nuclear reactors where the underlying domain was inherently complex."

"In complex systems, there are nonlinear responses to minute changes in the conditions."

"The risk of failure will grow nonlinearly with the increase in complexity, akin to a power law function."

"Even if the parts are connected, the system will not be that complex to manage and control if the parts are clones or simple variations of one another."

"You must approach the project as a network of networks."

"The key to success in large projects is to negate the drivers of complexity by reducing the size of the project."

"The aggregate quality is only as strong as the weakest link in the chain of components."

"When a complex system depends on the completion of a series of tasks, any failure in those tasks can have severe side effects."

"Avoid rushing. This will be especially challenging since everyone else will be itching to start work, but crucial planning and structuring are necessary to prevent failure."

"Do not shy away from proposing the reorganization as part of your design recommendations at the SDP review."

"You must strive for a complete superiority over every aspect of the project."

"The best career advice I can give you is: Treat the company’s money as your own."

"With a large and expensive project, even a minute change from the optimal point could be both huge in absolute terms and likely to surpass the cost of designing the project."

"The real answer to the question of when to design a project is when you have integrity."

"When you are accountable for your actions and decisions, your worth in the eyes of top management will drastically increase."

"Most people avoid thinking for themselves because it is so much easier to dogmatically follow the common practices of a failing industry."

"Respect is always reciprocal."

"Think of project design as a sun dial, rather than a clock."

"The project design option you choose will always differ from reality, and the actual project execution will be similar, but not quite what you have designed."

"The most important thing that project design enables is making educated decisions about the project: whether to proceed at all, and, if so, under which option."

It is more important to be creative in coming up with project design ideas, to recognize constraints, and to work around pitfalls, than it is to get every estimation exactly right.

You should not apply the ideas in this book dogmatically. Instead, you should adapt the project design tools to your particular circumstances without compromising on the end result.

When possible, do not design a project in secret. Design artifacts and a visible design process build trust with the decision makers.

The essence of good management is choosing the right option.

Giving people options empowers them. After all, if there is truly no other option, then there is also no need for the manager.

Compression reveals the true nature and behavior of a project, and there is always something to gain by better understanding your own project.

Even if you suspect that an incoming request is unreasonable, saying ‘no’ is not conducive to your career. The only way to say ‘no’ is to get them to say ‘no’.

Ignorance of reality is not a sin, but malpractice is.

The psychological need for float is the peace of mind of all involved. In projects with enough float, people are relaxed; they can focus and deliver.

You need to design project design and even use the tools of project design in doing so.

The real problem is that detailed design in the front end simply takes too long.

Designing the services on-the-fly, in parallel to the developers who are constructing services the architect has already designed could work.

With a senior hand-off, the architect can hand-off the design soon after the SDP review.

The senior hand-off is the safest way of accelerating any project because it compresses the schedule while avoiding changes to the critical path.

You must know exactly how many services you can design in advance and how to synchronize the hand-offs with the construction.

Debriefing each project is important and provides a way to share lessons learned across projects.

Even when the project is a success, could you have done a better job?

Quality leads to productivity, and it is impossible to meet your schedule and budget commitments when the product is rife with defects.

Well-designed systems and projects are the only way to meet a deadline.

When people are less stressed, they pay attention to details, resulting in better quality.

Success is addictive, and once people are exposed to working correctly, they take pride in what they do and will never go back.

No one likes high-stress environments with low quality, tension, and accusations.

Quality is not free. However, it does tend to pay for itself because defects are horrendously expensive.

Delivering high quality software is a team sport.

If you do not have Standard Operating Procedures for all key activities, devote the time for research and writing SOPs.

By following best practices, you will prevent problems and defects.

The best way of turning micromanagement around is by infecting the team with a relentless obsession for quality.

Allowing and trusting people to control the quality of their work is the essence of empowerment.

Quality is the ultimate project management technique, requiring very little management while maximizing the team’s productivity.

You must have the flexibility to pivot quickly between several meticulously laid-out options.