But I'm dissatisfied with the generalizations being proposed. We've heard before that programs are intended for humans to comprehend and only secondarily for computers to run. We've heard that programming interfaces are user interfaces. We've heard many many many attempts at distilling experience into maxims for others to follow. And yet those vague 'others' never follow said maxims.
What we tend not to track down is the reason why software is the way it is. We're warmer when we say the culprit is social rather than technical, but even that's not quite accurate. The culprit is political. Users of a piece of software aren't all the same. They can be segmented in many many ways, but I'll focus on one: people upgrading from D3 v3.0 and those coming straight to D3 v4.0. There's a tension between the needs of these segments that is identical to class warfare: every change to the API improves the life of the latter but adds an inconvenience to the former when upgrading. It's quite possible that D3 has done a good job addressing this tension with semantic versioning, and by being a tool rather than a service that users can upgrade on their own schedule. But this tension and the ways we choose to address it is by far the bottleneck in general. Most tools atrophy and fail to adapt to changing environments because they get captured [1] by existing users to the detriment of new users, and eventually to the detriment of everyone.
Repeat after me: compatibility is the mind killer. At least when we are building software for other programmers rather than end-users, we need a new social contract that allows newcomers and upgraders to coexist more peacefully and sustainably.
> What we tend not to track down is the reason why software is the way it is.
The rest of your comment goes in a different direction, but still, you might be interested in the Big Ball of Mud essay:
> While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.
Thanks; it was good to reread those patterns. I wonder how the trajectory of say a life stage like http://www.laputan.org/lifecycle/lifecycle.html#Consolidate is affected if some or all of the people responsible for previous stages left in the interim.
One of the main (logical, reasonable, and real) requirements of most software systems is building and maintaining them under budget. When you disregard compatibility in the name of progress you make a decision on behalf of all of your users: that whatever added functionality or increased elegance or consistency your product now provides, it is more important than their budget requirement. For most of your users, that decision is simply wrong.
You're right that it provides benefits. That's why I phrased it as a tension. So when I attack it I'm talking about looking for alternatives with all the same benefits and more.
As a concrete proposal, here's something I wrote a couple of days ago: https://github.com/akkartik/mu/blob/14d3dacc4d/Readme.md. I deleted it yesterday because a Readme feels like the wrong place for it, but it's still useful as an elaboration of my current thinking.
I really wanted to like this article, but it should have been called "What Makes Software Interoperability Good." There wasn't a lot of useful information about what makes software good at a high-level.
At a high level, what makes software good has almost nothing to do with how we code, and almost everything to do with what we code. If it solves a problem, simply, easily, and quickly, it is good.
Side note: the images in the middle of the article are Masahiro Mori's 1969 "Fancy Cups", and solve the problem of "you've all put down your drinks and now nobody remembers whose was whose" with tactile feedback -- without giving everyone a different style of cup. Right now I and my girlfriend have been doing the same by collecting a bunch of individual mason jars from different flea markets, ensuring that none of them look 100% alike, to try to replicate the same effect on a budget.
As for the article content, I am in general somewhat skeptical of these highly-cerebral approaches of "what can we learn from that?" -- it is very hard to remember those maxims when you are setting out on a new project, even if they are taped up on your desk! A simpler maxim which would save a lot of effort is "You only have to solve the immediate problem in front of you -- stop trying to anticipate the next one," and perhaps another is "Don't start that project until you spend a whole shower/bath thinking up some perspectives on different ways to solve this problem." As Alan Kay says, the right perspective is worth 80 points of IQ. Maybe one more is "design top-down: create a non-working prototype of what you want the end user to be able to do if they could magically will some functions to exist, then fill in those functions' type signatures and some stubs, then fill in those functions' bodies."
So for example I bolted one idea on top of an existing infrastructure this past December. The preceding infrastructure was really good for what it did -- categorizing books statistically by content -- and this would look at the categories of the book and then perform some action with it. This works great for the 90% of the use-cases we care about and we have humans filter the remaining 10%, making them 10x more efficient -- great! Except for the setup, which is painfully expensive, because now we have to set up these category rules etc. for anyone who wants our custom-action service, which turns out to put 2 layers of indirection between "here is this book" and "here is the action I want to take on it." Some client says "well I want to filter out the books containing this phrase", now we have to define some new categories, some appropriate rules to filter into those categories, and then set up new rules to act on the assignment of this category -- not fun, and the many-to-many table joining categories to actions is just annoying to deal with.
Instead I should have implemented (and am now implementing) a little microlanguage where you can just read what causes the action in one TEXT field in the database, and decouple these two systems completely. Then it becomes easy to ask someone, "hey, could you specify those rules? Here's a widget to test against with validators..." and they can see it for themselves. Now they can build a bunch of these in some text or Excel or whatever document they're using, and just send them to me, and all I have to do is change curly-quotes to straight-quotes.
No, software you don't have to interact with - that just does whatever you need done - seems to me to have more value than something I have to configure.
it still does something, so there's gain, but the cost is lower than if you had to configure it.
But I'm dissatisfied with the generalizations being proposed. We've heard before that programs are intended for humans to comprehend and only secondarily for computers to run. We've heard that programming interfaces are user interfaces. We've heard many many many attempts at distilling experience into maxims for others to follow. And yet those vague 'others' never follow said maxims.
What we tend not to track down is the reason why software is the way it is. We're warmer when we say the culprit is social rather than technical, but even that's not quite accurate. The culprit is political. Users of a piece of software aren't all the same. They can be segmented in many many ways, but I'll focus on one: people upgrading from D3 v3.0 and those coming straight to D3 v4.0. There's a tension between the needs of these segments that is identical to class warfare: every change to the API improves the life of the latter but adds an inconvenience to the former when upgrading. It's quite possible that D3 has done a good job addressing this tension with semantic versioning, and by being a tool rather than a service that users can upgrade on their own schedule. But this tension and the ways we choose to address it is by far the bottleneck in general. Most tools atrophy and fail to adapt to changing environments because they get captured [1] by existing users to the detriment of new users, and eventually to the detriment of everyone.
Repeat after me: compatibility is the mind killer. At least when we are building software for other programmers rather than end-users, we need a new social contract that allows newcomers and upgraders to coexist more peacefully and sustainably.
[1] https://en.wikipedia.org/wiki/Regulatory_capture