51–60 of 72 posts
9. Does your Infrastructure as Code live alongside the service it hosts? No, the IaC is configuration, and configuration should be separated from the application. in organizations that implemented GitOps, the IaC files in git are not only a copy of the configuration, it is the source of truth from which the configuration is copied to the systems. Unless all the developers who can commit code should have permission to…
Earlier quoted context omitted.
I like to imagine it as a sort of volume vs surface area problem. The amount of service you can deliver to costumers is your surface area, but the amount of work you put in only contributes to the volume. As the number of employees grow you will necessarily be less efficient, but there aren’t really any other great ways to gain the required surface area.
there are perhaps interesting options with bringing in partner-level labor instead of buying someone's time-in-seat and the relative personal investment involved in each the big point glossed over is that wage labor, where the value they produce is taken from them, isn't a great incentive for great work. that's imo a far bigger issue than fundamental challenges with collaborating, and why so many managers need to con…
Earlier quoted context omitted.
I like to imagine it as a sort of volume vs surface area problem. The amount of service you can deliver to costumers is your surface area, but the amount of work you put in only contributes to the volume. As the number of employees grow you will necessarily be less efficient, but there aren’t really any other great ways to gain the required surface area.
there are perhaps interesting options with bringing in partner-level labor instead of buying someone's time-in-seat and the relative personal investment involved in each the big point glossed over is that wage labor, where the value they produce is taken from them, isn't a great incentive for great work. that's imo a far bigger issue than fundamental challenges with collaborating, and why so many managers need to con…
Collaborative efforts to maximize good results, and predictable gains for each participators.
7. 7! This is by far the one that resonates with me the most. But for some reasons SREs think the opposite is true: the longest it takes to get to prod, the better. What a pain.
I'm an SRE and currently on a mission to get code into prod as fast and safely as possible. Instead of painting such a broad, generic negative picture, maybe articulate an actual position to argue against.
Extremely web centric list. Any other development (mobile, desktop, games, embedded, …) will find a lot of these steps very weird.
The whole idea of "Continuous Delivery" is not always one that meshes well with some shrink-wrap workflows. I worked for hardware manufacturers, for most of my career, and software was always just a "sidekick" to The Main Show. We just got the "Supporting Actor" nods. I'd say that 90% of HN seems to be Web/SaaS (and, these days, crypto), which is an excellent workflow; just not the one I do. Nowadays, I have some int…
Which is an enormous, catastrophic, fantastic mistake that should be leaving everyone breathless with shock.
Realising that the software matters is why Tesla is worth more than most of the other car manufacturers combined.
This is why Apple is the #1 biggest company in the world.
This is why every time some "hardware" has to be deployed, every enterprise admin rolls their eyes and groans.
This is why IoT, medical, and factory automation security is a trash fire.
Smart televisions aren't, and you can waste $5000 on one just to have a substantially better experience by plugging in a $150 box from Apple.
And on, and on, and on...
I literally told the local Toyota rep that I wouldn't buy a 2019 model-year vehicle specifically because it didn't have Apple CarPlay. The built-in system is simply garbage. Maps that are 4+ years out of date!
Apple has nearly monthly updates for iOS, which means if I plug my phone into my car, effectively my car gets monthly updates. With Toyota? Maybe once in a decade they'll release an update, and then never again, slowly but surely deprecating its software capabilities down to "worthless".
Similarly, Nikon releases updates for their existing cameras once in a blue moon. Recently they announced "Firmware 2.0" for their flagship Z9, and I was shocked. This is likely a one-time aberration, probably caused by their software division not being ready in time for the initial shipments. I guarantee that there will never be a Firmware 3.0. Never! Where I live, this camera with one lens and typical accessories will set you back $10K and is deprecating at an exponential rate because Nikon does not give a s%*t about software. Meanwhile my iPhone and its camera will keep getting updates.
So yes, CI/CD is a web-centric notion.
It ought not to be.
Earlier quoted context omitted.
The whole idea of "Continuous Delivery" is not always one that meshes well with some shrink-wrap workflows. I worked for hardware manufacturers, for most of my career, and software was always just a "sidekick" to The Main Show. We just got the "Supporting Actor" nods. I'd say that 90% of HN seems to be Web/SaaS (and, these days, crypto), which is an excellent workflow; just not the one I do. Nowadays, I have some int…
> I worked for hardware manufacturers, for most of my career, and software was always just a "sidekick" to The Main Show. Which is an enormous, catastrophic, fantastic mistake that should be leaving everyone breathless with shock. Realising that the software matters is why Tesla is worth more than most of the other car manufacturers combined . This is why Apple is the #1 biggest company in the world. This is why ever…
They likely have huge batteries of tests that the software needs to pass (CI), but the actual release build and “sign-off” involves a human.
Who will get their ass chewed off, if the update borks.
But everything before that point, is 1000% better and more agile than most hardware companies.
I’ll bet SpaceX has a lot more meatware in their process.
I always liked CI, as a basic infrastructure, for my team. I very much believe in early integration testing[0], but automated testing can be a trap. It should not be the only testing, for firmware.
If you push a bad release to a Web server, you have one point of failure, but also, one point of recovery.
If you push out a bad firmware release, you have a million $10K bricks. You may also have fires, explosions, and crashes.
Although I often had real disagreements with the hardware folks, I am entirely sympathetic to their priorities.
The main issue, was that they considered software developers to be “cowboys,” and judging from the general quality level of even enterprise software, I can understand their bias.
However, I am not a “cowboy.” I am absolutely anal about Quality, and I’m regularly attacked as being “too uptight,” by software developers.
Software is a different animal from hardware, and needs to be done differently. Quality, however, should not suffer.
As a standalone developer, I’ve learned to eliminate “concrete galoshes”[1], and CI tends to be that, but only in my case. What works for me, may not work for others. Just as importantly, what works for others, may not work for me.
I’ve spent the last few years, refining a personal process for my software development. It works great. You can see for yourself. Most of my work is open-source, or source-available[2].
[0] https://littlegreenviper.com/miscellany/testing-harness-vs-u...
[1] https://littlegreenviper.com/miscellany/concrete-galoshes/
Earlier quoted context omitted.
there are perhaps interesting options with bringing in partner-level labor instead of buying someone's time-in-seat and the relative personal investment involved in each the big point glossed over is that wage labor, where the value they produce is taken from them, isn't a great incentive for great work. that's imo a far bigger issue than fundamental challenges with collaborating, and why so many managers need to con…
I have been thinking about _how_ to build good (and stable) software a lot in last 10 years. Tried many approaches and verified them one by one. In my experience this is the ultimate fix. It may not work for big tech companies, but for most projects, it is much better to choose this approach. Collaborative efforts to maximize good results, and predictable gains for each participators.
Btw you may find Graber/Wengrow's recent Dawn of Everything to be an inspiration for how these sort of structures could scale up to larger groups of people than conventionally thought historically possible
Earlier quoted context omitted.
> I worked for hardware manufacturers, for most of my career, and software was always just a "sidekick" to The Main Show. Which is an enormous, catastrophic, fantastic mistake that should be leaving everyone breathless with shock. Realising that the software matters is why Tesla is worth more than most of the other car manufacturers combined . This is why Apple is the #1 biggest company in the world. This is why ever…
Well, hardware is a different world from software. I’ll bet that Tesla doesn’t do “sight unseen” updates. They probably wouldn’t be allowed to. They likely have huge batteries of tests that the software needs to pass (CI), but the actual release build and “sign-off” involves a human. Who will get their ass chewed off, if the update borks. But everything before that point, is 1000% better and more agile than most hard…
> 11. Do you include ticket IDs in your commits or branches? This is one of the things that sound 'good' on the surface and are totally worthless in practice (especially when practicing minimal commits). In the wild this devolves into a meaningless umbrella issue (Deliver Feature Foo) or 1 liner issues that sometimes did not even match the pr contents. Just use the commit message and in pr review enforce commit messa…
Earlier quoted context omitted.
> I worked for hardware manufacturers, for most of my career, and software was always just a "sidekick" to The Main Show. Which is an enormous, catastrophic, fantastic mistake that should be leaving everyone breathless with shock. Realising that the software matters is why Tesla is worth more than most of the other car manufacturers combined . This is why Apple is the #1 biggest company in the world. This is why ever…
Well, hardware is a different world from software. I’ll bet that Tesla doesn’t do “sight unseen” updates. They probably wouldn’t be allowed to. They likely have huge batteries of tests that the software needs to pass (CI), but the actual release build and “sign-off” involves a human. Who will get their ass chewed off, if the update borks. But everything before that point, is 1000% better and more agile than most hard…
For the people who are downvoting me, you do all realise that I'm not comparing a pure-software website to some embedded IoT thing, right?
Most of my examples are hardware with software as "necessary evil" vs hardware with software "being taken seriously."
Apple TV is a hardware appliance that takes the software seriously.
My Samsung "flagship" TV is a hardware appliance that does not.
They both get updates. One gets frequent updates that makes the product noticeably better. The other gets infrequent updates that have made it worse.
Cars from most manufacturers are hardware with trash software.
Tesla sell the cars, but unlike their competition their cars are regularly updated with new software. They have weekly(fortnightly?) updates rolled out to their for their beta testers! Not exactly daily CI/CD, but compare this to Toyota. They literally never release updates for most models, ever. And it's not like their 1.0 release is perfect! Mine has a bunch of small bugs and irritations that they should have patched... but never ever will.
It's not a question of "alternate process" or a "different workflow". They have no process! Their release strategy is "don't"!
Apple is about to release a complete car software + hardware suite. So not something you plug in, but the entire "avionics" as it were will come as a OEM part from Apple instead of the car manufacturer.
They're going to wipe the floor with their competition. The screens and software from GM, Ford, Audi, BMW have nowhere near the quality, commitment to updates, backporting of new features, etc, etc...
I will literally stand in line outside of the dealer to get a new car that has this style of Apple-made hardware+software instead of a lump of metal with paint on it and fabric on the inside.
Because I know it will get updates, and that those updates won't make things worse.