On Thu, Dec 17, 2020 at 1:00 PM Larry McVoy <lm@mcvoy.com> wrote:

I think it is part of being really smart, it's a puzzle for them and they
"win" if they can do something clever. I always replied "It is write once,
read many. Optimize for reads".

Amen to that bro.

And at the risk of getting either Jon or Ted (or both probably) I think that what astonished me when Jon and I were discussing how the Linux FS stuff got spliced in with so many macros and indirections, frameworks, et al. earlier in the summer (i.e. when Jon was trying to build up his newest idea); the Linux kernel code for the FS interface was so 'clever' (ney complex and indirect) that was no longer clear what in the code did what to either of us (and Jon and I are hardly neophyte C programmers). As Ted fairly points out it works and seems to be reasonably fast in practice, and the Linux kernel team has created test code for some of it all which is far better than the coding practice in a lot of the rest of the FOSS community at large. But I suggest that sometimes just because you can do something, doesn't mean you should (tipping my cap to Rob's 'cat -v harmful' observation of years gone by).

As a side note, I will say there is another vector to this same curse. It's the new guy coming into the project and deciding what is there is crap, they can not understand and they can do a better job. IMO this is a problem that is rampant in many FOSS community projects, but I used to see it at DEC >>all the time<< and still run into it at Intel these days. Picking on DEC and using Tru64 as an example, it took 3 extra years to get Tru64 out the door from the original OSF/1 codebase because of it. Every major subsystem was rewritten. Not saying what they got from OSF was perfect, but DEC could have shipped Tru64 with the original terminal handler/SCSI/memory/graphics/100% 64-bit clean ... and replaced the code later with 'better' implementations.

The bottom line for me is that I rather give up a tiny amount of the absolute speed for long-term scale and maintenance cost (then again it one of the reasons while I'm a microkernel fan too). Unless this new feature/rewrite something that is really going to make or break me, I rather make what works today, and evolve over time when I have a revenue stream (i.e. OSF/1 was good enough for most of Alpha, but Tru64 was amazing -- it just took three years]. Plus, as Warner points out, the original author will be long gone - which only play farther into my thinking of simple is clear is better in the long run. No just in FOSS, again, DEC/Intel, we have people retire or go elsewhere all the time (plus we get a new set of VPs that reset the corporate direction every 18-24 months).

My basic thinking is you should pick the one or two specific features that really matter for your product and you need to ensure that its value is exposed and very much available to the customer. The rest needs to be simple, clear, and works, and you're done. Get on to the next thing.

BTW: this is not just a system SW issue. I suspect it's more fundamentally human when people get excited by their own ideas and what they can do and don't stop to think about the true ramifications of the effort. One of my all-time favorite papers is Tom Lyon and Joe Skudlarek's wonderful 1985 tome 'All the Chips That Fit' which bemoans the hardware equivalent of this same problem [which if you have never read, as a system person you should].

Also, it's also not a computer business only issue. I have another story, I'm not sure if I have told here before, which I call the 'Milacron problem.' I use it to explain to our younger engineers why creating something new is not always the right way. Cincinnati-Milacron is one of the oldest, largest, and most respected machine tool manufacturers in the world. My HBS brother ran the robot division and later the machine tool group at one point. Milacron can make anything -- period. That is their business. So what happens, ever newly minted Mech E wants to make his own hydraulic values for their project. At some point in the 80s, Milacron had over 5000 different hydraulic values in their internal parts catalog because no one would take the time to see if one from a previous project would work.

Clem