software architecture

Kimsia

Dan Hockenmaier on Substack

substack.com

Org debt is just as dangerous as tech debt but is talked about much less

Org debt builds up every time a company operates without discipline:

- Inconsistent principles for promotions and comp

- Hiring without a clear scope for the new role

- Trying new operating models but not sticking to them

- Allowing meeting creep

In the short term, it's always easier to just let this stuff happen. But in the long term, org debt will destroy a company. Execution will slow down, people will get frustrated, and the best ones will leave.

If you're considering joining a company, assess org discipline in the same way you'd assess their metrics and team.

Decisions at all stages of the life cycle—from architectural design to coding and implementation and testing—affect system quality. Therefore, quality is not completely a function of an architectural design. But that’s where it starts.

Paul Clements • Software Architecture in Practice, 4th Edition

A system’s ability to meet its desired (or required) quality attributes is substantially determined by its architecture. If you remember nothing else from this book, remember that.

Len Bass • Software Architecture in Practice, 4th Edition

Once an architecture has been defined, it can serve as the basis for incremental development. The first increment can be a skeletal system in which at least some of the infrastructure—how the elements initialize, communicate, share data, access resources, report errors, log activity, and so forth—is present, but much of the system’s application fun... See more

Paul Clements • Software Architecture in Practice, 4th Edition

enabling incremental development

Every architecture, no matter what it is, partitions possible changes into three categories: local, nonlocal, and architectural.

A local change can be accomplished by modifying a single element—for example, adding a new business rule to a pricing logic module.

A nonlocal change requires multiple element modifications but leaves the underlying archite

Paul Clements • Software Architecture in Practice, 4th Edition

Coding with AI takes (and enables) more discipline.

I need more tests, more checks and constraints. This takes more scaffolding, which is now fast to create.

More “how will I know this works?” and less “how will I implement this?”

I need to learn how to influence the AI, and channel frustration into guidance.

More high-level thinking about what the sof... See more

Jessitron • Augmented Coding: an Experience Report

Architecture represents a common abstraction of a system that most, if not all, of the system’s stakeholders can use as a basis for creating mutual understanding, negotiating, forming consensus, and communicating with each other. The architecture—or at least parts of it—are sufficiently abstract that most nontechnical people can understand it to th... See more

Paul Clements • Software Architecture in Practice, 4th Edition

helps with communiation among stakeholders

Software architecture is a manifestation of the earliest design decisions about a system, and these early bindings carry enormous weight with respect to the system’s remaining development, its deployment, and its maintenance life. It is also the earliest point at which these important design decisions affecting the system can be scrutinized.

Rick Kazman • Software Architecture in Practice, 4th Edition

architecture maniffests early design decisions

If your system requires high performance, then you need to pay attention to managing the time-based behavior of elements, their use of shared resources, and the frequency and volume of their interelement communication.

If modifiability is important, then you need to pay attention to assigning responsibilities to elements and limiting the interaction