[randomdata]

I expect M ≈ L, though. All you can ever gain by relaxing code quality is some keystrokes, but I'm not sure typing is a bottleneck to begin with. The bulk of the work required is the same no matter what the code looks like. I've often believed that M < L when I've tried to take shortcuts, but in hindsight I'm not sure it has ever ended up being meaningfully true.

[nerdponx]

It's not about code quality in terms of variable names and things like that, it's more about architectural decisions. What assumptions do you make, what edge cases do you cover, how much flexibility you build into the design, how extensible is it, what kind of tests do you write, etc.?

[randomdata]

> What assumptions do you make, what edge cases do you cover, how much flexibility you build into the design, how extensible is it, what kind of tests do you write, etc.?

This what I was referring to. I'm not sure there are shortcuts here beyond saving some keystrokes.

As you've mentioned tests, this is one place I see a lot of people thinking they can save time not writing them out, even opting for no tests. I expect a good test suite for the average application easily doubles the number of keystrokes required, at very minimum. The code doubling in size sounds like a lot more work, but is it really in the grand scheme? You still have to put in all the same amount of thought into those tests in order to write the code (and again if you choose to manually test it). All you've saved is the effort of typing out the tests, which I don't find takes all that long.

Maybe there are some slow typists among us? If you spend most of your time clacking on the keyboard then, indeed, the number of keypresses required could become significant. But that's not my experience.

[nerdponx]

It's not only about the time spent physically typing, it's about the actual thinking, iterating, prototyping, etc.

[randomdata]

> it's about the actual thinking, iterating, prototyping, etc.

Yes, these are essentially constants that need to be done no matter what the code looks like. Which, again, means that the only gains you might make is in reducing the number of keystrokes. To which, I dare say a lot of those keystrokes can even be done in parallel. For example, writing tests and thinking about the problem pair quite well together, so I'm not sure you even lose an insignificant amount of time on those added keystrokes in reality.

The latter points are also where you can quickly get into time trouble if you do sacrifice your code, which is how it often takes longer if you try to shortcut the code. This would be a worthwhile gamble if poorer/less maintainable code bought you time, but in my experience it doesn't even off the hop.