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

91–100 of 235 posts

Re: How boring should your team's codebases be

#91

Post by listenallyall »

jiggawatts wrote: post #22
bdg wrote: post #16

Earlier quoted context omitted.

I understand the annoyance of it being replaced for a more complex more expensive system, but I would also like to know: What was the reasoning provided and what did decision makers truly believe about the whole thing?

> 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…

I think most readers, including myself, empathize with you and understand the frustration and absurdity. But you are also telling just one side of the story (yours) and I imagine that v.2.0 specs had certain requirements and features, possibly required by legislation, that needed to be followed and implemented. When you say, dismissively, There are rules, you see? They have to be followed! that's when I, and likely others, start to wonder if you are really providing the full story, or if you actually even understand the differences between your simple app and the updated version.

Re: How boring should your team's codebases be

#92

Post by nordsieck »

rTX5CMRXIfFG wrote: post #88
berkes wrote: post #69

Earlier quoted context omitted.

...and whether it will continue to do so. Maintenance over long time is hard, requires experience, architectural choices, risk analysis, balancing tradeoffs, and obviously a disciplined team.

Yes, but whether it will continue to do so, once again, has little if nothing to do with the tech stack. I think you’re getting at the point about how tech debt can bog down product development and the progress of a business, and I fully agree that it should be avoided, but tech debt avoidance is hardly related to the tech stack or programming style as much as it is to architectural decisions. And, when you’re lookin…

> I think you’re getting at the point about how tech debt can bog down product development and the progress of a business, and I fully agree that it should be avoided, but tech debt avoidance is hardly related to the tech stack or programming style as much as it is to architectural decisions.

I think all the people who are adopting Rust, who wouldn't have touched C++, would disagree with you.

Re: How boring should your team's codebases be

#93

Post by paulryanrogers »

Winsaucerer wrote: post #62
omegalulw wrote: post #54

Earlier quoted context omitted.

> The old app that I wrote would happily take JavaScript or SQL snippets as inputs to any text field and do The Right Thing. Confused here. Where were input validation checks in your implementation? How did you guard against SQL injection, etc?

Presumably they just did whatever the standard provided mechanisms for their SQL driver were (such as parameterised queries). User inputs text in a comment box, and you insert it into database using such a mechanism and it's safe. And if you're using, for example, Go's templating library, then it automatically escapes everything in HTML templates unless you explicitly override this default behaviour.

Well if it was only 100 lines of plain JS then how would one guard against reflection attacks? I.e. submitting HTML (like script tags) then getting that to render when others view the tainted data.

Re: How boring should your team's codebases be

#94

Post by geraldwhen »

jiggawatts wrote: post #22
bdg wrote: post #16

Earlier quoted context omitted.

I understand the annoyance of it being replaced for a more complex more expensive system, but I would also like to know: What was the reasoning provided and what did decision makers truly believe about the whole thing?

> 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…

Government software contracts are never meant to succeed. They are meant to burn as much cash as possible. Everyone I know who has worked in Arlington has the same story. Huge headcounts. Billable hours. Literal coked out VPs on yachts.

Re: How boring should your team's codebases be

#95

Post by ratww »

Winsaucerer wrote: post #58
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…

Horror stories like this are always fun to read. I've become a fan of avoiding ORM's and API's between front end and back end for websites. Want a page that shows a dashboard of xyz? Write the right query that fetches exactly what you want, render the HTML, and return it. Super simple, and abstractions are at a great minimum. No SQL->ORM->API->frontend, each with their own twist on how they model the world. A splash…

A few years ago I start a dashboard project that was mostly raw SQL.

I then saw the team wanting to convert it to ActiveRecord, which they started. But lots of queries had to use AREL (Rails' "low level SQL AST abstraction"), since they weren't really possible or just too difficult to do in ActiveRecord.

But AREL is so incredibly unreadable that every single AREL query often had its equivalent in plain SQL above it, as documentation, so new people could understand what the hell it was doing.

In the end some junior was unhappy with the inconsistent documentation and petitioned that every query, simple or complex, AREL or ActiveRecord, had to be documented using SQL above the AREL/AR code.

Then they discovered that documenting using Heredocs rather than "language comments" enabled SQL syntax highlighting in their editors.

After that we had both: heredocs with the cute SQL and some unreadable AREL+AR monstrosity right below it.

I still laugh about this situation when I remember it.

Re: How boring should your team's codebases be

#96

Post by andrewstuart »

Here’s a question for you:

“To what extent should developers use advanced programming language features?”

I worked on a project once that had lots of sophisticated code in it. One of the senior developers objected however when I suggested we use typescript decorators. He said other developers might not understand it.

Consider what happens when the question is phrased differently:

“To what extent should developers use unfamiliar programming language features?”

Well, all language features are initially unfamiliar.

It’s a matter of opinion, but I think developers should use whatever language features they want, and all developers working on that should be expected to be active in learning unfamiliar techniques that they are implemented in the code. It’s extremely unhelpful to say that language features are “too advanced” or “too unfamiliar” to use.

Re: How boring should your team's codebases be

#97

Post by kyleyeats »

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…

This comment was better than the post!

Re: How boring should your team's codebases be

#98

Post by photochemsyn »

Kwpolska wrote: post #71
photochemsyn wrote: post #59

The article mentions Architectural Design Records (ADR) which can be included as a folder in the git repo for the project, as a means of documenting the historical decisions that led to the project's current structure. Some of that seems overly complex or formalized (i.e. reinventing UML and all the problems that came with it), but having that history in some kind of constant format would likely help overcome any nov…

Where do you see the reinvention of UML within ADR? I wouldn't consider ADRs to be that; I'd say ADRs are meant for important decisions with important consequences, not a documentation of every single design choice and every single part of the project, as UML proponents would do.

Some of the ADR discussions seem to revolve around trying to create a formalized 'use anywhere' ADR model which does looks suspiciously like UML. The general concept (a historical record of the development of the architecture) sounds good, but a one-size-fits-all approach sounds like a bad idea. ADR approachs should probably be heavily customized to fit each project/codebase.

Some people might say, "but if we had standardized ADRs we could efficiently compare different codebases" but that's going back to UML.

Re: How boring should your team's codebases be

#99

Post by simonebrunozzi »

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…

> This is why we can't have simplicity: because it doesn't scale.

No, it's because it doesn't sell.

Re: How boring should your team's codebases be

#100

Post by Winsaucerer »

paulryanrogers wrote: post #93
Winsaucerer wrote: post #62

Earlier quoted context omitted.

Presumably they just did whatever the standard provided mechanisms for their SQL driver were (such as parameterised queries). User inputs text in a comment box, and you insert it into database using such a mechanism and it's safe. And if you're using, for example, Go's templating library, then it automatically escapes everything in HTML templates unless you explicitly override this default behaviour.

Well if it was only 100 lines of plain JS then how would one guard against reflection attacks? I.e. submitting HTML (like script tags) then getting that to render when others view the tainted data.

Because on this way of building sites, the user submitted data is escaped before it reaches the browser. E.g.: https://go.dev/play/p/MmNSxU5QfAb (hit run to see the output).

The JS wouldn't need to do any escaping, because it's not trusted to handle any unescaped data. It's operating on the already-escaped html template.

Post reply on HN