Thanks for mentioning the XY problem. I of course deal with this constantly and have never heard it so named. I usually try to explain this to people (in a professional context who are owed an explanation) in terms of "how", and "what and why." They come to me with a "how", which is usually just baffling and not instructive at all (being based on all kinds of incorrect assumptions, false premises, etc.), when what is really needed is the "what and why", which I can use my domain specific expertise to devise a "how" appropriate to the circumstances. In a professional context, one is still often compelled to do things in a "wrong" way, but that's a lot easier to swallow when one is being paid for one's time. In the free software context, usually no one is paying me for even the time it takes to kindly explain that an idea doesn't make any sense. And if they're not receptive to logical, reasonable, technical criticism of their ideas, then it's plainly obvious that it's not a situation where two or more people are working together for free for mutual benefit (i.e. making software better), it's a situation where one or more people are demanding that one person implement (with no compensation of any kind, either financial or through increased usefulness of the product) their poorly thought-out schemes.
Regarding sunk costs: I don't see how someone could get locked into a sunk costs bind if they're just talking about an idea or proposal. It's just chalk on a chalkboard at that stage---what is there to be attached to? It's not as if they spent more than 2 seconds coming up with the idea (which is evident from the sketchy reasoning). I am constrained in many ways though, I'm constrained by my past decisions (project scope, architecture), and I'm constrained by concern for my future self (so, don't do anything that will create headaches later), and I'm also constrained by my users, who doubtless, just like me, have plenty of sessions they don't want broken by some new feature they may not even care about. There are many things which would be much easier to do in a manner that breaks compatibility, but if I'm going to change a behavior that's already relied upon in dozens of my own sessions and who knows how many sessions of other users', I have to spend a lot of extra time figuring out a way to do it that isn't disruptive (in case I want to go back and remix or remaster something, or they're still works in progress [protip though: always print your mix before you walk away for a while]). This is, BTW, another way that software becomes complicated over time. It isn't bloat per se in that it is necessary in context, but it usually does make for more lines of code, code that is more difficult to reason about and maintain, and more complex project file formats. Some of the issues that people come to me with aren't so much things I don't want to do or disagree with as they are things that aren't nearly as simple as they seem at first glance (while maintaining back/forwards compatibility). This is the main reason that I personally try to put all my "brilliant" ideas through the ringer before committing them to (published) code. That thing that seemed cool yesterday might seem like an enormous gotcha tomorrow. And yes, it probably *can* be worked around, but at the cost of a lot of unnecessary effort and additional lines of code. On Thu, Jan 7, 2021 at 8:56 AM Aaron Duerksen <[email protected]> wrote: > Amen! > > I also like a good lite tool that hosts independent plugins, instead of > doing everything on its own...again...with its own set of bugs and > workarounds for the exact same thing. Light at the core, with a personal > set of plugins that together might be bloated, but that's the plugins' > problem and the user's problem, not the core. I think you've nailed that > with Non. > > Keep up the good work, and...sigh...continue to defend it against the > folks who insist that it be a monolithic monster, because they'll probably > never go away. > > > > To specifically comment on those people that demand a certain function in > a certain place: Not everyone even has a clue how software works, or > anything technical for that matter. I've worked with a few of those myself. > > I was a FOH Engineer and System Architect, for example, basically running > the system that I built on a regular basis, and the leadership would ask > for way-too-specific things as if they had somehow understood what was > there and did a fair amount of engineering themselves on it. Of course, > that "understanding" was wrong and so, therefore, was the engineering that > they did. But because that was the first that they were consciously aware > of, that's what they insisted on. Sometimes I could just ignore it, and > they would eventually accept a "no", other times I could do some > "theatrical magic" and make the real system *look* like it did what they > wanted when it was really doing something else that appeared similar on the > surface (that they never looked past). > > But I was always nervous about the "theatrical magic" approach because it > gave them a false data point that they could then use against me. "You did > 'X'! I saw it! Why can't you put 'Y' on top of it?! That should be > obvious!" > Actually, I didn't do "X". In fact, "X" was impossible and still is. I > only did something like looked like "X", and absolutely does not support > "Y" at all like I agree that "X" would have. > > > > I've also seen the same thing in an industrial equipment company. The > investment firm that bought a private company, made those same mistakes, > and were bad enough at it that they created a revolving door of engineers, > who kept taking whatever tribal knowledge they had with them, when the > general market at the time said that they should have had engineers lining > up at the door to work anywhere. I left there myself, close to my 1 year > anniversary. > > I don't think they ever realized how much they were actually costing > themselves by trying to do the engineers' job for them, and not listening > to a direct-expert's "No." Pretty soon, all of their engineers didn't > really know much (like me, still young), or had questionable attitudes > (claimed to plant a "code bomb" as he left - I looked all over it and > couldn't find one, but still...), and that's also costly in ways that are > inherently not obvious. > > > > To further generalize it, I've seen this described as the X-Y Problem, > where the real solution is to backtrack a lot and take a completely > different path...except that some (a lot of?) people can't do that because > of the Sunk-Cost Fallacy: > https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem > For the Sunk-Cost bit, they've spent a lot of mental effort (at least) on > their pet solution, and so they can't let go of it, no matter how > ridiculous it seems to everyone else. A dead-end impossible project at > that industrial equipment company, for example, which all the engineers and > technicians knew, but a manager continued to waste company resources (and > marketing) on. > > > > Your great advantage, Male, is that you don't answer to anyone but > yourself on this project. You can afford to blow those people away...as > long as you're okay with continuing to do it, over and over again. They > might wear you down if you pay too much attention to them, but they can't > do much more. > > > > ------------------------------ > *From:* John Rigg > *Sent:* Thursday, January 07, 2021 6:58AM > *To:* Non > *Subject:* Re: [non] The Parable of the Free Software Developer and the > Imposing Stranger > > On Wed, Jan 06, 2021 at 10:15:32PM -0800, J. Liles wrote: > > I feel like all of this should be self-evident. > > It is self-evident to those willing to see it. > > I've been recording music for a long time, on both hardware > and software. My mental model of how a recording system > works was formed in traditional analogue recording studios. > Non, with its modular design, fits that mental model better > than any monolithic DAW I've ever used. > > I also do electronics tech work for commercial studios. It's > easy to spot the gear that was designed by someone who uses > it themselves. It tends to have a restricted number of > features, but they all work well. It also tends to be > reliable and easy to maintain. > > Contrast that with gear designed by a marketing department. > It tends to have a lot of fancy features that can get in the > user's way. It's often unreliable and a nightmare to > maintain. > > Software follows a similar pattern. Non is firmly in the > 'designed by user' category. It's reliable and doesn't get > in my way with excessive handholding. > > A lot of other audio software follows the 'designed by > marketers' pattern. That's fine if it's what you want, but > it becomes a problem if you try to force all software to be > like that. Nobody has the right to demand a feature that > goes against a developer's design philosophy. > > John > > > >
