Hacker News Reader

Comment by bobleeswagger | Hacker News Reader

Well designed architecture will always be the guard against fragility. I do think there is a lack of architecture design and technical design discussions that contribute to the current state of software fragility. There's too many tools contributing to the noise, and not enough tools reducing that noise.

Software is hard because it is the last 10% ... Hardware was the first 90%, but anyone with project experience knows how long the last 10% lasts.

View on HN

This is somewhat of a tautology: if your architecture was good then it still is. But it is hard to define "good" or "well designed" or "better than that other one".

A slightly different take: there are a couple of categories for system changes: (a) adaptive changes to respond to a changing environment or requests for new functions, and (b) corrective changes which fix bugs (bugs of any age).

Examining a proposed architecture with these two categories in mind might help. As long as changes are correctly categorized and therefore the scope of changes matches, your architecture may be seen as better or worse. Or more or less survivable.

And on yet a completely different perspective: choose between two or three possible architectures. If you haven't got a choice then you need to fix that.

In software very long lived (I'm talking 20+ years) you don't have space for such questions; can something still be done to reduce fragility?

That may be true, but: many, myself included, live in a world where only so-so design is allowed, with many teams touching many products, often with different people, bad decisions, and pushing managers. Can something be done under this constraints to reduce fragility? I'm starting from a definition of it, maybe a description or measure

Reply on news.ycombinator.com