How to Spot Bullshit Claims in Technology

Marketing has invaded open source in a way that's extremely damaging to the future of the field. Engineering truths are becoming lost in the noise of what developers need to value in their technology choices.

Ease of use is a big claim. Anyone can claim this thing they just designed is easy. And the early adopters who saw it when the code was small and comprehensible, perhaps they now find it easy. What they fail to report is how easy it is to use in the middle of a project.

Some will claim molecularity, so you can use the pieces you choose and leave the rest. But with varied results.

Or inter-connectivity. Works easily with other software maybe. That's another use of ease. Perhaps they should replace it with setup. Ease of setup with other software. Otherwise harder, the rest of the life time of the project, than just doing it yourself.

But by far the biggest claim I see is for speed. Everything's blazing and lighting fast. No numbers, just a blaze of lighting you guys. The appeal to imagery. Or they compare themselves to their peers. Folks that have also built out platforms to solve this problem. Apples to apples, right? Well. Ultimately the apple left out is plain old code, roll your own. Which would by definition be smaller and faster than a more general purpose tool.

Security is also a big claim from frameworks. It makes intuitive sense that if a community of smart people are working on something, testing it on their own apps, depending on it as a business, the implication is security is thought about, the frameworks are often designed to protect a developer from leaving obvious doors open. So that's something you can point to as a benefit. Of course, that comes as the actual knowledge of why the framework needs to protect you fades from common knowledge and we're also given find_by_sql() for the more complex stuff. Just, fight next to it. The other, under-discussed aspect of security by open source project is a kind of abdication by the web company that they'd rather not be in the security business. Every version of every framework has shipped with security vulnerabilities in the code. That's basically the point of the "bug fixes and security improvements" section of every Change Log ever. Why is this?

Well security should be understood as a proper war time tactical situation. There's an offensive attack and there's defenses you can take. There's no perfect security, there's just the allocation of resources towards one kind of defense or another. A company can no more abdicate their responsibility to security as a soldier can not believe they're on a battlefield.

The reason there's bug fixes and security improvements, is because hackers, both white and black hat, find exploits, that is, literal lines of the code that allow for a specific kind of hack if all of these conditions are met. And these hackers are have never failed to innovate. They routinely break everything every company throws at them. When an exploit is found, it's documented secretly at first so the teams can find a way to write a fix before the exploit is made public. This is as good a system as we have so far, but it also leaves a lot of smaller companies with their asses in the wind until their development process, which might not be as efficient of on top of it as the bigger companies. Many mid-sized companies going online have web service providers or some digital agency they pay and hope everyone's doing the right thing.

This is not to say it is impossible to maintain a secure system. It's in fact very possible to be a very hard target. And it's actually going to require less code, not more. You see, every line of code, in every library and framework your app touches, is potential, I emphasize potential, way in. And the best code is no code. Less is more in security.

Coding something specific to the task, and making your knowledge domain network security fundamentals, rather than framework memorization is a superior strategy. Exploit targeting in the wild often includes sending mass requests everywhere for common signs of a particular framework or system. The most common target is still, Wordpress /wp-admin.php but every common system has these tells. If the attacker knows all the Wordpress exploits in the last year, they can try them. If any of the thousands of potentials hasn't upgraded to the absolute latest version, they're going to be hacked. They cast the net and if they get any bites, they basically know how to get in after that.

If it's specifically and hardened though simplicity there's not much room for even human error after a while. Understand your code and you'll harden it against threats. Own your code without excessive dependency and you'll be able to rewrite the slow parts. Focus on your teams gaining engineering knowledge instead of knowledge of a tool or service that's makes life "easier."

Simple vs Complex

Simple is relative but it can also be measured in comparison to something else. Marketers often talk of the underlying complexity. So here's a question. Which is simpler:

Easy is easy when you know how to do it. Easy is hard when you don't. Everything can be said to be possible, easily, once you get to know the tool. There's no way to measure it, even relative to other things. Apache configuration is literally written in XML, chosen because it looks and works similarly to HTML, and yet, it's often characterized as hard in comparison to Cloud hosting. But cloud hosting will always be measurable as more complex than the computer program Apache. Measurable in lines of code, documentation needed to cover concepts. Number of conceptual pieces of the code itself, like Classes, functions, whatever unit of code you'd like to decide.

Serving static content through Apache could be compared to the check box for static hosting in Amazon's S3 server. Which actually stands for Simple Storage Service (S3). The code needed to effectively run S3, then the code needed to route the domain name through Amazon's own platform, (not including the same code to move through the broader internet, that the Apache route would also share) to reach this S3 bucket, that somehow stores your files in a redundant way. I'd be happy to include the code for a RAID array of drives in our Apache server so we can properly compare apples to apples.

What's the complexity difference in lines of code? Files? Classes? Well here's Apache's numbers. Amazon's S3 is based on virtualization, and there's very bad data on the size of the codebase, but based on this open source attempt to recreate S3, we can assume Amazon's is at least as much as this stack needed to get the bare minimum functionality. It includes more points of failure in more hardware locations, so any individual request is more likely to fail than the Apache cluster, more latency across the board due to a larger network and everything being connected via their own network.

As to developer understanding (DU) this is more concepts to learn about before getting to a level necessary to actually use the Cloud effectively. But those concepts have little to do with the underlying, often proprietary software serving the static files and nothing to do with the open source, by definition simpler software that anyone could use to cut Amazon out of the picture. That's by design. Capitalism after all has more of an advertising budget than Collective Anarchism.

So the talent base, the schools, the blog posts, the answers to every question, over as little as 15 years can completely switch skill sets, and definitions. Doing the same thing, just differently this time. From time to time I'm sure everyone thinks about the implications of Cloud companies controlling all of the infrastructure for our free and open web and actively re-educating the new generation of developers to use something that's measurably slower and more complex than the knowledge that came before, and that those very cloud companies use and hire up to run their own actual machines.

All else being equal, more complex is always worse than less complex. If we have the same redundancy, same uptime, same bandwidth, same speed. You may save on hosting costs at first, but will make it up in development time costs for as long as you're with it.