[spenczar5]

The issue is, whats the alternative? People are generally bad at predicting what work will get broad adoption. Carefully elegantly constructing a project that goes nowhere also seems to be a common failure mode; there is a sort of evolutionary pressure towards sloppy projects succeeding because they are cheaper to produce.

This reminds me of classics like "worse is better," for today's age (https://www.dreamsongs.com/RiseOfWorseIsBetter.html)

[atrettel]

You're right that there isn't a good alternative. I'll just describe that I try to do even if it is inadequate. I write the code as obviously as possible without taking more time (as a courtesy to myself), and I then document the scope of what I am writing when I write the code (what I intend for it to do and intend for it to not do). The documentation is a CYA measure. That way, if something does get elevated, well, I've described its limitations upfront.

And to be frank, in scientific circles, having documentation at all is a good smell test. I've seen so many projects that contain absolutely no documentation, so it is really easy to forget about the capabilities and limitations of a piece of software. It's all just taught through experience and conversations with other people. I'd rather have something in writing so that nobody, especially managers, misinterprets what a piece of software was designed to do or be good at. Even a short README saying this person wrote this piece of software to do this one task and only this one task is excellent.