It would be interesting to attempt an analogy between software development processes and parallel computations. Let's analyze which job tasks are atomic, parallelized, depend on read or write operations with common shared data, and the costs associated with setting up new job tasks.
It is likely that we would discover that the majority of programming tasks are not parallelized and are costly to set up, especially if frequently switched between job workers. This is because programmers need to delve into the problem domain, the existing code base, the API, and various other factors before commencing an actual task implementation.
Assuming that task workers are fully fault-tolerant ("no bus factor"), the optimal design would involve dividing the code base into loosely coupled modules, possibly organized into a hierarchy, with each module's management entrusted to a single worker (programmer). To mitigate the fault factor, we might have substitutional task workers dedicated to critical modules.
Regarding other task types, such as manual testing, these are usually less expensive to set up, do not require write access to the code base, and can be efficiently implemented by worker groups not bound to specific code modules.
This approach should be scalable and could effectively contribute to product quality. However, it necessitates the business being run and owned by programmers, and more crucially, earning revenue directly from end users who value product quality—a major success factor for the business.
There are successful examples of businesses following this model, including many indie game development studios and some software product businesses. The scarcity of such examples in the broader business community is attributed to the fact that the majority of funds today come from large corporations and ultimately from governments. This system undermines the free market, impacting everything in software development, from product quality to development methodologies.
It is likely that we would discover that the majority of programming tasks are not parallelized and are costly to set up, especially if frequently switched between job workers. This is because programmers need to delve into the problem domain, the existing code base, the API, and various other factors before commencing an actual task implementation.
Assuming that task workers are fully fault-tolerant ("no bus factor"), the optimal design would involve dividing the code base into loosely coupled modules, possibly organized into a hierarchy, with each module's management entrusted to a single worker (programmer). To mitigate the fault factor, we might have substitutional task workers dedicated to critical modules.
Regarding other task types, such as manual testing, these are usually less expensive to set up, do not require write access to the code base, and can be efficiently implemented by worker groups not bound to specific code modules.
This approach should be scalable and could effectively contribute to product quality. However, it necessitates the business being run and owned by programmers, and more crucially, earning revenue directly from end users who value product quality—a major success factor for the business.
There are successful examples of businesses following this model, including many indie game development studios and some software product businesses. The scarcity of such examples in the broader business community is attributed to the fact that the majority of funds today come from large corporations and ultimately from governments. This system undermines the free market, impacting everything in software development, from product quality to development methodologies.