In my time working on Julia, I’ve seen a lot of requests for estimates of when some feature will be finished, or a roadmap for how it’s going to be accomplished. This post is intended to summarize why satisfying these requests is sometimes difficult or impossible, and address the much smaller issue of how such requests can occasionally come across as seeming entitled or ungrateful. Over time I’ve tried answering these requests in different ways, trying out different approaches for making the point clear. I should also say that when I started with Julia, I too had some of the same hopes that development would be predictable; you can think of this as a note from my older, wiser self to a less-experienced me.
In my view, the difficulties in providing a timeline (or even a sketch of the solution) basically boil down to two factors:
- for a nontrivial project, the engineering challenges often cannot be fully anticipated, even in order-of-magnitude
- the realities of open-source development mean that human timelines may trigger large gaps in calendar timeline
The difficulties of anticipating engineering challenges
Julia has many unique characteristics, not shared by any other programming language I know. (I don’t doubt this also applies to many other languages and open-source ecosystems, but I know Julia better so I’ll phrase this discussion in terms of what I know.) What this means is that implementing new features is often a research project in and of itself. Just because some other languages do X does not mean that all we need to do is copy their solution for X into Julia: often the fact that Julia also supports Y means that prior approaches taken to implement X won’t work in Julia. In such cases, we have to invent a novel approach.
Many of us are used to research being unpredictable. Few would expect a useful prediction of when nuclear fusion will become cost-effective, or when you’ll be able to take a pill to cure Alzheimer’s disease. But it’s easier to imagine that things are somehow more predictable in the world of software. Sometimes, this is even true. But “nontrivial” (whatever that means) changes often seem to fall into a different category. A spectacular example of this was the difficulty in forecasting what would be “easy” and “hard” in artificial intelligence: if I know my history (and I may not), it was thought that playing chess would be hard but navigating a room would be (literal) childsplay—it’s incredibly easy to take some things for granted that one shouldn’t.
In developing Julia itself, there are several factors that increase the difficulty of making accurate predictions:
-
One of the easiest to overlook is the requirement of backwards-compatibility. You might want to add some new language feature, and that might improve the lives of 98% of developers, but what if it breaks one out of every 5000 packages? This is not hypothetical, and the Julia ecosystem has set up PkgEval precisely to test this. There are many examples I could name: two recent ones I’ve seen with varying degrees of closeness are the need to create an API to support foreign objects in order to deliver precompilation without breaking some amazing existing packages and the heroic challenges in instantiating a major upgrade in Julia’s parsing. Often, avoiding breaking even a tiny fraction of packages can add weeks, months, or even years to a project.
-
Some problems are only solvable with tradeoffs. For example, type-inference is always up against the halting problem; you might pay for extra quality of compiled code with longer (or even, never-terminating) compilation. More generally, it’s very common that a cool new capability gets developed, but at least initially the tradeoffs prove to be unacceptable. At that point, it becomes your research problem to figure out how to mitigate those tradeoffs while preserving the advantages of your new capability. Sometimes, heroes swoop in and save the day; for example, the recent advances in precompilation are satisfying in no small measure because folks like @kristoffer.carlsson and @ianshmean made extensive changes to Pkg to reduce excessive precompilation. But as often as not, the original developer(s) usually end up fixing the negative consequences, and because that’s often a completely different problem it’s very unpredictable how long that will take.
-
Some projects are effectively unpredictable developments bottlenecked on other unpredictable developments: there will be lots of cool things we can do with debuggers, Revise, and displaying inference results to users if major changes to Julia’s internals get made, but those changes are research projects of their own.
What this means is that it’s often not possible to predict either how or when a given feature may be finished. It may be possible to put out a “sketch” of a solution, but with growing experience I seem to be getting more reluctant to put those out there. I’ve seen my sketches fail miserably too many times, and putting something like that out in the wild starts making things feel like a contract or setting up some eager volunteer (who sweetly decides to start working based off your sketch) for more trouble than they bargained for.
The mismatches between human timelines and the calendar
Expertise among Julia contributors is not distributed uniformly, and even people who have done amazing things in one subsystem may know little about another; when a project ends up involving an unexpected interaction with another subsystem, now you have a time/expertise problem on your hands. Sometimes someone with the required expertise can guide you through the challenges, but this often requires a pretty massive donation of effort on their part (they have to come up to speed on what you’ve done, and how they can help). Even when the spirit is willing, there may be practical factors that make it impossible.
The other factor is that a small “miss” on finishing something can translate into a large calendar delay. This wouldn’t happen as often if more people were paid to work on (your) hard problem in Julia full-time, but the reality is that many of the amazing changes to Julia are contributed by volunteers: grad students who get fed up with waiting for something they want and just decide to implement it themselves, professional developers whose paying job fully occupies their time on customer-satisfying goals but who decide to devote part of their winter break to work on something they’ve long wanted, etc. But this reliance on donated effort introduces a challenge: when the feature takes longer than anticipated, that graduate student may need to task-switch to prepare to present at a conference, or that paid developer’s winter break may be over, or that grant deadline suddenly looks uncomfortably close and the whole lab needs to focus. Thus, missing by a week of human effort can translate into a month or a year of calendar time: when relying on volunteer time, you can’t even get the order of magnitude right.
Entitlement/lack of gratitude
This is not a big deal, but asking for timelines or roadmaps can sometimes feel a bit entitled: usually the requester is not actually proposing to work on it themselves, which begs the question of why this information is needed. Software development doesn’t need to be a spectator sport where by cheering on new advances you hope to beat the competition. Like other people, I’d love to know whether it’s worth upgrading my phone now or wait for some new cool technology, but in the end the risk for that choice has to be on me.
While it is perhaps just a personal mis-impression, I also think there tends to be an uptick in these kinds of requests shortly after some significant advance has occurred—people naturally get excited to see change, dream big (“here’s what Julia needs to take over the world!”), and start getting impatient. Totally natural and understandable. But if someone walks up to you on the street and gives you a present, few of us would say “Thanks! When do I get the next one?” The better question to ask is, “wow, that made my life better. How can I use this to return the favor by ‘passing it on’ to others?”
Again, this last point is not a big deal. Gratitude in this community is expressed frequently and runs deep. Lots and lots of people indeed “pass it on” by using Julia to write amazing software that attracts new users to the community. I hope it always stays that way!
, but when one tries to look further all that can be found is a lonely set of PRs with very short descriptions and equally concise review comments!