
Self-Protecting Projects - amihaiemil
https://amihaiemil.com/2020/01/17/self-protecting-projects.html
======
blowski
I find it strange that senior developers would laugh at the idea of using
quality control gates in a CI/CD pipeline. I know a lot of people don't bother
with these things, but most seniors I've worked with would at least aspire to
(or say they aspire to) using such techniques.

But I guess that's the difference between a senior who knows lots of syntax,
and a senior that that knows how to deliver quality.

~~~
davedx
Senior here, 20 years experience, started out with C++ projects where the only
quality gate was the build server failing and currently working on a project
where commits fail because of lint rules including things like imports being
alphabetized.

IME the best approach is a "balanced" one. Let devs push their branches from
local to the repo without passing tests or lint rules. (e.g. git push --no-
verify). Try and keep your tests _fast_ so devs _want_ to run them locally.
(Carrot, not stick). But prevent a merge request from being merged to your
trunk branch until everything is green.

Personally I find "linters" horrible. They're like someone with OCD leaning
over your shoulder while you code. I think VS Code actually runs a LOT slower
when the linter is integrated, which can do more harm than good. How crazy is
it that TypeScript can do all its advanced type checking faster than the
linter?

~~~
userbinator
In my experience, any project with excessive automation and such rules quickly
turns into a game of "find how to pass the checks" and you spend the majority
of the time fighting the bureaucracy rather than doing useful work.

~~~
blowski
If your devs don't care about the quality of code they deliver, they'll find a
way to deliver whatever crap they've built - even if it takes longer to find a
workaround than just write some good code.

CI/CD should not be used to force developers to do things they don't want to
do, but to automate some easily repeatable tasks they would still do anyway.

------
clktmr
Wherever I worked, these kind of checks did always more harm than good. You
force a bunch of tools on your developers which they hate, only to have your
whole codebase littered with "disable linter X" comments. In a good review
process the developers can negotiate the conventions by themselves, which
leads to acceptance among the team.

~~~
amihaiemil
In one of the teams I best worked with, payment was done per closed task.
There were no salaries. Just bounties per closed tasks.

If you didn't respect the Quality Gates, your branch wouldn't be merged => you
wouldn't be paid.

It was one of the best experiences in my work life so far. Clear rules, no
chaos, no meetings, no negotiation. Just tasks and money :)

~~~
tomashubelbauer
I can think of a few ways of how this could backfire / be gamed or abused, but
all in all, seeing how everything else is just as susceptible to abuse and
gaming, it still sounds awesome to me.

~~~
cosmodisk
This sounds identical to the agency I was reading about.They pay devs for
closed tasks. I.e.: a class needs to written that does x. The reward is $100.A
senior dev will do it half an hour, while a junior will spend a few
hours,which bases work-reward process self balancing based on experience.The
owner of the shop had some very detailed blog posts on this,which attracted
tons of discussions.Shame I can't recall the guy's name..

~~~
amihaiemil
I think you're talking about
[https://www.yegor256.com/](https://www.yegor256.com/)

It was fun work back in the day of Teamed.io. But nowadays, with Zerocracy,
it's turned a bit too strange even for my taste, after having worked about 2
years with Teamed.

~~~
cosmodisk
Yes, that's the one! Will need to get on his blog at some point, he's got some
unorthodox,yet interesting ideas.

------
overlordalex
Nice article - one nitpick is that I absolutely do /not/ make the checks
mandatory as part of the build process. Rather there are some "opinionated"
checks that are run when code is pushed for review (which can be skipped), and
then strong checks run as the first step in the CI/CD pipelines. This means
that the tools stay out of the way when developing and running locally, but
still enforce standards where required. This leads to fewer developers
disabling or @ignore-ing rules to test things locally and then forgetting to
remove them.

This article also reminds me of a talk I saw from Neal Ford about
architectural fitness functions: the idea being that if there is an
architectural pattern that should be followed then the best place to put it is
in an automated step as part of your CI/CD. I thought it was interesting to
take the concept normally limited to linters and apply it to a more abstract
principle

~~~
eru
I agree. Curiously, the authors of the Go language disagree.

~~~
SAI_Peregrinus
I think it depends on the check. Some checks are better enforced strictly in
an automated fashion. Style rules are a good example: they make no performance
difference, lead to bikeshedding, and are pretty much arbitrary. Other checks
should be made automatically but not strictly enforced. EG you might want to
require all C casts to have a comment describing why it's safe. That can be a
good linter warning, and linters tend to have codes that can be added in
comments to suppress the warning. So the linter warning can make code review
easier, but shouldn't necessarily fail the build.

~~~
eru
Go fails the build, when you have an unused variable.

------
peterkelly
Great, so now I have 100,000 duplicate bug reports to sort through because I
forgot a null check and the logger automatically created an issue each time
that error occurred (with different timestamps, causing duplicate detection to
fail).

~~~
amihaiemil
The duplication Issue can be solved in many ways.

First one that comes to mind is, the Issue Tracker should have a limit on the
number of tickets a certain User can open.

If the Issue Tracker doesn't have that, then the company can have a firewall
rule to only allow a certain number of calls per day to the API.

I'm sure there are dozens of other possible scenarios :)

~~~
fapjacks
So not only do you fill the issue tracker with ten thousand duplicate issues,
but now you are blind to issues numbered #10000 or higher.

------
fapjacks
This sounds nice on the surface, good intent. But it smacks of inexperience
and is the same mechanism that ends up pushing the kinds of dumb conventions
that insist on golang's Trailing Comma. What is the expected outcome of your
rule, and how do you expect additional, incremental bureaucracy to drive that
outcome? Any time you push rules, you must expect that people will default to
simply obeying the rule without questioning _why_ the rule exists in the first
place. This is just a natural cost-minimizing function of human beings. As a
former console operator of a decades-old mainframe, let me warn you that this
is how informal "operator manuals" end up spanning many three-ring binders
filled with nonsensical, sometimes contradictory trivia, and how you end up
with people going through the motions like some kind of ritual whose origins
are lost in the mists of time.

If you're going to do something like this, I suggest that these kinds of "code
quality gateways" aren't as absolute as OP recommends. Be smart about it: You
could probably measure how "sloppy" a developer is (relative to some mean of
their own output and _not_ compared to the team or really anyone else). Simply
bringing it to a developer's attention (programmatically) will do far more for
your project's code quality than trying to dumbly enforce some list of code
conventions about whitespace or whatever. Also, this is a kind of tool that
should absolutely be scoped strictly on the level of the individual developer,
with no possibility of having externally-visible reports generated from it,
and _absolutely not_ exposed to management. You don't want to give management
too many knobs to turn, _especially_ knobs like this.

------
kkapelon
>Writing about this now, I got an idea: we should have some sort of plugin for
Log4J or slf4J: a plugin that would automatically open tickets on Github or
other trackers, when the .error(...) method is called

Great idea in theory. It will not fly in practice. If you tell to any
enterprise company that your (or their) software is automatically doing this
behind the scenes, the project will be shot down.

I mean, getting crash metrics is one thing, but opening automated issues from
_enterprise_ software is a completely different manner.

~~~
TYPE_FASTER
I like the approach Visual Studio App Center (and probably others) takes of
aggregating crash reports so you can easily figure out which issues are
impacting the most users and prioritize.

------
cerberusss
Author, I'm a sucker for spelling. (edit: removed).

Good blog post. When I was programming Java, I also used Checkstyle. It's a
long-running and reliable project.

~~~
amihaiemil
Thanks for the comment. I am a sucker for spelling indeed. I usually spend
about 1h after publishing each post, to fix typos (I never notice them until
it's published, no matter how hard I try).

~~~
blowski
I find when I write, the free
[http://hemingwayapp.com](http://hemingwayapp.com) website is really useful
for fixing basic spelling, punctuation and grammar errors.

~~~
amihaiemil
Thank you. I know about these apps, especially Grammarly. I just don't like
the idea that all I write goes to a server somewhere :)

I also noticed Grammarly sticking its nose in places it shouldn't have. Like
private repos on Github.

~~~
Sean1708
Why not use a local spell checker instead?

~~~
amihaiemil
The ones that IDE provide? Those are rather primitive, don't you think?

~~~
Sean1708
They would still catch all the incorrect spellings, they just wouldn't catch
the incorrect grammar. The grammar of the post is fine, though, so that
wouldn't matter too much.

You could even just copy and paste it into a word processor, if you also want
to catch grammar issues.

------
alessioalex
Weird. Everybody that I know seems to be using ESLint in some way or another,
which has rules for whatever you can think of.

