Viewing profile — gfairbanks

Abstract: Lehman’s Laws distinguish between stable S-type and volatile E-type code. Developers can decompose unique problems methodically by seeking standard sub-problems, which re…

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 program…

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…

> 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 experien…

> 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 …

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 excepti…

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 th…

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…

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…

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 thi…

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 worki…

In my own gut, I have a sense of the right amount of time to spend on design. Assume (falsely) for a moment that I'm right: How can I transfer that gut sense to you or anyone? Chap…

> throw imaginary problems in the mix Yes, this happens too easily. It's the crux of Ward Cunningham's original observation on tech debt discussed recently [1]. He basically said: …

How much architecture is enough? Chapter 3 Risk-Driven Model [1] guides you to do as little architecture as possible. It says: "The risk-driven model guides developers to apply a m…

Agreed. The architecture mismatch paper [1] identifies common assumptions that software can make, such as "I own the main thread of control and other modules will do my bidding", t…

Ward Cunningham's original idea of tech debt (see [1], a beauty of concision at just 300 words) is that iterative development distorts your code because you start writing code befo…

A quirk of IEEE's publishing system is that it drops the abstract, instead using the first paragraph. Here is the abstract [1]: The iterative process that a team follows is a bit l…

> if you attempted to automatically convert the model to code and back again, the output would mismatch. I like this way of expressing it. My book chapter is a much more long-winde…

Related treatment: ABSTRACT: The term technical debt was coined by Ward Cunningham in 1992. In recent years, people have broadened the definition to include ideas not present in th…