What you're missing is maintenance, security, scaling, and protection from data loss.
Bespoke CI is easy to build but no one wants to be in charge of rolling out a critical security patch to that on-prem box no one's touched since that consultant from 2 years ago.
Your CI has to be fully codified, stateless and possible to redeploy with a single command. That's the only way it can remain sustainable. No persistent hidden state, no manual configs (even as an option!) and automatically rebuilt on every release as the new version is deployed.
As a really big bonus, that also makes your CI testable.
Yes, totally agreed in theory, and it sounds like y'all built a great solution for your use case. But it takes substantial effort and discipline to do something like that at scale.
At some point, you develop complex interdependencies with other systems. You need sophisticated caching for optimum build performance. Techniques like GitOps are unsustainable at a certain number of engineers/commits per hour.
What I don't understand is why they don't have a canary update process. Server side deployments do this all the time. You would think Windows would offer that to their institutional customers, for all types of updates including (especially) 3rd party.
This isn't a Windows update (which absolutely does let you do blue/green deployments vis SUS), but rather a Crowdstrike update which also lets you stage rollouts and I expect several administrators are finding out why that is important.
I know about update policies, but afaik those are about the “agent” version. Today’s update doesn’t look like an agent version. The version my box is running was released something like a week ago.
Is there some possibility tu stage rollouts of the other stuff it seems to download?
We routinely implement phased / canary deployments in server-side systems to prevent faults from rolling out globally. How is it possible that CrowdStrike and/or Windows does not have a similar system built in for large, institutional customers? This is outrageous.
> In other words, the founder doesn't have the qualifications or characteristics that the underlings assume they need to be in a leadership position.
I find this to be an odd take, given context in the article. It sounds like the writer is simply contrasting her own leadership style with her boss's, as an example of how they complement each other.
Hierarchies make us uncomfortable because they challenge our egos. I've noticed this particularly in classic programmer personalities: smart, introverted, highly skilled.
Many of us spend our entire careers as ICs, as leaves on the corporate tree. It's easy to become cynical.
"The VP sits around chatting people up all day and droning about
OKRs while I just shipped a million dollar feature / resolved an expensive outage / built a tool
that will dramatically increase engineering efficiency. What value does _he_ bring to the table?"
Unfortunately this is an enormously unproductive attitude that will kneecap your career. No org is a meritocracy -- but what does meritocracy even mean? We sort everyone by IQ? Or "performance", measured by lines of code committed per week?
On a final note I'll add that hierarchies get things done. Imagine working for a company that functioned as a democracy, with all the attendant discourse, campaigning, checks and balances. I would personally find the inefficiency intolerable. Better to work for a single idiot than a committee of a dozen geniuses.
> It sounds like the writer is simply contrasting her own leadership style with her boss's, as an example of how they complement each other.
I agree, that's likely the author's intention.
> Unfortunately this is an enormously unproductive attitude that will kneecap your career.
You're getting to the heart of the matter, but not in the way that you think. To avoid repeating myself, I'll refer to what I wrote in another comment: https://news.ycombinator.com/item?id=36724073
> No org is a meritocracy -- but what does meritocracy even mean?
That was actually my point.
> On a final note I'll add that hierarchies get things done. Imagine working for a company that functioned as a democracy
My comment was not about how companies should be organized. That would be a misinterpretation.
This was my great frustration with Twitter the last time I tried it. Even when I carefully curated my followers, random crap would constantly sneak into my feed. It was annoying enough that I started just manually navigating to a few bookmarked profiles periodically to read their latest tweets.
This blog post reads like it's written by someone using Subversion back in 2015. Most of the justification for committing on mainline can be addressed by following other best practices:
1. Run the same suite tests additional quality checks (linters, etc) on PR branches that you run on mainline
2. Run branch CI against the merge commit for your PR branch (i.e. include your changes as well as latest mainline)
3. Avoid long-lived branches.
If you run into frequent merge conflicts and incompatible changes in an area of your codebase such that your team needs to integrate individual commits every half-hour instead of keeping 1-4 day feature branches around... That sounds like a code and/or organizational smell.
However!
> Using pull requests for code changes by your own team members is like having your family members go through an airport security checkpoint to enter your home. It’s a costly solution to a different problem.
I actually do like this analogy -- but it's not PRs that are the problem, it's mandatory reviews. And the cost/benefit of mandatory reviews varies widely depending on how senior the engineers on the team are, how much their work overlaps, and what their average tenure on the team is.
> I think we ought to consider a system where the Government or Fed provides the core functionality of “let me put $X in an account so I can use $X in the future” for free and banks compete based on value added.
One major draw of Lego is their licensing of expensive creative IP. Look at the Harry Potter, Star Wars, DC, Lord of the Rings themed sets. Smaller competitors likely can not afford the same offerings. And Lego probably has deep enough pockets to ensure exclusive deals.
There's also something to be said for having such a dominant, established brand. Lego is a cultural icon, beloved by multiple generations. Picking up a knockoff kit is sort of like taking your kid to a random local theme park instead Disney World. While in theory the two options have similar features (rides! characters running around in costume!) they are of course not the same.
> One major draw of Lego is their licensing of expensive creative IP.
This is the real genius beyond the manufacturing (which other comments are correctly praising). Lego was/is the only brand that gets to make, e.g. both Mikey Mouse and Bugs Bunny, both Marvel and DC, etc. By making Lego versions of those properties, they've convinced those enormous IP holders that this does not compete with other products; Disney can't make Lego Star Wars themselves.
Lego's corporate accomplishment is to have elevated themselves to the status of a platform. And doing so while their product isn't software or hardware is pretty unique.
You know the old saying "familiarity breeds contempt"? I believe the opposite is true as well. People who don't code think coding is typing. People who don't manage think it is as simple as forwarding emails from executives to subordinates.
I myself have often wondered if what doctors do couldn't be automated. You have the primary care physicians who seem to run on a loop of "listen to symptoms" - "order tests" - "prescribe medication" - "refer to specialist". And the specialists themselves seem to follow their own loops. Many surgeons for example, perform the exact same procedure day in/day out for decades. Surely well-trained robots, not prone to fatigue or loss of dexterity as they age, could produce superior outcomes.
But they haven't been replaced yet, just like I haven't, so I assume there is more going on there than what looks from the outside like repetitive manual labor.
Bespoke CI is easy to build but no one wants to be in charge of rolling out a critical security patch to that on-prem box no one's touched since that consultant from 2 years ago.