einarvalur.co

Problem-solution Advertisement

There is this thing in advertisement called "problem-solution advertisement"

advertisement that focuses on a consumer problem and offers a solution to the problem. For example, a problem-solution advertisement for a sunburn relief product will remind consumers of the problem of sunburn pain and promote its product as offering a fast, safe, and soothing solution to this pain. Product-solution advertisements are most effectively used when the consumer can readily identify with a problem, and when the solution to this problem is easily solved by purchasing the product -- www.allbusiness.com

Once you see it, you can't unsee it. It is everywhere.

The Problem

In a sense it makes total sense. Is your problem is hunger?, well this sandwich company has food, just come down and buy some. Is your problem hunger and laziness, well this pizza company has food and home delivery. Problem solved.

So at it's core it just explaining to you that you have a problem and then offer a solution to your problem.

Where it gets really interesting is when you are presented with a problem that you didn't know you had. This happens all the time in the supplements and vitamin industry: "You might not know this, but your gut bacteria is out of balance, it so happen that we have a remedy that might correct it".

The Solution

Github have introduced the GitHub Super Linter

From the press release:

Setting up a new repository with all the right linters for the different types of code can be time consuming and tedious. So many tools and configurations to choose from and often more than one linter is needed to cover all the languages used.

This stated the problem

The GitHub Super Linter was built out of necessity by the GitHub Services DevOps Engineering team to maintain consistency in our documentation and code while making communication and collaboration across the company a more productive experience. Now we are open sourcing that so everyone can use and improve it!

...And this stated the solution.

To be hones, I didn't know that I had this problem. I work in a company with 500 or so developers and we start new sub-system or project all the time. We really haven't had this problem. Each language we use has it's own quirks and rules regarding linting and formatting. Every time we start a new project we will usually use existing linting rules, something from a previous project. We might tweak it a little bit and bingo, we are off to the races.

It got me wondering, -"Am I spending to much time setting up my linter and the linting pipeline?". Every time we spin up a new project, we set up a build pipeline. This includes a Docker that can run the unit-test, the linting rules and the continues integration. We call this Iteration zero and we usually give us 2-3 days for a pair of developers to get it up and running. There is a lot that goes into this. Setting up configuration, pulling down passwords (for this we use AWS Key Management Service), building and running Dockers (for this we use Buildkite). If the build is successful, we create a backed container that can be deployed to production and so on and so forth.

Actually setting up the linter only takes a few hours. But let's say that it takes 1.5 days or 10.5 hours. Now let's say that the system is in active development for 4 years.

Let's start with the days in one year, subtract weekends. To account for some holidays, let's subtract additional 10 days. Now let's say that it's being worked on 5 hours a day. Lastly let's multiply this by 4 years. 

(365 - (52*2) - 10) * 3 = 1004 hours

How big of a part it the 10.5 hour setup time one might think?

(10.5/1004) * 100 = 1.046%

While this is still 1%, we can safely say that setting up a linter is not a bit part of running and maintaining production code.

Since linting is not really a bit part of code development. What problem is GitHub Super Linter solving, and do I have this problem?

...or is it a problem?

Again from the press release:

  1. Prevent broken code from being uploaded to master branches
  2. Help establish coding best practices across multiple languages
  3. Build guidelines for code layout and format
  4. Automate the process to help streamline code reviews
  5. With these basic criteria, we should be shipping better, cleaner, and more stable code internally and to our customers and partners

I have a few ideas on these points

  1. Because deployment pipelines usually run unit-tests as well as linting tests, very seldom does broken code end up in the master branch
  2. While a company might adopt a system-wide rules and guidelines regarding code, often times a small team might have good reasons to adopt their own. Just as long as all the code in a given repository is consistent, it is OK for different repositories to be inconsistent between them. Different languages often have different conversions. Python is usually snake_case, while others are CamelCase.
  3. I think point 3. is just the same as 2. with different wording
  4. This could be a good point. The counter-argument would be that having a linter running on your development machine, tied to your IDE should eliminate this problem all together. It seems that you can run it locally through a docker container locally, but is it simpler to just buy VisualStudio when the linter shows up as a new feature in that IDE?
  5. Every developer and every software company makes this their priority. While GitHub Super Linter does solve this problem, so does many, many, many other tools as well.

There is no such thing as a "free lunch", so why would Github put time and effort into this? Github is owned by MicroSoft:

"Embrace, extend, and extinguish" (EEE), also known as "embrace, extend, and exterminate", is a phrase that the U.S. Department of Justice found was used internally by Microsoft to describe its strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences in order to strongly disadvantage its competitors.

Could this be the reason? While the code itself is open-source it seems to integrate quite heavily into the GitHub ego-system, namely: The Super-Linter has CI/CT/CD configured utilizing GitHub Actions.

Could it be that tying your code to this linter also ties you into the GitHub supplementary products?

Is there any derived data that Github could utilize and sell? Is there value in knowing which languages have hight or low linting errors... maybe over time or in a given region?

So, while having another linting tool in the developer's toolbox couldn't be a bad thing, I guess everyone should ask them selfs:

Do I really have this problem, and if so, is this product really gonna solve it?