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.
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.