Time flies while you're having fun, but then one day your bio says something about being a 30+ year veteran in software engineering. Still, I've not seen it all, let alone done it all (yet).
You say Project cost estimation has two established methods: Fixed price or Time and materials
These are not cost estimation methods, they are forms of commercial contract that can exist between a buyer and seller. The latter does not really require any cost estimation. For the former, the accuracy of your cost estimation will determine how long you stay in business.
In my opinion, there actually are only two established costing methods;
Rigorous application of calibrated costing model,
Everything else, for which the technical term is "Guessing".
Cost estimation (of any worthwhile accuracy) is only possible where an agreed and sufficiently detailed specification exists. This is common sense - if you don't know what you have to develop, you can't possibly say how much it will cost. Never-the-less, people attempt to estimate the unknown regularly. This is still guessing - albeit that you are guessing what the specs will be.
When you do know what you are supposed to be delivering, then you need to break this down into quantifiable activities for which you already have a known costing. If the project your are estimating is completely novel with respect to team experiences, then you will be reduced to - you guessed it - guessing.
So this means that accurate estimation is some how based on repeatability. Models for doing this have been around for literally decades (e.g. COCOMO). My own experiences had led me to an approach based around software architectures - a given software architecture being the set of patterns (used in a broad sense) that the solution will be composed from. If you're built applications before with the same architecture, and you bothered to keep metrics, you can estimate accurately. If your team is well experienced with an architecture, they will also execute more consistently too.
Now, this calls for a degree of technological conservatism - if you are chasing the latest and greatest stack with every new project, you'll struggle with getting any accuracy.
So if accurate cost estimation is important to you (and it probably should be), stick to what you know, and only change you approach in controlled steps.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You say Project cost estimation has two established methods: Fixed price or Time and materials
These are not cost estimation methods, they are forms of commercial contract that can exist between a buyer and seller. The latter does not really require any cost estimation. For the former, the accuracy of your cost estimation will determine how long you stay in business.
In my opinion, there actually are only two established costing methods;
Cost estimation (of any worthwhile accuracy) is only possible where an agreed and sufficiently detailed specification exists. This is common sense - if you don't know what you have to develop, you can't possibly say how much it will cost. Never-the-less, people attempt to estimate the unknown regularly. This is still guessing - albeit that you are guessing what the specs will be.
When you do know what you are supposed to be delivering, then you need to break this down into quantifiable activities for which you already have a known costing. If the project your are estimating is completely novel with respect to team experiences, then you will be reduced to - you guessed it - guessing.
So this means that accurate estimation is some how based on repeatability. Models for doing this have been around for literally decades (e.g. COCOMO). My own experiences had led me to an approach based around software architectures - a given software architecture being the set of patterns (used in a broad sense) that the solution will be composed from. If you're built applications before with the same architecture, and you bothered to keep metrics, you can estimate accurately. If your team is well experienced with an architecture, they will also execute more consistently too.
Now, this calls for a degree of technological conservatism - if you are chasing the latest and greatest stack with every new project, you'll struggle with getting any accuracy.
So if accurate cost estimation is important to you (and it probably should be), stick to what you know, and only change you approach in controlled steps.