[RivieraKid]

The only way to do it I can think of: have two teams or individuals develop the same thing simultaneously and measure the time required to get a result of the same quality. This should be done in longer term to take into account code quality (poor code quality slows down future development).

[ptr]

I did this once for a medium complexity task. The quality ended up the same because both developers had good taste. One developer took 2 hours for the job, the other took 2 weeks. And people don’t believe in 10x developers...

[craftinator]

A few things can play havoc with this type of measurement. One is that the way we determine the "quality" of the code is based on the current scope of the project.

If the scope right now is pull a bunch of values out of spreadsheets and generate reports on them, the highest quality code would be the most terse: it looks up the files, get the information, then displays it. If tomorrow the scope changes to "do that, but in realtime, across multiple machines", the highest quality code is the one that implemented a database and REST API.

Since scope changes all the time, we can never evaluate which set of code is the highest quality.

[Lorean]

And then keep adding new features (identical for both teams) for a few years and measure the time taken.