Software Infrastructure 2.0: A Wishlist (2021) • Hacker News Board

Re: Software Infrastructure 2.0: A Wishlist (2021)

#81

Post by crabbone » Thu, Feb 29, 2024, 3:41 PM UTC

Kon-Peki wrote: post #41

crabbone wrote: post #35

Earlier quoted context omitted.

I want to expand on this :) When I have to describe to people who don't work with me my interactions with developers (especially of the crappy code like that) from a standpoint of someone who represents the QA side of things... I describe to them my interactions with my five y.o. son: Me: How as school? Son: Goooood! Me: Did you behave? Son: Yes! Me: Did the teacher send you into timeout? Son: Yes... Me: So how come?…

Not knowing anything other than what you wrote, it sounds like your organization has leadership problems. People don't know why their job exists, they don't know what your organization is actually trying to accomplish, how any individual person fits into it, why the day-to-day things someone does helps, etc. Nothing anyone does with software will help.

Yeah, but the most disappointing part is that you cannot say it out loud. Even acknowledging the problem will have all the swords pointing at you. So, everyone quietly hates their pointless tasks, but completes them somehow anyways. And things only get worse :) But, there's no reality check because there's no competition and hasn't been for such a long time that users are essentially led to believe that what they are getting is the best they can get.

Re: Software Infrastructure 2.0: A Wishlist (2021)

#82

Post by crabbone » Thu, Feb 29, 2024, 3:46 PM UTC

pdimitar wrote: post #77

crabbone wrote: post #35

Earlier quoted context omitted.

I want to expand on this :) When I have to describe to people who don't work with me my interactions with developers (especially of the crappy code like that) from a standpoint of someone who represents the QA side of things... I describe to them my interactions with my five y.o. son: Me: How as school? Son: Goooood! Me: Did you behave? Son: Yes! Me: Did the teacher send you into timeout? Son: Yes... Me: So how come?…

> And, my guess is that the reason for it is that nobody really wants to work too hard. There is certainly a lot of that but it gets even worse: you get actively punished for doing good work in many companies: you end up making other people work like asking managers around for product requirements (that are of course barely written somewhere, if at all) or reminding that sysadmin that they half-arsed the job of the d…

Haha. Yeah. I almost got fired in my first month because I asked another developer something I thought was really innocent: they mixed some code from pytest with unittest (two competing Python unit-testing libraries) where either one or the other could do the job perfectly fine. So, I naturally asked why'd they do it. Not even being mean. They, of course, interpreted this as me being snarky... complained to the management, and I had to look for another department to house me.

Now I write "sorry" and "excuse me" when I get assigned to review someone's code and I mostly fix typos in the comments. But, even so, I don't get assigned to code reviews all that often :)

Re: Software Infrastructure 2.0: A Wishlist (2021)

#83

Post by crabbone » Thu, Feb 29, 2024, 4:02 PM UTC

pdimitar wrote: post #78

crabbone wrote: post #30

If I didn't know better, I'd think I'm reading one of those cheesy LinkedIn advertorials... To someone who dedicated their professional life to infrastructure all of these wishes read mostly irrelevant, with a strong proprietary advertising flavor. At every turn of a sentence I expected to find a mention of some commercial product this article was going to promote. Well, at least it doesn't seem to do that, not openl…

> Well... yeah, sure, why not... but it's not very important. Lots of other goals will overshadow this one. For you. For me having to tinker with a repo full of YAML files just to have a Kafka topic provisioned (like it just happened to me this week) can and has killed motivation to the point of not working at all after, for a day or two. This stuff should be blindingly obvious, to the point a trained monkey should b…

> For you. For me having to tinker with a repo full of YAML files just to have a Kafka topic provisioned

This is understandable, but this isn't about speed. Many YAML files may result in high provisioning speed or low provisioning speed, after all they only give instructions to the program doing the provisioning.

You could legitimately complain about choice of YAML as a platform for infrastructure configuration so several reasons, like:

1. Not having a built-in ability to describe templates. Lots of infrastructure wants to have some sort of polymorphic configuration, and when the infra developers chose YAML to configure it, they didn't account for that. So, instead they use various template engines that strap on this polymorphism on YAML. This was also indirectly mentioned by OP.

2. Poorly structured, especially when it comes to large configuration size. It's easy to accidentally write something you didn't intend. It's hard to search.

3. Being JSON in disguise, it inherits a lot of problems from JSON. Marshaling richer type / structure of data in and out of the program is severely impacted by the primitive and inflexible type system of the format.

But, again, this isn't speed. This is just a different set of problems.

> If I were a CTO or an IT manager I'd be very worried about stuff like this.

Practice shows this is mostly irrelevant. It's hard to reach the point where provisioning speed starts to hurt so much it impacts business decisions. For instance, provisioning in MS Azure is on average twice as slow as it is in AWS. (And deprovisioning is probably four times as slow.) And nobody cares. So many other concerns will overshadow this particular aspect, that you'd feel uncomfortable to even bring it up, if you had to choose between two service providers. Primary driver is cost of running the infrastructure for a long time, overall as a system. Starting time does contribute to the total, but unless your business requires very frequent allocation and deallocation of resources, this won't make a difference. Also, cloud vendors don't bill you for the time that the infrastructure is being brought up, so, it's really hard to make a compelling case to choose the fast-to-provision infra over the slow one just based on that aspect alone.

Re: Software Infrastructure 2.0: A Wishlist (2021)

#84

Post by pdimitar » Thu, Feb 29, 2024, 5:03 PM UTC

crabbone wrote: post #83

pdimitar wrote: post #78

Earlier quoted context omitted.

> Well... yeah, sure, why not... but it's not very important. Lots of other goals will overshadow this one. For you. For me having to tinker with a repo full of YAML files just to have a Kafka topic provisioned (like it just happened to me this week) can and has killed motivation to the point of not working at all after, for a day or two. This stuff should be blindingly obvious, to the point a trained monkey should b…

> For you. For me having to tinker with a repo full of YAML files just to have a Kafka topic provisioned This is understandable, but this isn't about speed . Many YAML files may result in high provisioning speed or low provisioning speed, after all they only give instructions to the program doing the provisioning. You could legitimately complain about choice of YAML as a platform for infrastructure configuration so s…

> Practice shows this is mostly irrelevant.

I'd dispute this, though I don't have data. To me the problem of people just phoning it in and collecting FAANG salaries is pretty nasty and seems like it's not solvable.

But yes, I do agree that if the economic analysis SEEMS TO point at the idea that X times 3 effort for provisioning is irrelevant to the bigger bottom line then yes, it seems that the need for action does not exist.

Re: Software Infrastructure 2.0: A Wishlist (2021)

#85

Post by pdimitar » Thu, Feb 29, 2024, 5:04 PM UTC

crabbone wrote: post #82

pdimitar wrote: post #77

Earlier quoted context omitted.

> And, my guess is that the reason for it is that nobody really wants to work too hard. There is certainly a lot of that but it gets even worse: you get actively punished for doing good work in many companies: you end up making other people work like asking managers around for product requirements (that are of course barely written somewhere, if at all) or reminding that sysadmin that they half-arsed the job of the d…

Haha. Yeah. I almost got fired in my first month because I asked another developer something I thought was really innocent: they mixed some code from pytest with unittest (two competing Python unit-testing libraries) where either one or the other could do the job perfectly fine. So, I naturally asked why'd they do it. Not even being mean. They, of course, interpreted this as me being snarky... complained to the manag…

Yep, had several similar such occurrences and my mind is boggled every time. I personally welcome any opportunity to learn and improve, but many people apparently don't.