Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How boring should your team's codebases be

blog.meadsteve.dev

Post reply on HN
Print view View original

171–180 of 235 posts

Re: How boring should your team's codebases be

#171

Post by hedora »

skeeter2020 wrote: post #115
osigurdson wrote: post #103

Earlier quoted context omitted.

>> deployed to over 2000 locations Were there 2000 independent systems / SQL server instances running or just one? 2K separate deployments to manage (with 1K users each), does sound a little scary. Of course, perhaps that is not what is going on at all.

Which is actually kinda funny, because some of the "complex" technology the OP is railing against allows us today to manage thousands of databases both easily and efficiently... IF the systems are built with a more current approach. This is why I try to understand ALL of the motivations for disruptive change and not immediately assume incompetence and self-interest bordering on criminal.

Option one:

Write a cloud formation / terraform template that involves O(1) machines and deploy 2000 identical copies.

Option two:

Write a template that deploys O(N = 2000) interdependent services across roughly 3-10x as many machines, and deploy one copy.

From what I can tell, you are arguing for option 2. It is strictly worse than option one. In addition to being more complex, it has a few nines less reliability, and costs 3-10x more for the hardware. The dev and CI hardware budgets is going to be 10x more because you can't test it on one machine, and it has bugs that only manifest at scale.

Source: I do this for a living, and have been on both sides of this fence. Option 1 typically has 5-6 nines (measured in chance a given customer sees a 10 second outage), option 2 never gets past 3-4 nines (measured in at least N% of customers are not seeing an outage).

The modern vs old technology debate has nothing to do with this tradeoff. If you want, you can build option 2 with EJB + CORBA on an IBM mainframe, and option 1 with rust and json on an exokernel FAAS.

Re: How boring should your team's codebases be

#172

Post by tchaffee »

pkrumins wrote: post #164
meadsteve wrote: post #130

Earlier quoted context omitted.

The excitement comes when security issues are discovered in no longer maintained code

There are no security issues.

That's a laughable claim.

https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

And just 10 days ago:

Code security company SonarSource today published details on a severe vulnerability impacting Packagist, which could have been abused to mount supply chain attacks targeting the PHP community.

https://www.securityweek.com/critical-packagist-vulnerabilit...

And this source says PHP is the 2nd most vulnerable server-side language in the world.

https://www.thewebmonkeyonline.com/php-security-issues-you-n...

Re: How boring should your team's codebases be

#173

Post by marcosdumay »

throwawaymaths wrote: post #152
malyk wrote: post #126

Earlier quoted context omitted.

I agree 100% with your first comment. The best developers care about the impact their work has above all else. Sure, they might prefer Ruby, or Golang, or whatever, but at the end of the day the results are what they are after. However, somehow we’ve created a world where the tools and techniques matter more than the output. I have no idea why this is, but I see it every day where engineers want to refactor code and…

It's also wrong to say that tools don't matter. If you say try to shove async and multiprocessing python into a system because python is boring and tools don't matter you are going to get absolutely fucked in terms of maintainability. Maybe you can afford that (and many startups can) but there's going to be a lot of survivorship bias that is sourced from non-technical things like "founder had connections" that are no…

This.

In my experience, people that insist in never adding new things can only afford to do that because they push all of the flashy problems their "boring" options create onto somebody else. And that somebody else tends to be severely underrated because they lose all their time fixing the crazy problems that come from ignoring tool selection.

But also, people that insist on novelty all the time usually can only afford to to that because they abandon their code as soon as the complexity of joining all new pieces together starts to appear. Usually leaving it for somebody else to deal with.

As a rule, developers that always choose X, for almost any X create many more problems than they solve. But they do make great strawmen to fight against in HN comments. As soon as you see people equating them to the technique, you can know the comment is worthless.

Re: How boring should your team's codebases be

#174

Post by barrucadu »

skeeter2020 wrote: post #118
jiggawatts wrote: post #32

Earlier quoted context omitted.

Fantastically . The new one had "hand rolled cryptography", which should make you twitch uncontrollably if you know anything about security. The new application had, among other failings, hard-coded (unchangeable!) RSA keys used for communication channels. As in, all customers shared the same keys. I can't remember the exact specifics, but I swear at some point there was something like encrypted JSON in XML. Or was i…

> The old app that I wrote would happily take JavaScript or SQL snippets as inputs to any text field and do The Right Thing. I can't be the only one here who is both skeptical and a little turned off by someone who says "You can stick any user input into a database query and you'll be fine", with a condesending pat on my head. Your comments continue to be incredibly one-sided and biased. The summary is "My work was p…

That's what parameterised queries are for. SQL injection isn't hard to avoid.

Re: How boring should your team's codebases be

#175

Post by listenallyall »

csa wrote: post #169
jiggawatts wrote: post #22

Earlier quoted context omitted.

> What was the reasoning provided Reasoning? Hah-ha. Haaaaa... It was an open government tender process, for which I, or the company I worked for was not eligible, despite the tender being "open". You see, a decade-long pedigree of actually having implemented the software used for this purpose did not qualify us for replacing it with a v2.0. There are rules , you see? They have to be followed! Or else. Or else bad th…

In the US, especially with federal money, this would be ample justification for a congressional inquiry and a potential fraud, waste, and abuse claim. The usual outcome of the investigation is uncovering a bunch of people just saying that they were doing what they were told to do, and no one taking the common sense approach of looking at the current vendor. It might push one or two incompetent middle managers into re…

> congressional inquiry

The only result of this would be millions more dollars "investigating" version 1, led by the bureaucrats who made the decision to build a v.2, including paying an army of consultants to find every possible flaw and non-compliant feature, in order to justify their decisions. The horns will really come out then... v.1 did not achieve 100% accessibility according to OSHA, cookies had the potential to leak data, the JS packages underneath were not vetted and compliant, no guard against denial-of-service, the list of possibilities is endless... point being, when you force gov't officials to find a flaw in something because their job is being questioned, they essentially have unlimited resources to find that flaw and justify their own existence.

Re: How boring should your team's codebases be

#176

Post by hedora »

jiggawatts wrote: post #15

Every time this topic comes up, it reminds me of a web app I wrote back around 2007 that was deployed to a over 2000 locations. I deliberately used "boring" technologies. The entire front-end used under 100 lines of JavaScript. The backend was simply SQL Server, and the queries were written in SQL instead of some ORM. The output was just HTML. No special tooling was used, no "minification" or "tree shaking", or any s…

I've seen this at startups. Management starts off informal, and promotes people that have good visibility. In the early stage, these are people that quickly churn through feature lists and deliver solid code.

Later, drunk on its own success, management continues to promote based on visibility. In a mid sized company, the most visible engineers are the ones that manage to ship broken code, then respond to nail-biter business continuity ending pages at 2AM.

At this point, the engineers that built the product and keep the lights on vest out, are passed over for promotion, and then leave.

In the next phase, the company's product stops delivering on its core competency, but hopefully it has monopoly leverage, so whatever.

Finally, the big company has a come to Jesus moment, and tries to course correct. This step is fraught with peril. It rarely works, and instead usually leads to a revolving door of process-fiddling / agile-promoting execs. This happens because execs that could solve the problem necessarily realize the root issue is middle and upper management; organizational antibodies pick up on this and isolate such threats to the staus quo.

The only execs that succeed at this point are the ones that somehow delegate 100% to low level managers and ICs while giving their peers the impression they are micromanaging and making massive organizational realignments or something.

Re: How boring should your team's codebases be

#177

Post by xcambar »

FpUser wrote: post #109
xcambar wrote: post #29

Earlier quoted context omitted.

It is also possible that this project and you being the only one handling it were analyzed as a risk. It doesn't justify how the handover/rewrite happened, but why it did is somewhat understandable, if not plain reasonable. Typically, employees with walled gardens (willingly or not) are a massive liability to their company.

>"It is also possible that this project and you being the only one handling it were analyzed as a risk" If that was indeed the case then hire a "backup" person. Way cheaper.

Absolutely.

But would you be surprised of such a decision?

Heres a proposal: As organizations grow, the size of a solution becomes imcreasingly proportional to the size of the organization rather than to the size of the problem.

Re: How boring should your team's codebases be

#178

Post by richardhod »

jiggawatts wrote: post #15

Every time this topic comes up, it reminds me of a web app I wrote back around 2007 that was deployed to a over 2000 locations. I deliberately used "boring" technologies. The entire front-end used under 100 lines of JavaScript. The backend was simply SQL Server, and the queries were written in SQL instead of some ORM. The output was just HTML. No special tooling was used, no "minification" or "tree shaking", or any s…

I think you mean: we can't have simplicity, because it doesn't sell!

Re: How boring should your team's codebases be

#179

Post by lolinder »

thow232329 wrote: post #79
sorokod wrote: post #49

Earlier quoted context omitted.

Developer can be a programmer or a software engineer ( my definitions). Programmers tend to be interested in cool new paradigms, tools, libraries, etc... Software engineers tend to be interested in delivering robust and correct features. Consequently they are more conservative. When companies hire, they should be clear what sort of developer they want. Programmer in a software engineering role will damage the code ba…

> Programmers tend to be interested in cool new paradigms, tools, libraries, etc... Yeah well guess what, a company does not care one iota about what its employees personal interests are, or what they think is cool. And it shouldn't.

This is nonsense. A company that doesn't care one iota about how its employees feel about their job ends up with high turnover, which dramatically increases costs in the long run. Good companies strike a balance between the needs of the employees, the needs of customers, and the bottom line. Any company that fails to strike that balance will lose in the long term.

Re: How boring should your team's codebases be

#180

Post by thow232329 »

lolinder wrote: post #179
thow232329 wrote: post #79

Earlier quoted context omitted.

> Programmers tend to be interested in cool new paradigms, tools, libraries, etc... Yeah well guess what, a company does not care one iota about what its employees personal interests are, or what they think is cool. And it shouldn't.

This is nonsense. A company that doesn't care one iota about how its employees feel about their job ends up with high turnover, which dramatically increases costs in the long run. Good companies strike a balance between the needs of the employees, the needs of customers, and the bottom line. Any company that fails to strike that balance will lose in the long term.

The definition of a company and its goals and motivations, is clear, and it does not have any consideration for employee amusement. That's what the christmas party and company picnic is for, and they happen outside of working hours.

If you push your own amusement as a priority at work, at the expense of the goal of the company, you literally make the working environment dysfunctional.

Post reply on HN