The idea of a learning curve is fairly well-accepted, that one makes progress in gaining skills at some rate that can be “steep”, where it takes a long time to gain much proficiency, or “gentle”, where a fair amount of proficiency is gained relatively quickly.
Here, I want to propose the parallel idea of a software development curve. For some types of software, there is a gentle software development curve, where it is easy to get started in developing it, leading to software that has some initial useful functionality. While for other types of software, there is a steep software development curve, where a large amount of work needs to be done before the software provides any useful functionality.
An example of software with a gentle software development curve is workflow software. A developer typically starts with a script, perhaps a shell script, or a makefile, that lets them run some series of tasks in a repeatable manner, which is relatively easy to do, and works well in a limited environment. Adding additional functionality can then be done, such as the ability to run some of the tasks on a particular remote resource, transfer some data files, etc. But the more general the software needs to be, the harder it is to develop good software.
An example of software with a steep software development curve is computational science software, such as the computational electromagnetics software I developed as a graduate student at Northwestern and while working at Cray and JPL shortly after that. In order to develop software that provided useful results, almost all elements of the software needed to be developed, such as the core methods (discretizing and implementing the PDE solver(s)), the boundary conditions, methods of injecting source(s) of energy, methods of analyzing scattered waves, etc.
The difference here is the amount of initial work needed to build minimally useful software, which is low for workflow systems, and high for computational science software, though in both cases, there is a large amount of work needed to develop good fully-functional software. The difference is what fraction of that work needs to be done before there is some return.
A consequence of software that has a gentle development curve is that many people will start developing such software, leading to large numbers of packages that provide some functionality, and that as they do this, they will be subject to the sunk cost fallacy and will continue to invest in their custom packages, rather than joining together with others and building community packages, leading to large numbers of competing packages.
On the other hand, software with a steep software development curve encourages developers to use and modify/contribute to existing software packages rather than starting from scratch, leading to fewer competing packages, and more community development.
Notes:
The choice of the terms “steep” and “gentle” is somewhat arbitrary, but these terms used in this way regarding learning curves are fairly well-accepted.
This concept is probably related to software complexity and composability, as software that is less complex and more composable likely has a more gentle software development curve as well.
This is also related to the idea of a productivity curve, for example, as Mike Crittenden has written about.
I’m also ignoring maintenance here, not because it’s not important, but because I want to focus on development. How maintenance is related to software with different software development curves is an interesting future topic.
Daniel S. Katz's blog 
Hi Daniel – nice post ! A similar idea I’ve heard about is in relation to functionality and development effort: ie there’s a sweet spot where more development effort doesn’t yield equivalent improvements in functionality or usability. For some problems, since it doesn’t take much effort to get something usable, people don’t bother to reuse (or even look to see if there is anything to reuse).
This of course is subtly different – I quite like the idea of being able to use this concept to reason about whether embarking on a development project in a particular application domain/task might successfully yield a sustainable community project, or instead result in ‘yet another bespoke solution’.
LikeLiked by 1 person
Also, thanks for your private comment pointing out a couple of errors I made in the original post, which are now fixed!
LikeLike
While I certainly agree with your logic, I think there is perhaps a counteracting force with the codes with the steep learning code. Such codes tend to be large, complex and often not terribly well written, which makes them appear difficult to learn well enough to add new functionality. This couples with (what I think) is a common bias that there is tendency when first looking at a code to see the visible problems, and think we can do better. At the same time we aren’t as aware of the less visible problems, the edge cases, etc. that took a lot of time to find and correct, and which often distorted the code making it “ugly”. This leads to underestimating how much effort it really takes to develop a well-debugged and validated code while at the same time overestimating how difficult it will be to learn the existing code. And besides, it is more fun and mentally challenging to start from scratch! Reality is probably a balance between these two forces.
I am haven’t really thought as much about the case of the gentle learning curve, but it seems possible that this same bias is at play, but this time the effect is aligned with the one that you note, making it even more likely that people go their own way.
LikeLike
thanks – this is a good point to further consider!
LikeLike
Thanks – I’ve fixed those errors. And thanks for commenting overall!
LikeLike
The points laid out here make good sense, but it seems like the terms “steep” and “gentle” are backwards compared to the plot shown as an illustration. The one labeled “steep” starts out gentle (low slope) on that axis, and the one labeled “gentle” starts out steep (high slope) on that axis. Seems like you’d want different terms if you want to use that plot, or a different set of axes to plot if you want to use those terms!
LikeLiked by 1 person
Yes, I agree, and I noted this in the post, but this is the way these terms are used in terms of learning curves (which some people also say are backwards), but I decided to stick with what’s in use rather than what I might prefer.
LikeLike
Good points. As another comparison, there’s also a difference in the development curve (steep vs gentle) between languages. For example, the development effort to get a project to a similar point of functionality (not considering run time performance) in Python is typically much less than that of C++. In both this case of more complex languages and yours of more complex software, I wonder how much the grade of the development curve can be reduced by better design and planning up front.
I’m in the process of rearchitecting a scientific software project that has a development curve profile like your “steep” curve. It was very easy to get through a few major releases and milestones, but now every small step takes a ton of effort due to the baggage of a few rushed development sprints. I’m hoping to alleviate this problem by adding intentional design, patterns, and tooling.
LikeLike
Thanks – I guess there’s a tie to technical debt that you’ve found, and that I hadn’t thought about previously
LikeLike
I am agree for this post i note the refocused this post. really thank to u for share this post. i suppose this is good point for future consider.
LikeLike