I don't think you can really understand "the inherent complexities" of anything with inherent complexities from the outside.

"What I cannot create, I do not understand" - Richard Feynman

I agree completely, and I think that reimplementing things is a great exercise to learn. This doesn't mean that you should do this exercise on "real" conditions. Instead you should practice and learn about the subject before doing something. That is we let people build their own cars, but we don't let those cars go on the street because they haven't passed the necessary tests to verify they won't light on fire.

OpenSSL is very much in that category.

My response to that is read the first line. One of the reasons we say "don't reinvent the wheel" is because people assume that complexities in software are arbitrary, that everything is simple and elegant in their mind. This is rarely the case once it goes into practice. For learning this is OK, it gives you insight into why things are the way they are. In production, were extra pressures and deadlines exist, and were your errors will have consequences that cost money this is NOT OK.

So unless you're already an expert in one of the appropriate technologies you're kind of stuck. There's no way to know in advance whether any library or framework or program is really suitable.

There's the rub eh? This is the issue with being a programmer. You need to learn about a problem and gain knowledge. If your manager doesn't give you time to research, then you pick the solution that seems to most trustworthy (based on age, support and usage) and go with that, leaving it clear that there wasn't time to do more research.

And it's cheaper to use an existing library, realize how it doesn't meet your requirements and learn that you need a homemade solution and then reinvent the wheel than instead to make your own solution, see all kinds of problems, only to realize that someone else did exactly what you needed and you could have saved all that time.

Either way (and as I wrote) if you're being objective and doing a half way decent job and it's important enough to get this right now you can easily burn weeks just comparing the existing solutions.

What's the old adage? "Measure twice and cut once". I know that realistically this isn't the case. But if you don't have time then just use an existing library until you've learned how the problem works well enough to judge if you implement something or not.

In the end it comes down to opinion. I could give you all manor or arguments for why nothing is really appropriate and you could shoot them all down with "don't reinventing the wheel". Which is my real problem with these phases. "don't reinvent the wheel", "premature optimization", "worse is better" (ignoring the original/intended meaning), "NIHS", <design pattern/principle or paradigm/religion or choice>, are all highly questionable as far as I'm concerned, but they're an excellent ways to end a potentially useful argument. It's a form of "developer shaming"/"appeal to [false] authority".

Again the thing is that this is repeated so much we think these phrases are laws, when in reality they are advices. I guess it's our nature as programers to be anal about syntax and semantics, plus it's great bikeshedding material, but these are the kind of rules that, once mastered, must be broken. The challenge is to know when and how. I don't feel this is an issue with the people I've been discussing with.

Ok. I'm jaded. I've seen this play out enough times that I've decided (rightly or wrongly) that it's usually better to fit the right wheel than to bolt on whatever you can find because it'll probably be ok [2]. If you have a half-way decent team you're probably better off just from the increased level of understanding and control that you get from this.

I agree, I think that most of the time you end up finding that the wheel you need doesn't actually exist (only similar stuff exists). With some things this is more common than others. I doubt it is the case with an SSL library though.

Sometimes I get the impression that programmers don't actually believe they can program. They're happy to plug pre-built solutions together without stopping to ask even basic questions, but if you ask them to solve a real problem themselves you get ideas like "your problem is not unique"

Nah, I trust programmers that are as lazy as possible. Plus just because I know I can code a computer from the kernel up doesn't mean I am going to! I'd rather use as much existing things and focus on doing something that no one else has done yet.