This conceptual idea is apparently known to philosophers as “Eternal return” or “eternal recurrence.” Funny story for me, I worked with a business analyst one time who was a former philosopher. To purposely antagonize him, I gave a super amateurish explanation of Descartes writings and how I thought they applied to engineering in principle where I knew he could hear just to torture him while I butchered the subject. Coincidentally, this project had a bi-weekly mandatory team morale meeting. Go figure.
I can’t find the source of this quote today, but I’ve frequently heard and repeatedly used the following phrase to other folks (maybe from here?):
Software is never finished, only abandoned
I predominantly work with long lived codebases for software tools used by other developers. A very common source of frustration for me is making a bug fix release to burn down the open issue list, only to have all new issues get raised in the next couple hours. To some degree, any complicated software project is naturally going to feel like a Sisyphean task if you think of time as a straight line to being “finished” with the project for good.
Maybe this is a special problem for development tools (and I’ve worked on enough long lived business systems to say that nope, this is a pretty common issue for any long lived codebase), but no matter how hard I and the rest of the Critter Stack community try, folks will continuously come out of the wood work to:
- Report previously unknown bugs
- Stumble on unanticipated usages that aren’t well supported
- Hit performance or concurrency problems that haven’t come up before
- Simply make compelling suggestions about some new kind of use case for the tooling
- Need to integrate your tool with some different sort of infrastructure or even a different runtime
- Point out gaps in the documentation
- Describe content in the documentation that isn’t clear enough, or flat out misstated
- Express frustration about information they want to find in the documentation, but cannot — even if it is there, but just not in a way that made sense for the user to find
It’s admittedly exhausting sometimes trying to be “done” with long lived projects. I think my advice — not that I always live this myself — is to think of these projects as more of a cycle and a continuous process of slow, steady improvement rather than any kind of concrete project to be completed. For me especially, I need to constantly remind myself that technical documentation has to constantly pruned and improved in the face of user feedback.
My other scattered pieces of advice for dealing with the ownership of long lived codebases is to:
- Remember to celebrate the good things you’d done once in a while instead of always being focused on what’s not good yet
- Grant yourself some grace and not let it weigh on you just because there are some open bug reports or open questions at the moment
- Give yourself permission to unplug from message boards, chat rooms, or social media when you just need some mental rest when off work or even when you just need to focus during a work day. I sometimes have to completely switch off Discord some days when I’m at my limit of incoming questions or problems
- Have reasonable expectations for how fast you should be dealing with user issues, bugs, and feature requests — with the caveat for me that it’s a very different thing when those come in from paying clients or maybe even just from other contributors
- And lastly, if nothing else, unplug immediately and walk away if you find yourself either being or wanting to be snappish or brusk or sarcastic or rude to people asking for help online. Again, be better than I am at this one:)
I’ve worked over the past year with a couple clients who were building greenfield systems with “Critter Stack” tools, and let me tell you, that’s been a blessing for my mental health. Whenever you get to do greenfield work, appreciate that time.
The Shade Tree Developer 