Comment by atrettel

Comment by atrettel 6 days ago

The "assets" and "debt" discussion near the middle is interesting, but I can't say that I agree.

Yes, many programs are not used my many users, but many programs that have a lot of users now and have existed for a long time started with a small audience and were only intended to be used for a short time. I cannot tell you how many times I have encountered scientific code that was haphazardly written for one purpose years ago that has expanded well beyond its scope and well beyond its initial intended lifetime. Based on those experiences, I write my code well aware that it may be used for longer than I anticipated and in a broader scope than I anticipated. I do this as both a courtesy for myself and for others. If you have had to work on a codebase that started out as somebody's personal project and then got elevated by a manager to a group project, you would understand.

spenczar5 6 days ago

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)

Reply View 1 reply

atrettel 6 days ago

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.

Reply View | 0 replies