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

51–60 of 235 posts

Re: How boring should your team's codebases be

#51

Post by jderiksen »

Philip-J-Fry wrote: post #40

There's never a simple answer to this. Here's some of the things we encounter: * A bored developer is an unhappy developer. Unhappy developers leave. Developers that leave take a swathe of domain knowledge with them. * Your good developers are often the ones who like to tinker with frameworks, patterns and complexity. Note: good developers don't force this down people's throats, but they're always thinking about what…

> Technical leaders have a fine balance between keeping developers happy, keeping development velocity high and keeping onboarding speed high.

Very much in agreement that the best developers love experimentation and tinkering. I think about this kind of balancing act quite a bit and I personally like very small teams of folks who are not afraid of a lot of spice as long as the tools either have decent community or are not impossible to hack.

Re: How boring should your team's codebases be

#52

Post by xcambar »

ratww wrote: post #50
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.

Nowhere in the grandparent's post says that it was a "walled garden", or even that it was closed source. The fact that only one person was needed doesn't mean there's only one person available. OP even said he worked for a company in a reply. The rationalisation automatically assumes that the grandparent is either incompetent or lying by omission, which is very uncharitable. Even if all those problems were true, if i…

Didn't say it was a walled garden. But management has its own ways and quirks I said it was possible that the situation was seen by mgmt as a walled garden.

Seen as.

Re: How boring should your team's codebases be

#53

Post by patrickthebold »

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…

It sounds like your project ended up working out well (ignoring the replacement). But one thing that would be hard for me when starting a project like this: How do you know that over time it won't grow into something terribly unmaintainable? You don't have an ORM, but then perhaps over time you re-implement most of the functionality of an ORM, and now new people need to learn that. Of course, you can start with out one and bring one in when it is needed. But in my experience that's hard to actually do because feature N + 1 needs to be implemented now and there's no time to migrate everything over to (ORM that would have been nice to have to make feature N + 1 easy to implement.)

I'm just using ORM as an example, or course.

Anyhoo, I think there's probably some other dimensions than "boring". Seems like you used "less" tech, but I'd say in the java world Spring and Hibernate are boring, or at least "popular", in the sense you can hire devs anywhere with some experience.

Re: How boring should your team's codebases be

#54

Post by omegalulw »

jiggawatts wrote: post #32
eurasiantiger wrote: post #21

Earlier quoted context omitted.

How secure was the app compared to the new one?

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.

Confused here. Where were input validation checks in your implementation? How did you guard against SQL injection, etc?

Re: How boring should your team's codebases be

#55

Post by andrewstuart »

I disagree with the fundamental premise put forward here.

Software should be written to meet specific needs.

And those needs should be defined.

And it’s likely a software project will have many tens of needs defined.

And amongst all those needs it will become clear what technologies fit the needs.

A blanket statement like “choose boring technology” only fits projects where the project needs result in that outcome.

Saying “projects should be built with boring technologies” is the equivalent of saying “projects should be built to NASA launch spec reliability”. That MIGHT be true, but having a predefined idea of what the requirements are puts the cart before the horse.

Requirements come first, then after that come statements about how things will be done.

My guess is that systematic definition of requirements will result in very very few projects “built using boring technology”.

Re: How boring should your team's codebases be

#56

Post by porker »

Working on a not-yet-launched Web app, where the backend and frontend both use CQRS, and hoops are jumped through in the name of "purity", a more boring codebase would be appreciated. Velocity would be higher and new hires onboarded in less time.

Re: How boring should your team's codebases be

#57

Post by brobdingnagians »

conickal wrote: post #26
bdg wrote: post #18

Earlier quoted context omitted.

> I would prefer to work on a codebase that solves problems effectively than a codebase that is novel. I have a design for a very very boring code base that involves no frameworks or external libs. It works fantastic and has been used by some of the most productive teams I've managed. Those teams can manage "more services than we have people on the team by a scale of 2-4x" (quote from one of the engineers on one of t…

This sounds interesting to me!

I second that. I really like the idea.

Re: How boring should your team's codebases be

#58

Post by Winsaucerer »

jiggawatts wrote: post #32
eurasiantiger wrote: post #21

Earlier quoted context omitted.

How secure was the app compared to the new one?

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 of JS (perhaps via HTMX or Alpine), and this can take you a long way.

Re: How boring should your team's codebases be

#59

Post by photochemsyn »

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 novelty issues and help people grasp what's going on. The simplest format discussed seems the best for most cases:

https://github.com/joelparkerhenderson/architecture-decision...

Post reply on HN