You don't have to write it (all) first...

It seems like I get pretty much the same questions all the time.  A common one is, "Rico can you tell me if it would be ok for me to use <technology> to solve this <problem>?  How much does <technology> cost anyway?"

The answer is (nearly) always the same: "How the hell should I know?"

This is frequently followed by lamentations that there isn't some giant book of costs in which you can look up <technology> and see how expensive it is in <units>.

The contrapositive of this situation is where a person decides that they can't possibly know what anything is going to cost until they build the system and measure it.  I suppose if you're being pedantic that's true but as a practical matter nothing could be further from the truth.  Both situations have the same resolution.

If you want to get a sense of what something is going to cost, build a little gizmo that does kinda sorta what you have in mind and measure it to get a feel for the costs.  Don't do all the work of getting your business logic right and the specifics perfect, throw something together on the cheap that is going to give you a feel for the essential costs you are going to have. 

Here's a very specific example that came up not too long ago:  someone wanted an opinion on what it would cost to convert their data protocol from http to https.  How do you get that answer?  Well getting a complete answer will require a big investment but getting a sense of if you can afford this and what to look for is remarkably easy.  Write a little thingy that fetchs about the right amount of data with http then replace it with https -- this is like a 10 minute exercise.  Then look at both from a CPU perspective, and maybe network I/O, and DLLs loaded/code used too.  Try various request sizes and in particular some that are kinda like what you intend to do.  This can very quickly give you a sense of whether this is something you can afford and will give you excellent insights into what your final costs will actually be.  As your real code comes along, keep looking at it using your initial measurements as a touchstone.  If your costs start to be wildly different than your initial forecast, then you missed something.  If that happens you're going to know a lot sooner than the finish line that things are not going as expected.

This technique works in many domains -- database connection and query costs, UI frameworks, data processing, serialization, pretty much anything -- it's kind of like test driven development but for performance factors rather than correctness.

Whatever you do, don't tolerate a "we won't know until the end" attitude or, just as bad, "ask some expert, they're bound to know..."

Experiments are your friend.