gfairbanks

9 ms·

1.
Stable Code from Stable Problems(ieeexplore.ieee.org)
2 points by gfairbanks 4mo ago|1 comments
2.
by gfairbanks 4mo ago
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 reduces complexity and boosts productivity. This illuminates
3.
by gfairbanks 1y 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 informa
4.
by gfairbanks 2y 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 bu
5.
by gfairbanks 2y 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 &quot
6.
by gfairbanks 2y 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
7.
by gfairbanks 2y 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
8.
by gfairbanks 2y 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 dif
9.
by gfairbanks 2y 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
10.
by gfairbanks 2y 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
11.
by gfairbanks 2y 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 bui
12.
by gfairbanks 2y 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 i
13.
by gfairbanks 2y ago
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? Chapter 3 of the book is my attempt to share that gut fe
14.
by gfairbanks 2y ago
> 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: all of you thinking you can use waterfall to
15.
by gfairbanks 2y ago
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 minimal set of architecture techniques to reduce their
16.
by gfairbanks 2y ago
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", that tend to be baked-in from the start. [1] Garla
17.
by gfairbanks 2y ago
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 before you know the requirements, but even so, it's be
18.
by gfairbanks 2y ago
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 like a garbage collection algorithm, and we can compare
19.
Garbage collect your technical debt (2021)(ieeexplore.ieee.org)
136 points by gfairbanks 2y ago|89 comments
20.
by gfairbanks 4y ago
> 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-winded. The chapter explains why the round-trip loses info,
21.
by gfairbanks 6y ago
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 the original formulation, including lack of skill, expedient h
22.
Testing Numbs Us to Our Loss of Intellectual Control(ieeexplore.ieee.org)
7 points by gfairbanks 6y ago|0 comments
23.
Better Code Reviews with Design by Contract(ieeexplore.ieee.org)
5 points by gfairbanks 7y ago|0 comments
24.
Ignore, Refactor, or Rewrite(ieeexplore.ieee.org)
1 points by gfairbanks 8y ago|0 comments
25.
by gfairbanks 8y ago
Hi Jacques, author here. I'm a big fan of testing so I'm disappointed if the article gave the opposite impression. You won't find me saying "of course I didn't test it; I proved it correct." I was trying to use
26.
Intellectual Control [pdf](ieeexplore.ieee.org)
29 points by gfairbanks 8y ago|3 comments