Adding a new design constraint to D

[Ola Fosheim Grøstad]

On Wednesday, 15 June 2022 at 02:15:16 UTC, norm wrote:
> D's only real problem is people power.

This is a not true at all. D would end up in the same position no 
matter how many people you throw at it. You first need to:

1. set clear goals

2. design an architecture that makes the goals achievable and the 
product maintainable

3. set up an iterative process that provide a clear path to the 
goals

4. evaluate and improve the process

D has both a formal and informal process, but the informal one 
trumphs the formal one.

Then you either need to break up the culture and enforce the 
formal process or you need to change the formal one to match the 
informal process and improve on it from there.

So there are two realistic options:

A. View dmd as legacy and switch focus to SDC or some other clean 
slate approach, help out by setting clear goals, create a 
documented architecture, set up an iterative process.

B. Adopt the informal process for dmd, and modify it by creating 
a clear separation between people who create and people who do 
quality assurance. Give the latter team full veto power. Then 
create a plan for giving dmd an architecture.

Option A is probably easier and cheaper.