28 Aug 2022 06:57 - 28 Aug 2022 08:50
Open in Logseq
    • Habitability is the characteristic of source code that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently.
    • Habitability makes a place livable, like home. And this is what we want in software—that developers feel at home, can place their hands on any item without having to think deeply about where it is. It’s something like clarity, but clarity is too hard to come by.
    • Huh, that this is exactly the quality of "easy" that Rich Hickey was deriding in his "simple made easy" talk.
    • Also really resonates with How Buildings Learn. Hey that's an idea, why isn't there more work on How Software Learns, that is, how it evolves over time as it adapts to the changing needs of its inhabitants (users and developers).
    • A strong theory of what programming is really about:
    • Most programming languages are excellent for building the program that is a monument to design ingenuity—pleasingly efficient, precise, and clear—but people don’t build programs like that. Programs live and grow, and their inhabitants—the programmers—need to work with that program the way the farmer works with the homestead. This, I think, is the challenge of programming language design in the next generation: to recognize, finally, what programming really is and to address those issues, not issues of elegance and monumental programs.
    • Software needs to be habitable because it always has to change. Software is subject to unpredictable events: Requirements change because the marketplace changes, competitors change, parts of the design are shown wrong by experience, people learn to use the software in ways not anticipated. Notice that frequently the unpredictable event is about people and society rather than about technical issues. Such unpredictable events lead to the needs of the parts which must be comfortably understood so they can be comfortably changed
    • This part looks like it is inventing Agile
    • Finally, if Alexander’s lesson applies to software, it implies that a development project ought to have less of a plan in place than current thinking allows. This provides a mechanism for motivation and a sense of responsibility to those developers who later must work with the code.
    • (but that's because agile was trying to re-invent some of the things that came natually to Lisp programmers...I remember when Agile or XP was a first a big thing, I could make no sense of it, because I hadn't had experience with the waterfall methodology it was a reaction against)