gfairbanks (u/gfairbanks)

gfairbanks commented on Use Your Type System dzombak.com/blog/2025/07/... · Posted by u/ingve

jjice · 8 months ago

Does anyone know the term for this? I had "Type Driven Development" in my head, but I don't know if that's a broadly used term for this.

It's a step past normal "strong typing", but I've loved this concept for a while and I'd love to have a name to refer to it by so I can help refer others to it.

gfairbanks · 8 months ago

The overall idea of using your type system to enforce invariants is called typeful programming [1]. The first few sentences of that paper are:

"There exists an identifiable programming style based on the widespread use of type information handled through mechanical typechecking techniques. This typeful programming style is in a sense independent of the language it is embedded in; it adapts equally well to functional, imperative, object-oriented, and algebraic programming, and it is not incompatible with relational and concurrent programming."

[1] Luca Cardelli, Typeful Programming, 1991. http://www.lucacardelli.name/Papers/TypefulProg.pdf

[2] https://news.ycombinator.com/item?id=18872535

gfairbanks commented on Just Enough Software Architecture (2010) georgefairbanks.com/book/... · Posted by u/teleforce

chanux · 2 years ago

Good read. Thanks for sharing.

I feel that this article goes really well with it.

https://johnwhiles.com/posts/programming-as-theory

gfairbanks · 2 years ago

Some folks read Peter Naur's Programming as Theory Building [1] and become zealots. I'm that kind of person. His ideas are woven through my recent talks [2]. Via years of essays, I've been building to a vision of how to build software that I'm calling Continuous Design that's partly stitched together in this overview [3].

[1] Gwern on Peter Naur's Programming as Theory Building, which includes Naur's essay and related comments. https://gwern.net/doc/philosophy/epistemology/index#naur-198...

[2] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...

[3] Continuous Design, https://www.georgefairbanks.com/ieee-continuous-design/

gfairbanks commented on Just Enough Software Architecture (2010) georgefairbanks.com/book/... · Posted by u/teleforce

matt_lo · 2 years ago

Great book. I think it’s more ideal for folks who solution design day-to-day. Better when you have experiences to relate back with.

gfairbanks · 2 years ago

> Better when you have experiences to relate back with.

100% this. I've been teaching software design since the 1990's and it's so much easier when the audience has enough experience that I can wave my hands and say "you know when things go like this ... ?" and they do, and then we can get on with how to think about it and do better.

Without that, it's tedious. Folks with less experience have the brainpower to understand but not the context. I try to create the context with a synthetic example, but (again, waving hands...) you know how much richness your current system has compared to any example I can put on a page or a slide.

gfairbanks commented on Just Enough Software Architecture (2010) georgefairbanks.com/book/... · Posted by u/teleforce

dgb23 · 2 years ago

We have or rather could have data and metrics. We just tend to ignore them outside of specific domains.

For example, from glancing at this summary and table of contents, it seems like there’s no to little mention of performance metrics. What is architecture good for if it doesn’t account for what the computer actually does?

Even in terms of development productivity or UI: why don’t we have mathematical models to decribe the mental stack one needs to develop, change, extend and more importantly use software?

Why are compute resources (human or machine) rarely a consideration when they have a real, measurable impact on interacting with software as developers or users?

gfairbanks · 2 years ago

> it seems like there’s no to little mention of performance metrics.

The book uses the jargon from the architecture community. Chapter 12 section 11 on Quality Attribute Scenarios is what you're looking for. But [1] seems to be a summary of Michael Keeling's treatment on qualities and scenarios, which I like better.

My thinking on this has been greatly influenced by Titus Winters who I've been teaching with in Google for the past couple years. He's tied together the ideas of quality attribute scenarios, compile-time tests, monitored metrics, and alerts in a way that is, in hindsight, completely obvious but I've not seen elsewhere. Maybe we can get him to write that up as an essay.

[1] https://dev.to/frosnerd/quality-attributes-in-software-1ha9

[2] Titus Winters, Design is Testability, May 8 2024. https://on.acm.org/t/design-is-testability/3038 (note: video doesn't seem to be posted yet)

gfairbanks commented on Just Enough Software Architecture (2010) georgefairbanks.com/book/... · Posted by u/teleforce

b1ld5ch1rm5por7 · 2 years ago

Within my prior company they circulated this "Software Architecture for Developers" book by Simon Brown: https://leanpub.com/b/software-architecture.

It's still on my reading list, though. I've moved on from that company. But it came highly recommended, because they also documented their architecture with the C4 model.

Has anyone here read it?

gfairbanks · 2 years ago

Simon Brown is another person who has done a far better job than me of "democratizing" software architecture for developers. His talks [1] and workshops on architecture are exceptionally effective and his C4 architecture modeling language [2] is getting real traction.

I have youtube videos too [3] but they aren't as effective.

[1] https://www.youtube.com/results?search_query=simon+brown+arc...

[2] https://c4model.com/

[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...

gfairbanks commented on Just Enough Software Architecture (2010) georgefairbanks.com/book/... · Posted by u/teleforce

pbnjay · 2 years ago

Published in 2010? Curious how much of it has survived since then?

I like “Design It” because of some of the workshop/activities that are nice for technical folks who need to interact with stakeholders/clients (I’m in a consulting role so this is more relevant). Also it doesn’t lean hard on specific technical architectural styles which change so frequently…

gfairbanks · 2 years ago

Keeling's Design It book is great [1]. It helps teams engage with architecture ideas with concrete activities that end up illuminating what's important. My book tries to address those big ideas head-on, which turns out to be difficult, pedagogically, because it's such an abstract topic.

Which ideas have survived since 2010?

Some operating systems are microkernels, others are monolithic. Some databases are relational, others are document-centric. Some applications are client-server, others are peer-to-peer. These distinctions are probably eternal and if you come back in 100 years you may find systems with those designs even though Windows, Oracle, and Salesforce are long-gone examples. And we'll still be talking about qualities like modifiability and latency.

The field of software architecture is about identifying these eternal abstractions. See [2] for a compact description.

"ABSTRACT: Software architecture is a set of abstractions that helps you reason about the software you plan to build, or have already built. Our field has had small abstractions for a long time now, but it has taken decades to accumulate larger abstractions, including quality attributes, information hiding, components and connectors, multiple views, and architectural styles. When we design systems, we weave these abstractions together, preserving a chain of intentionality, so that the systems we design do what we want. Twenty years ago, in this magazine, Martin Fowler published the influential essay “Who Needs an Architect?” It’s time for developers to take another look at software architecture and see it as a set of abstractions that helps them reason about software."

[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/

[2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...

gfairbanks commented on Just Enough Software Architecture (2010) georgefairbanks.com/book/... · Posted by u/teleforce

banish-m4 · 2 years ago

Big grand architecture invariably leads to an elitism culture where there are overpaid technical architects who don't do much but insist on terrible patterns for software engineers to solve under unreasonable constraints including deadlines.

gfairbanks · 2 years ago

One of my main goals with the book was to "democratize" architecture, to make it accessible and relevant to every developer. As the cover blurb says:

"It democratizes architecture. You may have software architects at your organization — indeed, you may be one of them. Every architect I have met wishes that all developers understood architecture. They complain that developers do not understand why constraints exist and how seemingly small changes can affect a system’s properties. This book seeks to make architecture relevant to all software developers, not just architects."

In hindsight, my book hasn't been very good at that but perhaps it was a stepping stone on the path. Michael Keeling's book Design It: From Programmer to Software Architect does a better job of saying how developers can engage with architecture ideas. I'm a personal friend of his and a huge fan of his work. His experience report [2] on how to democratize architecture is what I aspire to do.

[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/

[2] Keeling and Runde, Agile2018 Conference. Share the Load: Distribute Design Authority with Architecture Decision Records. https://web.archive.org/web/20210513150449/https://www.agile...

gfairbanks commented on Just Enough Software Architecture (2010) georgefairbanks.com/book/... · Posted by u/teleforce

banish-m4 · 2 years ago

The category is nonfunctional requirements.

gfairbanks · 2 years ago

It's often taught as "nonfunctional requirements" or NFRs. The architecture community says "quality attributes". Why?

1) Not all qualities are requirements. Requirements tend to be pass/fail, either you meet them or you don't. Latency is a quality and typically lower is better, not pass/fail (though sometimes it is).

2) "Nonfunctional" in other contexts means broken. If you saw a machine with a sign on it saying "nonfunctional" what would you conclude?

At one point I tried to find the origin of the term "quality attributes". It's way older than the software community. I found it being used in the 1960's by the US National Academy of Sciences. If anyone knows the origin I'm interested in learning more.

gfairbanks commented on Just Enough Software Architecture (2010) georgefairbanks.com/book/... · Posted by u/teleforce

CraigJPerry · 2 years ago

The goal of software architecture is

>> cost reduction

> fulfil the quality goals

I’d word it as “keeping the cost of changing software low over the long term”.

I don’t think you can reduce that to a quality goal of “modifiability” because it’s not negotiable like other quality goals.

I don’t think you can say it’s just cost reduction, but that is closer.

It’s an existential thing. Architecture is about retaining the ability to change your software (avoiding the big ball of mud). If you lose the ability to change within time and resource constraints then the project, product or startup is dead.

gfairbanks · 2 years ago

For typical web / IT systems I largely agree with focusing on modifiability as a heuristic because on those kinds of systems it's typically the biggest risk.

But, have you seen this kind of mistake / failure? A system is built so flexibly that it can handle all kinds of future needs, but it's slow. Maybe it's a shopping cart that takes 5 seconds to update. So start with modifiability as the primary heuristic but keep an eye out for other failure risks.

Meta-commentary:

This is an example of why it's so hard to discuss architecture. My book talks about "failure risks", which is pretty abstract or generic. There's no easy heuristic for avoiding "failure risks" like there is for web / IT systems.

Software architecture is a discipline that's bigger than just web / IT systems. Some systems must respond with X milliseconds, otherwise the result is useless, so the architecture should make that possible -- and preferably make it easy.

gfairbanks commented on Just Enough Software Architecture (2010) georgefairbanks.com/book/... · Posted by u/teleforce

jefffoster · 2 years ago

Not just cost reduction but allowing more investment. A good architecture can enable more people to work on your product.

gfairbanks · 2 years ago

Agreed. See: Scale Your Team Horizontally [1].

"I’m not ready to argue against Brooks’ Law that adding people to a late project makes it later. But today, when developers are working on a clean codebase, I see lots of work happening in parallel with tool support to facilitate coordination. When things are going smoothly, it’s because the architecture is largely set, the design patterns provide guidance for most issues that arise, and the code itself (with README files alongside) allow developers to answer their own questions."

[1] Scale Your Team Horizontally, George Fairbanks, IEEE Software July 2019. https://www.georgefairbanks.com/ieee-software-v36-n4-july-20...