Level playing fields are for commies.

No, robber barons generally sent someone to your house too. They were more powerful than local government in many regions.

I take it you did not live in one of the regions that had DSL covered under Title II? The number of options and price ranges were far wider than today since Verizon was required to lease its lines, allowing 3rd parties to actually exist. When the FCC pulled them off the regulation, competition and options vanished almost overnight.

This is not far off how it used to be. Years back Verizon DSL was covered under Title II. They provided the lines, but you could choose any one of dozens of ISPs to actually buy your service from. It was wonderful.

The problem with elegant code is more often than not 'elegance' is rooted in how similar it is to what the reader has read before as opposed to objective measures. One only has to go to a meeting where people argue about what coding standard a project should use to see 'but this is so much more readable!' is all its arbitrary glory.

While I would not describe it as a religious issue, I would describe it as a cultural issue just as much as an experienced/engineering one. Experience is rooted in what has been done, so often it can be pretty reactionary regarding what mistakes have gone out of style and which ones have been forgotten long enough to be acceptable again.

This is why I tend to point to Java's dependency injection as an example of the pendulum swinging too far the other way. Much of it was developed as a reaction to what was being done at the time, but also in the faded memories of what was done before that...

I think the key piece is 'it depends on what you are writing'. Use of 3rd party solutions or internally developed ones is something that needs to be evaluated on a case by case basis, with various cultures and companies within tech, all too often, defaulting to one path or the other. I tend to feel that the pendulum has swung a bit too much, with 'not invented here' becoming such a boogie man that an increasing number of projects and defaulting to using external dependencies unless you can justify breaking away from that.

Yep, you are that old ^_~

In modern development one can go through an entire project without using any of the language's standard libraries or even, in extreme cases, the language itself. If you ever want to see a frightening example of this gone too far, take a look at over uses of Apache Camel or even Spring, where you can write entire systems using code embedded in XML files and that weird 'conditional logic as constructor arguments' camel allows for.

Even worse, when the framework is so general that there is really no envisioned usage outside 'all the things!' and you end up with something that requires just as much glue code as working with the standard API would have since it is no more special purposed than the original.

Sadly, it did not take a day. I really felt that the solution was not only more complicated but took longer to implement and test than the internal coding option would have. Granted the two approaches were not tried in parallel, but the amount of time and effort that was eaten up by taking the dependency injection route seemed quite excessive given the complexity of the problem being solved.

One example that really drove me crazy was a developer who was tasked with putting in a 'retry' mechanic. Rather than simply working with the socket he pulled in some spring library that altered the socket behavior according to an external XML file and was praised by the lead for doing it this way. The code (java + XML) was several times longer than it would have been otherwise, plus a new library had to be included in the build/distribution, but it was still 'proper'. I think that was the breaking point for me working on that project.

Keep in mind that there was no 'original path' in christianity, it began as a highly fractured system and never really fully centralized.

To be fair, quite a few religions grew out of not being controlled, so they can also be a counter to such structures.

I do not see this topic brought up nearly as much, which worries me. I have worked on quite a few projects where the unwillingness to write functionality internally lead to excessive testing of external options and overuse of generic frameworks which not only increased the dependency/complexity of the project but often required just as many lines of code to use as just writing our own damn module would have.

It feels like this is worst in the Java (enterprise) community, but that could be my imagination. Sometimes I think those programmers need their 3rd party instantiation taken away from them....

And crap, looks like I have been moved over to slashdot-beta so I will probably never see if I get responses....

What does being in the computer industry for 20 years have to do with knowing the history of CS? Very few CS programs have any coursework on history, and it is not a topic that is highly covered in industry. Working in tech might give one a default knowledge of products and technologies developed during their time in industry, but even that is going to be limited to a person's specific subdomain unless they are actually independently interested in learning deeper history.