"Well, I'm assuming we're comparing code that works."
That is an interesting assumption given that in many problem domains proving that the code works as specified is the hardest problem.
"Maintenance is generally a red herring, it's best to use statistical methods to determine the likelihood of maintenance."
I really dislike anyone who makes general claims about the entirety of software development. I for one spend way more time changing existing code than writing new code. I know that there are problem domains where that is not the case so I don't recommend my methods for those spaces.
What are these statistical methods you are referring to?
"Usually if you're doing lots of maintenance you have other problems in your code / workflow, such as mistaking your codebase for your database."
Or you are working in a problem domain that shifts a lot, or where requirements specification is more expensive than deployment opportunity costs, or in a legacy system.
Proving your hand won't go through a wall is a difficult problem in quantum physics, for most people they just push against the wall. I don't care whether the code is provably correct, I care that it does what the user expects.
Actually 'change requests' are even easier when the requirements change frequently, just provide an estimate in excess of when you think the next change will be, then put your feet up and wait for the requirements to change again.
PS. Changing requirements isn't 'maintenance', it's a change request.
PPS. Having to add code to add fields to a form means you spec'd your solution around your forms instead of specing your solution around solving the problem of changing forms. (aka. you baked your problem domain into your code and now you're fucked) (eg. you mistook your codebase for your database)
